|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * hosted-control-planes/hcp-deploy/hcp-deploy-aws.adoc |
| 4 | +// * hosted-control-planes/hcp-deploy/hcp-deploy-bm.adoc |
| 5 | +// * hosted-control-planes/hcp-deploy/hcp-deploy-non-bm.adoc |
| 6 | +// * hosted-control-planes/hcp-deploy/hcp-deploy-virt.adoc |
| 7 | + |
| 8 | +:_mod-docs-content-type: PROCEDURE |
| 9 | +[id="hcp-custom-cert_{context}"] |
| 10 | += Configuring a custom API server certificate in a hosted cluster |
| 11 | + |
| 12 | +To configure a custom certificate for the API server, specify the certificate details in the `spec.configuration.apiServer` section of your `HostedCluster` configuration. |
| 13 | + |
| 14 | +You can configure a custom certificate during either day-1 or day-2 operations. However, because the service publishing strategy is immutable after you set it during hosted cluster creation, you must know what the hostname is for the Kubernetes API server that you plan to configure. |
| 15 | + |
| 16 | +.Prerequisites |
| 17 | + |
| 18 | +* You created a Kubernetes secret that contains your custom certificate in the management cluster. The secret contains the following keys: |
| 19 | +
|
| 20 | + ** `tls.crt`: The certificate |
| 21 | + ** `tls.key`: They private key |
| 22 | +
|
| 23 | +* If your `HostedCluster` configuration includes a service publishing strategy that uses a load balancer, ensure that the Subject Alternative Names (SANs) of the certificate do not conflict with the internal API endpoint (`api-int`). The internal API endpoint is automatically created and managed by your platform. If you use the same hostname in both the custom certificate and the internal API endpoint, routing conflictcs can occur. The only exception to this rule is when you use {aws-short} as the provider with either Private or PublicAndPrivate configurations. In those cases, the SAN conflict is managed by the platform. |
| 24 | +
|
| 25 | +* The certificate must be valid for the external API endpoint. |
| 26 | +
|
| 27 | +* The validity period of the certificate aligns with your cluster's expected life cycle. |
| 28 | +
|
| 29 | +.Procedure |
| 30 | + |
| 31 | +. Create a secret with your custom certificate by entering the following command: |
| 32 | ++ |
| 33 | +[source,terminal] |
| 34 | +---- |
| 35 | +$ oc create secret tls sample-hosted-kas-custom-cert \ |
| 36 | + --cert=path/to/cert.crt \ |
| 37 | + --key=path/to/key.key \ |
| 38 | + -n <hosted_cluster_namespace> |
| 39 | +---- |
| 40 | + |
| 41 | +. Update your `HostedCluster` configuration with the custom certificate details, as shown in the following example: |
| 42 | ++ |
| 43 | +[source,yaml] |
| 44 | +---- |
| 45 | +spec: |
| 46 | + configuration: |
| 47 | + apiServer: |
| 48 | + servingCerts: |
| 49 | + namedCertificates: |
| 50 | + - names: <1> |
| 51 | + - api-custom-cert-sample-hosted.sample-hosted.example.com |
| 52 | + servingCertificate: <2> |
| 53 | + name: sample-hosted-kas-custom-cert |
| 54 | +---- |
| 55 | +<1> The list of DNS names that the certificate is valid for. |
| 56 | +<2> The name of the secret that contains the custom certificate. |
| 57 | + |
| 58 | +. Apply the changes to your `HostedCluster` configuration by entering the following command: |
| 59 | ++ |
| 60 | +[source,terminal] |
| 61 | +---- |
| 62 | +$ oc apply -f <hosted_cluster_config>.yaml |
| 63 | +---- |
| 64 | + |
| 65 | +.Verification |
| 66 | + |
| 67 | +* Check the API server pods to ensure that the new certificate is mounted. |
| 68 | +
|
| 69 | +* Test the conncetion to the API server by using the custom domain name. |
| 70 | +
|
| 71 | +* Verify the certificate details in your browser or by using tools such as `openssl`. |
0 commit comments