Validated Patterns

Secret management for the RHOSO GitOps pattern

The RHOSO GitOps pattern requires secrets for OpenStack service passwords, SSH key pairs, bare-metal controller credentials, and container registry authentication. You can provide these secrets in two ways depending on whether a secure storage backend is available. The two approaches can also be combined: for example, store shared credentials (registry, subscription) in the backend while injecting service-specific passwords as bootstrap_secrets, or use onMissingValue: generate to let the backend generate passwords at deployment time.

For the canonical list of required secrets, see Providing secure access to the RHOSO services in the Red Hat OpenStack Services on OpenShift documentation.

Choosing a secrets approach

Review the following approaches before you deploy the pattern.

Secure storage backend and External Secrets Operator

Secure storage backend and External Secrets Operator secrets flow

This is the recommended approach for production deployments. You store secrets in a secure storage backend (for example HashiCorp Vault, AWS Secrets Manager, or any provider supported by the External Secrets Operator). ExternalSecret resources project these secrets into the openstack namespace through a SecretStore.

The framework does not install the storage backend or the External Secrets Operator automatically. You must include the External Secrets Operator through the operator-dependencies Argo CD application by using a Kustomize component from the upstream secrets components. The openstack-secrets Argo CD application deploys the SecretStore and ExternalSecret resources that pull secrets from the backend.

This approach uses the following configuration:

  • The bootstrap secret (for example vault-approle-secret-id) is defined as a bootstrap_secret. The framework injects it into the openstack namespace during make install so that the External Secrets Operator SecretStore can authenticate against the backend.

  • All other secrets are defined under the secrets: section of the values-secret.yaml file. The framework loads them into the backend during make load-secrets.

  • ExternalSecret resources, deployed by the openstack-secrets Argo CD application, fetch secrets from the backend and create the corresponding Kubernetes Secret objects.

Direct injection without an external store

Direct injection secrets flow

Use this approach when you do not have a secure storage backend. All secrets are defined as bootstrap_secrets in the values-secret.yaml file. The framework injects them as Kubernetes Secret objects during make install. No storage backend or External Secrets Operator is installed.

When you use this approach, configure the following:

  • Set global.secretStore.backend to "none" in values-global.yaml.

  • Define every required secret under the bootstrap_secrets: section.

  • Leave the secrets: section empty.

Required secrets

The RHOSO GitOps pattern requires the following secrets in the openstack namespace. The values-secret.yaml.template file in the pattern repository contains placeholder entries for each secret.

Secret nameKey fieldsPurpose

vault-approle-secret-id

id

Authentication credential for the External Secrets Operator SecretStore to connect to the secure storage backend. Required only with the backend + External Secrets Operator approach.

osp-secret

Multiple service and database password fields

OpenStack service passwords (for example AdminPassword, KeystoneDatabasePassword, NeutronPassword). See the Red Hat OpenStack Services on OpenShift documentation for the complete list.

baremetalset-password-secret

NodeRootPassword

Root password for bare-metal data plane nodes.

dataplane-ansible-ssh-private-key-secret

ssh-privatekey, ssh-publickey, authorized_keys

SSH key pair for Ansible provisioning of data plane nodes.

libvirt-secret

LibvirtPassword

Libvirt authentication password.

nova-migration-ssh-key

ssh-privatekey, ssh-publickey

SSH key pair for Nova live migration.

redfish-bmc-secret-auth

username, password

Redfish BMC credentials for bare-metal node management.

redhat-registry

edpm_container_registry_logins

Container registry credentials for EDPM nodes (JSON format).

subscription-manager

username, password, rhc_auth

Red Hat Subscription Manager credentials for EDPM nodes.

Configuring secrets with a secure storage backend

Prerequisites
  • You have forked and cloned the rhoso-gitops repository.

  • You have deployed a secure storage backend and have an authentication credential (for example an AppRole secret ID) available.

  • You have a Git repository with Kustomize overlays that define the SecretStore and ExternalSecret resources for the openstack namespace.

  • You have the OpenStack service passwords, SSH key pairs, BMC credentials, and registry credentials listed in the Red Hat OpenStack Services on OpenShift documentation.

Procedure
  1. Include the External Secrets Operator in the operator-dependencies application by adding a Kustomize component in overrides/values-rhoso-gitops.yaml. The following example uses the Red Hat build of the External Secrets Operator:

    applications:
      operator-dependencies:
        kustomize:
          components:
            - "https://github.com/openstack-k8s-operators/gitops/components/secrets/external-secrets-operator/redhat?ref=<gitops-tag>"

    For other External Secrets Operator variants, see the upstream components/secrets README.

  2. Enable the openstack-secrets application in the same overrides file. This application deploys the SecretStore and ExternalSecret resources that pull secrets from the backend:

      openstack-secrets:
        enabled: true
        repoURL: "https://github.com/<your_organization>/<your-gitops-overlay>.git"
        path: "<path-to-eso-overlay>"
        targetRevision: "<branch-or-tag>"
  3. Extract the authentication credential from your secure storage backend (for example an AppRole secret ID) and save it to a file:

    $ echo -n "<approle-secret-id>" > ~/vault-approle-secret-id
  4. Create a values-secret.yaml file based on the template. Include the bootstrap secret for the backend credential and define all other secrets under the secrets: section for backend injection:

    version: "2.0"
    
    bootstrap_secrets:
      - name: vault-approle-secret-id
        targetNamespaces:
          - openstack
        fields:
          - name: id
            path: ~/vault-approle-secret-id
            onMissingValue: error
    
    secrets:
      - name: osp-secret
        fields:
          - name: AdminPassword
            value: "<admin-password>"
          # ... remaining service password fields
      # ... remaining secrets
  5. Install the pattern:

    $ ./pattern.sh make install
  6. Verify that the ExternalSecret resources are synchronized:

    $ oc get externalsecrets -n openstack

    Each ExternalSecret shows a SecretSynced status when the External Secrets Operator has created the corresponding Kubernetes Secret.

Configuring secrets with direct injection

Prerequisites
Procedure
  1. Set the secret store backend to none in values-global.yaml:

    global:
      secretStore:
        backend: "none"
  2. Copy the secrets template and edit it:

    $ cp values-secret.yaml.template ~/values-secret-rhoso-gitops.yaml

    Replace every CHANGEME_* placeholder with the actual value. For SSH key pairs, set the path: field to point at your local key files. Secret values must be in plain text, not base64-encoded.

  3. Install the pattern:

    $ ./pattern.sh make install
  4. Verify that the secrets exist in the openstack namespace:

    $ oc get secrets -n openstack