Internode encryption

Mission Control can manage and orchestrate internode encryption for DataStax Enterprise (DSE), Hyper-Converged Database (HCD), and Apache Cassandra® clusters. Mission Control also supports using a root Certificate Authority (CA) that you provide. In this case, Mission Control uses an existing certificate issuer referenced in the cluster definition. When create a new Mission Control cluster, Mission Control generates a new certificate for each node and signs it with the cluster’s root CA. It next generates the keystore and truststore for each node and configures the cluster to use them.

For more information about managing certificates and CAs, see Manage Mission Control certificate and certificate authority (CA) expiration.

Mission Control supports the following scenarios:

Use the CA issuer designated by Mission Control
No internode encryption
Use an alternate issuer supported by Cert-Manager

No internode encryption

Internode encryption can be disabled by setting the .spec.encryption.internodeEncryption.enabled field to false and disabling the certificate issuer creation in the MissionControlCluster spec with .spec.createIssuer set to false:

apiVersion: missioncontrol.datastax.com/v1beta2
kind: MissionControlCluster
metadata:
  name: test-cluster
  namespace: NAMESPACE
spec:
  createIssuer: false
  encryption:
    internodeEncryption:
      enabled: false
  k8ssandra:
    cassandra:
      serverVersion: SERVER_VERSION
      serverType: SERVER_TYPE
      storageConfig:
        cassandraDataVolumeClaimSpec:
          storageClassName: standard
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 5Gi
      config:
        jvmOptions:
          heapSize: 512M
      datacenters:
        - metadata:
            name: dc1
          size: 3
          resources:
            requests:
              memory: 1Gi

Replace the following:

NAMESPACE: The namespace where the cluster is deployed.
SERVER_VERSION: The version of the server, for example 6.9.12 for DSE or 1.1.0 for HCD
SERVER_TYPE: The type of the server, for example dse or hcd

Apply this updated MissionControlCluster resource by running the following command:

kubectl apply -f test-cluster.missioncontrolcluster.yaml

Mission Control-provided root CA generation and self-signing

A certificate authority (CA) is a trusted entity that stores, signs, and issues Transport Layer Security (TLS) certificates.

Create a MissionControlCluster resource by copying the following manifest and saving it in a file named test-cluster.missioncontrolcluster.yaml:

apiVersion: missioncontrol.datastax.com/v1beta2
kind: MissionControlCluster
metadata:
  name: test-cluster
  namespace: NAMESPACE
spec:
  k8ssandra:
    cassandra:
      serverVersion: SERVER_VERSION
      serverType: SERVER_TYPE
      storageConfig:
        cassandraDataVolumeClaimSpec:
          storageClassName: standard
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 5Gi
      config:
        jvmOptions:
          heapSize: 512M
      datacenters:
        - metadata:
            name: dc1
          size: 3
          resources:
            requests:
              memory: 1Gi

Replace the following:

NAMESPACE: The namespace where the cluster is deployed.
SERVER_VERSION: The version of the server, for example 6.9.12 for DSE or 1.1.0 for HCD
SERVER_TYPE: The type of the server, for example dse or hcd

Run the following command to apply the newly-created MissionControlCluster resource:
```
kubectl apply -f test-cluster.missioncontrolcluster.yaml
```
The generated root CA secret is created within a few seconds.

Run the following command to reveal the secret:

kubectl get secrets -n mission-control |grep internode

Result

NAME                                                    TYPE                                  DATA   AGE
mission-control-test-inode-selfsigned-ca-cert           kubernetes.io/tls                     3      12s

Generated next are the cluster’s certificate secrets which are signed by the root CA.

Run the following command to reveal the certificate secrets:

kubectl get secrets -n mission-control |grep inode

Result

