Manage TLS Certificates for Confluent Platform Using Confluent for Kubernetes¶

Rotate user-provided server certificates¶

In Confluent for Kubernetes (CFK), to rotate user-provided certificates that have been provided as Kubernetes secrets, you can update the contents of the Kubernetes secrets.

For example, to rotate the server certificates that you provided in .pem files:

Update the server.pem certificate and server-key.pem certificate private key.

Update the Kubernetes secret using the following command:

kubectl create secret generic component-tls \
--from-file=fullchain.pem=server.pem \
--from-file=cacerts.pem=ca.pem \
--from-file=privkey.pem=server-key.pem \
--save-config --dry-run=client -oyaml | \
kubectl apply -f -

CFK will watch for the Kubernetes secret changes, will notice that the content has changed, and will then rolling restart the component to configure the new server certificate.

Note that CFK only watches the secrets provided in the .pem format. This feature is not supported for the secrets provided in the .jks format.

Rotate certificate authority¶

You can rotate the certificate authority that have been provided as Kubernetes secrets using the steps described in this section.

The examples use the .pem files for providing certificates.

Step 1. Append new certificate authority¶

Append the new intermediate/root CA to the ca.pem file. It will co-exist with the old intermediate/root CA.

file name: ca.pem
content:
-----BEGIN CERTIFICATE-----
<old root CA certificate>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<new root CA certificate>
-----END CERTIFICATE-----

Update the secret:

kubectl create secret generic component-tls \
--from-file=fullchain.pem=server.pem \
--from-file=cacerts.pem=ca.pem \
--from-file=privkey.pem=server-key.pem \
--save-config --dry-run=client -oyaml | \
kubectl apply -f -

CFK will watch for the Kubernetes secret changes, notice that the content has changed, and then perform a rolling restart for the component to configure the new root CA for use alongside the old root CA.

If this certificate authority is for Kafka and the dynamic loading is enabled, the cluster will not roll.

Step 2. Generate server certificates with new certificate authority¶

Generate the new server certificates with the new CA, and replace the server.pem certificate and the server-key.pem certificate private key.

Update the Kubernetes secret:

kubectl create secret generic component-tls \
--from-file=fullchain.pem=server.pem \
--from-file=cacerts.pem=ca.pem \
--from-file=privkey.pem=server-key.pem \
--save-config --dry-run=client -oyaml | \
kubectl apply -f -

CFK will watch for the Kubernetes secret changes, will notice that the content has changed, and will then rolling restart the component to configure the new server certificate.

If this certificate is for Kafka and the dynamic loading is enabled, the cluster will not roll.

Manage auto-generated certificates¶

To manage auto-generated certificates in Confluent for Kubernetes (CFK), use the following annotations in the Confluent Platform component CRs.

Force a renewal of auto-generated certificates:
```
kubectl annotate <Component CR type> <Component CR name> \
  platform.confluent.io/force-managed-cert-renewal="true"
```
The annotation triggers a reconciliation on the Confluent Platform component. The process causes the certificates to be renewed, and the component to be rolled.

After the certificates are renewed, the annotation is reset to false.
Add additional custom SAN for auto-generated certificates. This will be added to SANs defined at the global level in managedCerts.sans in the CFK Helm values (in values.yaml).
```
kubectl annotate secret ca-pair-sslcerts \
  platform.confluent.io/managed-cert-add-sans="<Comma separated list of SANs>"
```
For example, the following annotation will add the SANs, kafka.operator, kafka.operator.local, to auto-generated certificates for Kafka:
```
kubectl annotate secret ca-pair-sslcerts \
  platform.confluent.io/managed-cert-add-sans="kafka.operator, kafka.operator.local"
```
After the annotation is set, use the platform.confluent.io/force-managed-cert-renewal="true" annotation to force a renewal of certificates. If not forced, SANS will be updated during the next reconciliation.
Specify the Kubernetes secret name for the CA certificates at the CR level. This will override the global config defined in managedCerts.caCertificate in the CFK Helm values (in values.yaml). This can be used even if managedCerts.enable is set to false.
```
kubectl annotate <Component CR type> <Component CR name> \
  platform.confluent.io/managed-cert-ca-pair-secret=<Secret name>
```
The secret should have tls.crt and tls.key with the CA certificate and key.

Configure the optional settings for auto-generated certificates at the CR level:

kubectl annotate <Component CR type> <Component CR name> \
  platform.confluent.io/managed-cert-duration-in-days=<Number of days>

kubectl annotate <Component CR type> <Component CR name> \
  platform.confluent.io/managed-cert-renew-before-in-days=<Number of days>

For example:

kubectl annotate kafka kafka platform.confluent.io/managed-cert-duration-in-days=60

kubectl annotate kafka kafka platform.confluent.io/managed-cert-renew-before-in-days=30

After the annotations are set, use the platform.confluent.io/force-managed-cert-renewal="true" to force a renewal of certificates.