Verification

The Beyond Defaults page covers the values you send into the chart. This page covers the opposite direction. It shows how a deployer can see what is actually running, including the material the deployment generates on its own, such as service provider signing keys and SAML metadata.

Values in the release

Render the manifests without installing, to preview the result of your overrides:

helm template <Release.Name> cortex/cortex -f my-values.yaml -n <NAMESPACE>

After an install, inspect the values a release was actually given:

helm get values <Release.Name> -n <NAMESPACE>

See every manifest the release currently has applied, with the defaults and overrides already resolved:

helm get manifest <Release.Name> -n <NAMESPACE>

Secrets and certificates

The chart and its dependencies generate a number of Kubernetes secrets that hold TLS certificates, SAML signing keys, and credentials. cert-manager issues the service certificates, and CloudNativePG issues the ones for the Registry database. None of this material appears in your values file.

Secret	Type	Purpose
proxy-tls	TLS	Proxy HTTPS server certificate
discovery-tls	TLS	Discovery HTTPS server certificate
registry-tls	TLS	Registry HTTPS server certificate
ldap-tls	TLS	LDAP directory TLS certificate
registry-sp-cert	TLS	Registry Shibboleth service provider signing and encryption certificate
discovery-sp-cert	TLS	Discovery Shibboleth service provider signing and encryption certificate
satosa-backend-cert	TLS	Proxy SATOSA backend certificate, the proxy acting as a service provider
satosa-frontend-cert	TLS	Proxy SATOSA frontend certificate, the proxy acting as an identity provider
registry-db-server	TLS	Registry database server certificate
registry-db-replication	TLS	Registry database replication certificate
registry-db-ca	Opaque	Registry database certificate authority
registry-db-credentials	basic-auth	Registry database username and password
registry-secret	Opaque	Registry database password, email account password, and security salt
satosa-secret	Opaque	Proxy state encryption key and user identifier hash salt
ldap-admin	Opaque	LDAP administrator password

Reading secrets

Kubernetes stores secret data base64 encoded. To see every key of a secret with its decoded value:

kubectl -n <NAMESPACE> get secret registry-secret \
  -o go-template='{{range $k,$v := .data}}{{printf "%s:\n" $k}}{{$v | base64decode}}{{"\n\n"}}{{end}}'

To read a single key, for example the database username and password from the basic-auth secret:

kubectl -n <NAMESPACE> get secret registry-db-credentials -o jsonpath='{.data.username}' | base64 -d; echo
kubectl -n <NAMESPACE> get secret registry-db-credentials -o jsonpath='{.data.password}' | base64 -d; echo

The decoded output includes private keys and passwords in clear text, so run these commands in a private shell and do not share the output.

Checking certificates

A TLS secret holds the certificate under tls.crt. Decode it and pass it to openssl to see who it was issued to, who signed it, and how long it is valid. Reading the certificate is safe, because it is the public half of the pair.

kubectl -n <NAMESPACE> get secret registry-tls -o jsonpath='{.data.tls\.crt}' | base64 -d \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

The output shows the subject, which is who the certificate was issued to, the issuer, which is who signed it, the notBefore and notAfter validity window, and the DNS names the certificate covers. To check quickly whether a certificate is still valid:

kubectl -n <NAMESPACE> get secret registry-tls -o jsonpath='{.data.tls\.crt}' | base64 -d \
  | openssl x509 -noout -checkend 0 && echo valid || echo expired

Tip

A secret that holds a certificate authority, such as registry-db-ca, keeps its certificate under ca.crt rather than tls.crt, so read that key instead.

More details on the certificates in general can also be obtained by running the commands below;

kubectl -n <NAMESPACE> get certificate -o wide
kubectl -n <NAMESPACE> describe certificate registry-tls

Tip

The Shibboleth and SATOSA signing certificates (registry-sp-cert, discovery-sp-cert, satosa-backend-cert, and satosa-frontend-cert) are long lived and self signed.