Intra-cluster encryption in transit is implemented (if enabled) through a deployed service mesh called Istio. At installation time,
Out of the box, Istio provides scalable identity and X.509 certificate management for use with mTLS encryption, including periodic certificate and key rotation. Because all encrypted communication is internal,
Domino acknowledges that enterprise policies might mandate the use of corporate public key infrastructure (PKI) and necessitate the use of certificate authority (CA) certificates.
Set up custom CA certificates
First, obtain the certificate files, noting the file names for use in future commands.
Filename | Description |
---|---|
| Root CA certificate for PKI. |
| Intermediate CA certificate from root CA. This is the Istio CA certificate. |
| Private key for Istio CA certificate. |
| Full chain from |
# Concatenate all certificates into a certificate chain file
# Assuming `N` intermediate certificates denoted as `int-ca-<i>.pem`, with `i = {1,...,N}`
cat ca-cert.pem int-ca-1.pem ... int-ca-N.pem root-cert.pem > cert-chain.pem
# Create new kubernetes secret with CA certificate files
kubectl -n istio-system create secret generic cacerts \
--from-file=./ca-cert.pem \
--from-file=./ca-key.pem \
--from-file=./root-cert.pem \
--from-file=./cert-chain.pem
Final steps
-
New Domino installation
A standard installation following the install process with the
fleetcommand-agent
(Domino installer) willautomatically pick up the created secret and Istio will use the configured certificates. -
Existing Domino installation
Restarting all the pods of the existing Domino installation
Update existing custom CA certificates
This section describes how to update the custom CA certificates used by Istio for intra-cluster encryption in transit. The following are the scenarios:
-
No changes have been made to the private key and common name
This assumes onlyca-cert.pem
is updated. -
Updates have been made to the private key, common name, or upstream certificates
Any of the certificate files have changed, including any upstream intermediate certificates.
In both cases, you must create a new full chain certificate file (cert-chain.pem
).
No changes have been made to the private key and common name
The procedure to update custom CA certificates is to create a secret[secret^] with the new files and restart the Istio daemon (istiod
).
# Delete existing secret with CA cert files
kubectl -n istio-system delete secret cacerts
# Create new secret with CA cert files
kubectl -n istio-system create secret generic cacerts \
--from-file=./ca-cert.pem \
--from-file=./ca-key.pem \
--from-file=./root-cert.pem \
--from-file=./cert-chain.pem
# Restarting all istiod pods
kubectl -n istio-system delete po -l app=istiod
Updates have been made to the private key, common name, or upstream certificates
Any changes made to the private key, common name (CN) or upstream certificates necessitate recreating the cacerts
secret and restarting the Istio daemon.
# Delete existing secret with CA cert files
kubectl -n istio-system delete secret cacerts
# Create new secret with CA cert files
kubectl -n istio-system create secret generic cacerts \
--from-file=./ca-cert.pem \
--from-file=./ca-key.pem \
--from-file=./root-cert.pem \
--from-file=./cert-chain.pem
# Full restart for all Istio pods
for NS in istio-system domino-platform domino-compute; do
kubectl -n $NS get po --no-headers -o custom-columns=name:metadata.name | xargs kubectl -n $NS delete po
done