Manage Credentials and Secrets in Confluent for Kubernetes Blueprints¶

Credentials stores¶

To set up authentication and authorization in Confluent for Kubernetes (CFK) Blueprints, you use credential stores (CredentialStoreConfig CRs) to create and manage credentials. The required credentials are referenced in the ConfluentPlatformBlueprints via credential stores.

For external communication, you can provide credentials in the ConfluentPlatformBlueprint CR or in the Confluent cluster CR based on desired provider option you specify in the ConfluentPlatformBlueprint CR.
For internal communications among Confluent Platform components and Kafka internal listeners, CFK Blueprints auto-discovers and manages internal credentials. However, you have the option to provide client-side credentials at the deployment level through the component cluster CRs.

Configure a credential store¶

Create a file and add the credentials in the required format. Refer to the specific authentication and authorization documents for the required format.
Create a Kubernetes secret using the expected/default key and the value file you created in the previous step.

The expected/default key can be found in the specific authentication and authorization document that require these credentials.

In the case where the default keys can be overridden, use your custom key in the command below (<key>), and specify that key in the ConfluentPlatformBlueprint CR in configStoreRef.key under the corresponding object.
```
kubectl create secret generic <secret name> \
  --from-file=<key>=<path to the credential file> \
  --namespace <namespace>
```
To inject the authentication credentials, create a CredentialStoreConfig CR:
```
kind: CredentialStoreConfig
metadata:
  name:                       --- [1]
  namespace:                  --- [2]
spec:
  sourceType: kubernetes      --- [3]
  kubernetes:                 --- [4]
    type: secret              --- [5]
    secret:
      name:                   --- [6]
    autoRoll:                 --- [7]
```
- [1] Required. Name of this credential store.
- [2] Namespace for this credential store.
- [3] Required. Specify how the credentials are stored. The valid option is kubernetes for using Kubernetes to store credentials.
- [4] Required when [3] is set to kubernetes.
- [5] Required. Specify to use a Kubernetes secret to store the credentials.
- [6] Required. Provide the name of the secret that contains the credentials.
- [7] Set to true to have updates to these credentials automatically roll the clusters. Only the clusters that use the credentials will be rolled. false is the default setting.
  
  If you want to control how the credential updates and the clusters roll, set this to false to disable auto-rolling.
To the ConfluentPlatformBlueprint CR that will use the credentials, add a reference to the credential store you created in the previous step.
```
kind: ConfluentPlatformBlueprint
spec:
  credentialStoreConfigRefs:
    - name:                   --- [1]
      namespace:              --- [2]
```
- [1] Required to enable authentication. The name of the CredentialStoreConfig CR that contains the credential secrets.
- [2] The namespace of the CredentialStoreConfig CR in [1]. If omitted, defaults to the current namespace of this ConfluentPlatformBlueprint CR.

Update a credential¶

When an underlying credential changes, and when spec.autoRoll is set to false in the CredentialStoreConfig CR, apply the following annotation to manually roll the cluster deployment CR that is using the CredentialStoreConfig CR:

kubectl annotate <CR type> <CR name> -n <namespace> cpc.platform.confluent.io/force-roll=”true”

Delete a credential store¶

You can delete unreferenced CredentialStoreConfig CRs with the kubectl delete -f command.

You cannot delete a CredentialStoreConfig CR if the CR is referenced by any CFK Blueprints object, such as a ConfluentPlatformBlueprint CR.

Password encoders¶

To encrypt sensitive configuration information, such as passwords for SASL/PLAIN or TLS, create a password encoder in the ConfluentPlatformBlueprint CR. Password encoders are used in the following cases:

For Kafka Cluster Linking, the destination cluster needs to set a password encoder secret and use it to encrypt the sensitive authentication and TLS information of the source cluster.
For Schema Linking, a password encoder secret needs to be configured in the source Schema Registry cluster.

For a new or updated password encoder, the cluster will automatically restart.

To set a password encoder secret:

Create a .txt file in the following format:
```
password=<password>
oldPassword=<old password>
```
oldPassword is only required for password rotations.
Create a Kubernetes secret using the file created in the previous step.

The default keys are:
- kafka-server-password-encoder.txt
- schemaregistry-server-password-encoder.txt
If using different keys, specify those keys in credentialStoreRef.key in the ConfluentPlatformBlueprint CR.
```
kubectl create secret generic <secret name> \
  --from-file=<key>=<path to the credential .txt file> \
  --namespace <namespace>
```
Create a CredentialStoreConfig CR with reference to the secret created in the previous step.

