Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 6. Adding custom TLS certificates for Red Hat OpenStack Services on OpenShift
If you decide to apply trusted certificates from your own internal certificate authority (CA), you will need the following information.
- DNS names
For each service you apply your own custom certificate to, you will need its DNS hostname for the process of generating the certificate. You can get a list of public hostnames using the following command:
oc get -n openstack routesNoteTo use a single certificate for two or more services, use a wildcard in the DNS name field, or list multiple DNS names in the subject alt names field. If you do not use a wildcard, then you must update the certificate in the event of a route hostname change.
- Duration
- To update a service’s certificate in OpenShift, the service must be restarted. The duration for the certificate is the longest amount of time a service can stay live without being restarted, subject to your internal security policies.
- Usages
-
You must include -
key encipherment,digital signature, andserver authwithin the list of usages in your certificate.
Updating TLS to use custom certificates requires edits to both the control plane and the data plane.
6.1. Updating the control plane with custom certificates for public services
When you deploy Red Hat OpenStack Services on OpenShift (RHOSO), most API connections are protected by TLS.
TLS is not currently available for the internal Alert Manager Web UI service endpoint.
You might be required to protect public APIs using your own internal certificate authority. In order to replace the automatically generated certificates you must create a secret that contains your additional ca certs, including all certificates in needed chains of trust.
Prerequisites
- You have a service certificate for the public services
Procedure
Create a manifest file called
myAdditionalCACerts.yamlthat includes all CA certificates. Include all certificates in chains of trust if applicable:apiVersion: v1 kind: Secret metadata: name: myAdditionalCACerts namespace: openstack type: Opaque data: myBundleExample: <cat mybundle.pem | base64 -w0> CACertExample: <cat cacert.pem | base64 -w0>
Create the secret from the manifest file:
oc apply -f myAdditionalCACerts.yaml
Create a manifest file for each API certificate secret called
api_certificate_<service>_secret.yaml:apiVersion: v1 kind: Secret metadata: name: api_certificate_<service>_secret namespace: openstack type: kubernetes.io/tls data: tls.crt: <cat tlscrt.pem | base64 -w0> tls.key: <cat tlskey.pem | base64 -w0> ca.crt: <cat cacrt.pem | base64 -w0>
Replace
<service>with the name of the service that this secret is for.NoteYou can use the same secret for multiple services.
Create the secret
oc apply -f api_certificate_<service>_secret.yaml
Edit the
openstack_control_plane.yamlcustom resource and add your bundle as the parameter forcaBundleSecretName:apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane metadata: name: myctlplane spec: tls: podLevel: enabled: true caBundleSecretName: myAdditionalCACertsApply the secret service certificates to each of the public services under the apiOverride field. For example enter the following for the Identity service:
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane metadata: name: myctlplane namespace: openstack spec: ... keystone: apiOverride: tls: secretName: api_certificate_keystone_secretApply the control plane changes
oc apply -f openstack_control_plane.yaml
