Preparing for external secret management

If you plan to integrate Content Cortex and Content Cortex AI Services with an external secret provider such as HashiCorp Vault, complete the following prerequisites.

About this task

External secret management supports secrets for all Content Cortex components and Content Cortex AI Services.

The following custom resource parameters store secret names when a deployment is configured to use an external secret provider:

  • ldap_configuration.lc_bind_secret
  • ldap_configuration.lc_ldap_ssl_secret_name
  • ldap_configuration_<ldap_id>.lc_bind_secret
  • ldap_configuration_<ldap_id>.lc_ldap_ssl_secret_name
  • open_id_connect_providers.client_oidc_secret
  • scim_configuration.scim_secret_name
  • navigator_configuration.ban_secret_name
  • ecm_configuration.fncm_secret_name
  • datasource_configuration.dc_<xxx>_datasource.database_ssl_secret_name
  • ecm_configuration.css.css_production_setting.icc.icc_secret_name
  • shared_configuration.sc_ingress_tls_secret_name
  • shared_configuration.trusted_certificate_list
  • ier_configuration.ier_secret_name
  • iccsap_configuration.iccsap_secret_name
  • iccsap_configuration_multi.<instance_id>.iccsap_secret_name

Procedure

  1. Install HashiCorp Vault and configure it with Kubernetes authentication.

    For more information, see Mounting secrets from HashiCorp Vault External link opens a new window or tab from the Red Hat® OpenShift® Container Platform documentation. The page describes how to set up HashiCorp Vault for basic testing purposes. For production purposes, use the HashiCorp Vault documentation.

  2. Install the CSI drivers and vault plug-in.

    For more information, see Installing the Secrets Store CSI driver External link opens a new window or tab.

    Warning: If you are using a Red Hat OpenShift Kubernetes Service (ROKS) cluster, the Secret Store CSI operator does not work because the Secret Store CSI driver uses /var/lib/kubelet and the default kubelet root directory is /var/data/kubelet. Install the Secret Store CSI Helm chart, and use the configuration parameter --set linux.kubeletRootDir=/var/data/kubelet to resolve the issue. For more information, see the HashiCorp Vault documentation External link opens a new window or tab.
  3. Create a vault policy for Content Cortex.

    The following example creates a vault policy that stores all the required secrets in the secret/data/ccx folder.

    vault policy write ccx-vault-policy - << EOF
path "secret/data/ccx/*" {
  capabilities = ["read"]
}
EOF
  4. Create a vault role for Kubernetes.

    The following example creates a vault role that lists the service account names that need access, and the Content Cortex namespace.

    cat <<EOF | vault write auth/kubernetes/role/ccx-vault-role \
  bound_service_account_names="ibm-<meta.name>-operator, \
                               ibm-<meta.name>-operator-sa, \
                               <meta.name>-fncm-service-account, \
                               ibm-cp4a-content-operator, \
                               ibm-ccx-ai-services-operator-sa, \
                               ibm-ai-services-sa" \
  bound_service_account_namespaces=<ccx-project> \
  policies=ccx-vault-policy \
  ttl=20m
EOF
    The <meta.name> in the command is the name of the Content Cortex custom resource (CR) that you create. By default, the name is content. Replace <meta.name> with the name of your CR.
    You can add any other service accounts required to the bound_service_account_names parameter.
    bound_service_account_names="ibm-<meta.name>-operator,ibm-<meta.name>-operator-sa,<meta.name>-fncm-service-account,<meta.name>-iccsap-service-account,<meta.name>-ier-service-account,ibm-usage-metering-instance,ibm-usage-metering-operator,ibm-ai-services-sa,ibm-ccx-ai-services-operator-sa"