In the ConfluentPlatformBlueprint CR, configure the password encoder credentials:

kind: ConfluentPlatformBlueprint
spec:
  passwordEncoder:
    providerType:             --- [1]
    blueprint:
      credentialStoreRef:
        forKafka:
          name:               --- [2]
          key:                --- [3]
        forSchemaRegistry:
          name:               --- [4]
          key:                --- [5]
    deployment:
      credentialStoreRef:
        forKafka:
          key:                --- [6]
        forSchemaRegistry:
          key:                --- [7]

[1] Required. Specify where the credentials are provided. Valid options are:
- blueprint if you provide the credentials in the ConfluentPlatformBlueprint CR.
- deployment if you provide the credentials in the component cluster Deployment CR.
[2] [4] The value of the credentialStoreConfigRefs.name in the ConfluentPlatformBlueprint CR.
[3] [5] [6] [7] The name of the key in the secret the credentialStoreConfigRefs.name refers to.

Mounted Kubernetes secrets¶

When installing Confluent Platform components, Confluent for Kubernetes (CFK) Blueprints securely stores sensitive credential configuration values you provide as Kubernetes Secrets. However, there are cases where you may wish to provide your own pre-existing secrets to be used in the configuration of Confluent Platform. In CFK Blueprints, you can configure Confluent Platform with the custom secret data you store in an external file. You need to pass only the secret key to CFK Blueprints without exposing sensitive information.

To utilize your own secret, provide a list of those secret objects in Confluent component custom resources (CRs), and CFK Blueprints will mount those secrets as in-memory files in the component containers.

A change in mounted secrets will roll the cluster.

To provide and use mounted secrets:

Create a Kubernetes secret file that contains your sensitive data.

For example:
```
username: user1
password: $ecret_passw0rd
```
Note

The file must use the Linux style line ending that only uses line feed (\n). The Windows style line ending that uses carriage return and line feed (\r\n) does not work in Kubernetes secret files.
Create a Kubernetes secret which stores the content of the file (<path to the secret file>) you created in the previous step:
```
kubectl create secret generic <secret name> \
  --from-file=<secret key>=<path to the secret file>
```
The contents of <path to the secret file> will be Base64-encoded and stored under the <secret key> key of <secret name>.
Create a CredentialStoreConfig CR with the secret you created in the previous step.
Specify the secret information in the ConfluentPlatformBlueprint CR:
```
kind: ConfluentPlatformBlueprint
spec:
  components:
    <component>:                 --- [1]
      mountedSecrets:
        providerType:            --- [2]
        blueprint:               --- [3]
          credentialStoreRefs:   --- [4]
            name:                --- [5]
            - keyItems:
                key:             --- [6]
                path:            --- [7]
                mode:            --- [8]
```
- [1] The Confluent Platform component that the mounted secret is for. The followings are component objects supported in the ConfluentPlatformBlueprint CRs:
  - connectCluster
  - controlCenterCluster
  - kafkaCluster
  - kafkaRestCluster
  - kafkaRestProxyCluster
  - ksqlDBCluster
  - schemaRegistryCluster
  - zookeeperCluster
- [2] Required. Specify where the mounted secrets come from. The valid option is blueprint.
- [3] Required. Specify the secrets provided by the Blueprint.
- [4] Required. Specify a list of credentialStoreRef.
- [5] Required. The name of the Kubernetes secret.
- [6] Required. The secret key of the Kubernetes secret.
- [7] Required. Set to the relative path where the secret key ([6]) is stored.
  
  It may not be an absolute path and may not contain the string ...
  
  For example, if name ([5]) is set to my-secret-aws, key ([6]) is set to credentials, and path ([7]) is set to aws/creds, the credentials are stored in /mnt/secrets/my-secret-aws/aws/creds/credentials.
- [8] Set permissions on secret file. Must be an octal value between 0000 and 0777 or a decimal value between 0 and 511.
  
  YAML accepts both octal and decimal values, and JSON requires decimal values for mode bits. If not specified, the volume defaultMode will be used.

Reference the mounted secret in the Confluent component cluster CR:

kind: <Confluent component cluster class CR>
spec:
  provisioner:
    cfk:
      configOverrides:
        server:
          - property=${file:/mnt/secrets/<secret name>/<secret path>/<secret key>}

For example:

kind: KafkaClusterClass
spec:
  provisioner:
    cfk:
      configOverrides:
        server:
          - kafka.user=${file:/mnt/secrets/example-secret/local/my_credentials:username}
          - kafka.password=${file:/mnt/secrets/example-secret/local/my_credentials:password}