Creating secret

Passwords are used for KeyStore, by Administrator to connect to Connect:Direct server, and to decrypt certificates files.

To separate application secrets from the Helm Release, a Kubernetes secret must be created based on the examples given below and be referenced in the Helm chart as secret.secretName value.

To create Secrets using the command line, follow the steps below:
  1. Create a template file with Secret defined as described in the example below:
    apiVersion: v1
    kind: Secret
    metadata:
      name: <secret name>
    type: Opaque
    data:
      admPwd: <base64 encoded password>
      crtPwd: <base64 encoded password>
      keyPwd: <base64 encoded password>
      appUserPwd: <base64 encoded password>
    Here:
    • admPwd refers to the password that will be set for the Admin user 'cduser' after a successful deployment
    • crtPwd refers to the password used to decrypt certificate files
    • keyPwd refers to the Key Store password
    • appUserPwd refers to password for a non-admin Connect:Direct user. This user will only be created inside container if appUserPwd is defined in secret yaml to create Connect:Direct secret object.
    • After the secret is created, delete the yaml file for security reasons. The password entered for admPwd is set as password for the user cduser at pod initialization.
    Note: Base64 encoded passwords need to be generated manually by invoking the below command:
    echo -n “<password>” | base64
    Use the output of this command in the <secret yaml file>.
  2. Run the following command to create the Secret:
    Kubernetes:
    kubectl create -f <secret yaml file>
    OpenShift
    oc create -f <secret yaml file>
    To check the secret created invoke the following command:
    kubectl get secrets

    For more details see, Secrets.

    Default Kubernetes secrets management has certain security risks as documented here, Kubernetes Security.

    Users should evaluate Kubernetes secrets management based on their enterprise policy requirements and should take steps to harden security.

  3. For dynamic provisioning, one more secret resource needs to be created for all certificates (secure plus certificates and LDAP certificates). It can be created using below example as required -
    Kubernetes
    kubectl create secret generic cd-cert-secret --from-file=certificate_file1=/path/to/certificate_file1 --from-file=certificate_file2=/path/to/certificate_file2
    OpenShift
    oc create secret generic cd-cert-secret --from-file=certificate_file1=/path/to/certificate_file1 --from-file=certificate_file2=/path/to/certificate_file2
    Note: The secret resource name created above. It should be referenced by Helm chart for dynamic provisioning using parameter `secret.certSecretName'