Certificates and DevOps Secrets Safe

The DevOps Secrets Safe application uses both client facing and internal application certificates to maximize the security of the application. The following sections describe their usage and purpose.

Client Facing Certificates

The DevOps Secrets Safe application always serves over an HTTPS connection. By default the standard Kubernetes self-signed certificate is used.

If you wish to supply a custom certificate for an instance of DevOps Secrets Safe, you must provide your certificate to the cluster before installing and supply the certificate name for the install either through installer arguments or values file entries.

If using the values file, modify the following in the values.yml file:

  • Change the ingress.certificateSecretName: value to ${CERT_SECRET_NAME}.
  • Change the ingress.host to the hostname you wish to use to refer to the ingress.

If using the installer arguments, those values may be supplied using --ingress-cert-secret-name and --ingress-hostname arguments.

In order to provide your chosen certificate to the cluster use the following command:

kubectl create secret tls ${CERT_SECRET_NAME} --key ${KEY_FILE} --cert ${CERT_FILE}

If you do not wish to supply a custom certificate but you do want the feature of hostname-based routing, you may leave the certificateSecretName value blank but fill in the preferred ingress hostname.

Internal Application Certificates

The DevOps Secrets Safe application leverages an internal set of certificates signed by the cluster's Certificate Authority to enhance security. These certificates have a duration governed by the configuration of the cluster (many clusters default to one year).

In order to renew these certificates you can run the following command:

<installer_directory>/install.sh --rotate-certificates --namespace ${KUBERNETES_NAMESPACE}

Renewing these certificates will not interrupt normal operations.