domino logo
About DominoArchitecture
Kubernetes
Cluster RequirementsDomino on EKSDomino Kubernetes Version CompatibilityDomino on GKEDomino on AKSDomino on OpenShiftNVIDIA DGX in DominoDomino in Multi-Tenant Kubernetes ClusterEncryption in Transit
Installation
Installation ProcessConfiguration ReferenceInstaller Configuration ExamplesPrivate or Offline Installationfleetcommand-agent release notes
Azure Deployments
Prepare for InstallationProvision Infrastructure and Runtime EnvironmentDeploy Domino
Google Cloud Deployments
Prepare for InstallationProvision Infrastructure and Runtime EnvironmentDeploy Domino
Amazon Web Services Deployments
Prepare for InstallationProvision Infrastructure and Runtime EnvironmentDeploy Domino
Configuration
Central ConfigurationNotificationsChange The Default Project For New UsersProject Stage ConfigurationDomino Integration With Atlassian Jira
Compute
Manage Domino Compute ResourcesHardware Tier Best PracticesModel Resource QuotasPersistent Volume ManagementAdding a Node Pool to your Domino ClusterRemove a Node from Service
Keycloak Authentication Service
Operations
Domino Application LoggingDomino MonitoringSizing Infrastructure for Domino
Data Management
Data in DominoData Flow In DominoExternal Data VolumesDatasets AdministrationSubmit GDPR Requests
User Management
RolesView User InformationRun a User Activity ReportSchedule a User Activity Report
Environments
Environment Management Best PracticesCache Environment Images in EKS
Backup and Restore
Backup StructureBackup LocationCustomize BackupsRun a Manual, On-Demand BackupRestore backups
Control Center
Control Center OverviewExport Control Center Data with The API
domino logo
About Domino
Domino Data LabKnowledge BaseData Science BlogTraining
Admin Guide
>
Kubernetes
>
Encryption in Transit

Encryption in Transit

Intra-cluster encryption in transit is implemented (if enabled) through a deployed service mesh called Istio. At installation time,

Domino can deploy Istio for Domino use only, or
Domino can be configured to leverage an existing deployed Istio mesh on the Kubernetes cluster (potentially shared with other applications). See Installation Configuration Reference for details.

Custom certificate authority certificates

Important

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,

these certificates are not exposed or required for communication to any external services, such as web browsers and clients.

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

Note

First, obtain the certificate files, noting the file names for use in future commands.

FilenameDescription

root-cert.pem

Root CA certificate for PKI.

ca-cert.pem

Intermediate CA certificate from root CA. This is the Istio CA certificate.

ca-key.pem

Private key for Istio CA certificate.

cert-chain.pem

Full chain from ca-cert.pem to root-cert.pem

(including both certificates).

# 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

  1. New Domino installation

    A standard installation following the install process with the fleetcommand-agent (Domino installer) will

    automatically pick up the created secret and Istio will use the configured certificates.

  2. 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:

  1. No changes have been made to the private key and common name

    This assumes only ca-cert.pem is updated.

  2. 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).

Tip

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
Domino Data LabKnowledge BaseData Science BlogTraining
Copyright © 2022 Domino Data Lab. All rights reserved.