CLM TLS overview
Introduction
CLM communication is secured using Transport Layer Security, or TLS. The TLS-secured elements of a CLM deployment include the following:
-
Kubernetes infrastructure—Kubernetes registry, interfaces between CLM deployer host and CLM cluster VMs
-
external CLM cluster endpoints for communication with:
Note: A CLM system upgrade preserves the TLS artifacts.
CLM TLS certificates
The CLM TLS certificates include the following:
Note: You specify the issuer and server TLS artifacts during CLM cluster deployment. The Kubernetes certificates are automatically generated, and require no configuration.
-
Kubernetes infrastructure certificates, applied to:
-
CLM issuer certificates, applied to:
-
CLM server certificates, applied to:
CLM issuer certificates
CLM issuer certificates are CA signing certificates that provide session-level security for the internal and external-facing CLM application endpoints.
CLM server certificates
CLM server certificates secure the ingress gateway for external client access. Using a custom server certificate has special requirements, as described in Using custom TLS certificates.
Kubernetes secrets
The TLS artifacts of a CLM cluster are stored in Kubernetes secrets to prevent the exposure of sensitive security information. The ‘nspdeployerctl secret’ command on a CLM deployer host facilitates secret creation, update, and replacement, and includes other functions such as secret backup and restore. You can also use the command to display the secret content.
The CLM system deployment procedures include steps for creating the required secrets, and “What is NSP TLS administration?” in the NSP System Administrator Guide describes post-deployment TLS certificate and Kubernetes secret management.
See CLM TLS configuration requirements and CLM TLS configuration procedures for information about creating the required TLS artifacts for a CLM deployment.
CLM PKI-server service
A CLM cluster hosts a PKI-server service that uses the CA certificates from the internal and external issuer secrets to sign certificates. The service uses an access control list based on the CLM cluster configuration; consequently, the service responds only to certificate requests from known addresses in the nsp-config.yml file of the local cluster.