Transport Layer Security (TLS) in Mission Control

Mission Control uses Transport Layer Security (TLS) to secure communication between platform components. Mission Control automates much of the complex work required to configure and maintain TLS.

This page explains the parts of TLS management in Mission Control that you can configure or inspect.

Configure TLS

By default, the values.yaml file includes the following tls settings:

tls:
  generateCa: true
  rootCaSecretName: "mission-control-platform-ca"
  certDuration: 8760h # 365 days
  certRenewBefore: 336h # 14 days before expiry

The following settings control how Mission Control manages platform TLS resources:

generateCa: Tells Mission Control to create and manage a root certificate authority (CA). See Choose a CA management model.
rootCaSecretName: Specifies the Kubernetes secret that stores the root CA. If generateCa is false, this value must point to an existing CA secret. See Choose a CA management model and Resources derived from the root CA.
certDuration: Sets the lifetime of certificates that Mission Control creates. You do not need this setting for certificates that Mission Control doesn’t create. For more information, see Manage Mission Control certificate and certificate authority (CA) expiration.
certRenewBefore: Sets how long before expiration cert-manager starts certificate renewal. You do not need this setting for certificates that Mission Control doesn’t create. For more information, see Manage Mission Control certificate and certificate authority (CA) expiration.

Choose a CA management model

For the platform root CA, you can use fully managed TLS (recommended) or your own CA.

Use fully managed TLS

DataStax recommends that you use fully managed TLS. It is the simplest and most secure way to manage TLS for Mission Control.

If generateCa is true, Mission Control creates cert-manager resources during the Helm installation.

First, Mission Control creates a self-signed Issuer resource similar to the following example:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: mission-control-platform-self-signed
  namespace: mission-control
spec:
  selfSigned: {}

Next, Mission Control uses that issuer to create a Certificate resource that acts as the root CA:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: mission-control-platform-ca-cert
  namespace: mission-control
spec:
  commonName: mission-control-platform-ca
  dnsNames:
  - mission-control-platform-ca
  duration: 8760h0m0s
  isCA: true
  issuerRef:
    kind: Issuer
    name: mission-control-platform-self-signed
  renewBefore: 336h0m0s
  secretName: mission-control-platform-ca

cert-manager then creates the secret that secretName specifies. Mission Control expects this secret to use the default cert-manager TLS keys:

Type: kubernetes.io/tls

Data
====
ca.crt:   1188 bytes
tls.crt:  1188 bytes
tls.key:  1675 bytes

Because the root CA is self-signed, web browsers display a warning about the security certificate when you open the Mission Control UI or other web endpoints that Mission Control serves.

Use your own CA

If generateCa is false, the Helm installation doesn’t create the self-signed issuer or the root CA certificate.

Instead, Mission Control uses the secret that rootCaSecretName names when it creates the remaining TLS resources.

When you provide your own CA, ensure that the CA can sign the leaf certificates that Mission Control needs.

Resources derived from the root CA

After the Helm installation creates or identifies the root CA secret, Mission Control creates another Issuer resource that references rootCaSecretName:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: mission-control-issuer
  namespace: mission-control
spec:
  ca:
    secretName: mission-control-platform-ca

Mission Control then uses this issuer to create several Certificate resources for platform components.

Dex certificate for the UI

Mission Control mounts the Dex certificate into the ui and dex pods. This certificate encrypts traffic to the UI and requests that the UI forwards to Dex.

For example:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: mission-control-dex
  namespace: mission-control
spec:
  commonName: mission-control-dex
  dnsNames:
  - mission-control-dex
  duration: 8760h0m0s
  issuerRef:
    kind: Issuer
    name: mission-control-issuer
  renewBefore: 336h0m0s
  secretName: mission-control-dex-tls

If ingress.enabled is true, then the dnsNames list also includes ingress.regionDomain. For more information, see Platform ingress.

The UI does not enable hostname verification for this connection.

Deprecated certificate for the UI

Earlier versions of Mission Control used a certificate such as mission-control-ui-cert for UI access.

Current versions use the Dex certificate instead.

A future release will remove the UI certificate secret.

Grafana certificates

Mission Control creates a certificate named grafana-server-tls for Grafana.

This certificate secures traffic between Grafana and its sidecars. It also secures direct connections to Grafana.

If Values.ingress.enabled is true, the dnsNames list for this certificate also includes the Grafana hostname.

Loki and Mimir certificates

Mission Control creates certificates named loki-server-tls and mimir-server-tls.

Mission Control passes these certificates to Loki and Mimir to encrypt traffic between their components. Mission Control also mounts these certificates into the UI pod so that the UI can connect securely when it retrieves observability data.

Vector certificates

Mission Control configures Vector to use mutual TLS (mTLS). This configuration adds another layer of protection when data planes send observability data to the control plane.

Mission Control creates a server certificate. For example, mission-control-s-aggregator. The control plane Vector aggregator uses this certificate as its server certificate.

Mission Control also creates a client certificate. For example, mission-control-c-aggregator. Other Vector instances use this client certificate to connect to the aggregator.

Mission Control does not provide an automated way to replicate the client certificate to data planes.

To manually replicate the client certificate, do the following:

Set the control plane context:
```
CP_CONTEXT=CP_CONTEXT_NAME
kubectl config use-context "$CP_CONTEXT"
```
Replace CP_CONTEXT_NAME with the name of the context for your control plane cluster.
Fetch the aggregator client certificate secret, modify the metadata, and save it to a file:
```
kubectl get secret -n MISSION_CONTROL_NAMESPACE mission-control-aggregator-tls-client -o yaml | yq eval '.metadata |= {"namespace": .namespace, "name": "cp-mission-control-aggregator-tls-client"}' > cp-mission-control-aggregator-tls-client.yaml
```
Replace MISSION_CONTROL_NAMESPACE with the namespace where you installed Mission Control in the control plane.

This command creates a new secret named cp-mission-control-aggregator-tls-client.
Switch to the data plane context:
```
DP_CONTEXT=DP_CONTEXT_NAME
kubectl config use-context "$DP_CONTEXT"
```
Replace DP_CONTEXT_NAME with the name of the context for your data plane cluster.
If you haven’t installed Mission Control yet, create the namespace:
```
kubectl create namespace MISSION_CONTROL_NAMESPACE
```
Replace MISSION_CONTROL_NAMESPACE with the namespace where you want to install Mission Control in the data plane.
Apply the secret to the data plane:
```
kubectl apply -n MISSION_CONTROL_NAMESPACE -f cp-mission-control-aggregator-tls-client.yaml
```
Replace MISSION_CONTROL_NAMESPACE with the namespace where you installed Mission Control in the data plane.