NAME                                                    TYPE                                  DATA   AGE
mission-control-test-inode-selfsigned-ca-cert           kubernetes.io/tls                     3      27s
test-dc1-default-sts-0-inode-cert                       kubernetes.io/tls                     3      12s
test-dc1-default-sts-0-inode-cert-keystore              Opaque                                2      12s
test-dc1-default-sts-1-inode-cert                       kubernetes.io/tls                     3      11s
test-dc1-default-sts-1-inode-cert-keystore              Opaque                                2      11s
test-dc1-default-sts-2-inode-cert                       kubernetes.io/tls                     3      12s
test-dc1-default-sts-2-inode-cert-keystore              Opaque                                2      12s

The -keystore secrets are mounted appropriately in the HCD, DSE, or Cassandra pods. The pods should then start within a few minutes.

Optional: Run the following kubectl command to check the pods' status:

kubectl get pods

Result

NAME                   READY STATUS   RESTARTS AGE
test-dc1-default-sts-0 2/2   Running  0        18m
test-dc1-default-sts-1 2/2   Running  0        18m
test-dc1-default-sts-2 2/2   Running  0        18m

Use an alternate issuer supported by Cert-Manager

Mission Control supports using any alternative issuer in turn supported by cert-manager. Cert-Manager is an API used by K8ssandra to manage Transport Layer Security (TLS). Starting with the v1.0.0-beta.1 release of Mission Control, the following issuers are supported:

Vault
Venafi
ACME, which allows relying on Let’s Encrypt
A wide range of external issuers

To use one of these alternative issuers, create it using the standard https://cert-manager.io/docs/configuration/ [Cert-Manager API] and then reference it as follows in the MissionControlCluster spec.

Save the specification in a file named cluster.MissionControlCluster.yaml:

apiVersion: missioncontrol.datastax.com/v1beta2
kind: MissionControlCluster
metadata:
  name: cluster
  namespace: NAMESPACE
spec:
  createIssuer: false
  encryption:
    internodeEncryption:
      certs:
        certTemplate:
          issuerRef:
            name: my-alternate-issuer
  k8ssandra:
    cassandra:
      serverVersion: SERVER_VERSION
      serverType: SERVER_TYPE
      storageConfig:
        cassandraDataVolumeClaimSpec:
          storageClassName: standard
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 5Gi
      config:
        jvmOptions:
          heapSize: 512M
      datacenters:
        - metadata:
            name: dc1
          size: 3
          resources:
            requests:
              memory: 1Gi

Replace the following:

NAMESPACE: The namespace where the cluster is deployed.
SERVER_VERSION: The version of the server, for example 6.9.12 for DSE or 1.1.0 for HCD
SERVER_TYPE: The type of the server, for example dse or hcd

Run the following command to apply the newly-created cluster.MissionControlCluster.yaml file:
```
kubectl apply -f cluster.MissionControlCluster.yaml
```
Within moments a set of secrets should be created with certificates (secrets ending with -cert) that are automatically generated and signed by the root CA.

Run the following command to reveal the secrets (where inode is an alias for internode):

kubectl get secrets -n mission-control |grep inode

Result

test-dc1-default-sts-0-inode-cert                       kubernetes.io/tls                     3      11m
test-dc1-default-sts-0-inode-cert-keystore              Opaque                                2      11m
test-dc1-default-sts-1-inode-cert                       kubernetes.io/tls                     3      11m
test-dc1-default-sts-1-inode-cert-keystore              Opaque                                2      11m
test-dc1-default-sts-2-inode-cert                       kubernetes.io/tls                     3      11m
test-dc1-default-sts-2-inode-cert-keystore              Opaque                                2      11m

The -keystore secrets are mounted appropriately in the HCD, DSE, or Cassandra pods. The pods should then start within a few minutes.

Optional: Run the following kubectl command to check the pods' status:

kubectl get pods

Result

NAME                   READY STATUS   RESTARTS AGE
test-dc1-default-sts-0 2/2   Running  0        18m
test-dc1-default-sts-1 2/2   Running  0        18m
test-dc1-default-sts-2 2/2   Running  0        18m

Internode encryption

No internode encryption

Mission Control-provided root CA generation and self-signing

Use an alternate issuer supported by Cert-Manager

Was this helpful?

Give Feedback