NebulaGraph supports data transmission with SSL encryption between clients, the Graph service, the Meta service, and the Storage service. This topic describes how to enable SSL encryption.
NebulaGraph supports four encryption policies:
-
Encrypt the data transmission between clients, the Graph service, the Meta service, and the Storage service.
To enable this policy, addenable_ssl = true
to each component.apiVersion: apps.nebula-graph.io/v1alpha1 kind: NebulaCluster metadata: name: nebula namespace: default spec: sslCerts: serverSecret: "server-cert" clientSecret: "client-cert" caSecret: "ca-cert" graphd: config: enable_ssl: "true" metad: config: enable_ssl: "true" storaged: config: enable_ssl: "true"
-
Encrypt the data transmission between clients and the Graph service.
This policy is applicable when the clusters are set up in the same server room. Only the port of the Graph service is open to the outside, as other services can communicate over the internal network without encryption. To enable this policy, addenable_graph_ssl = true
to the graphd component.apiVersion: apps.nebula-graph.io/v1alpha1 kind: NebulaCluster metadata: name: nebula namespace: default spec: sslCerts: serverSecret: "server-cert" caSecret: "ca-cert" graphd: config: enable_graph_ssl: "true"
-
Encrypt the data transmission related to the Meta service in the cluster.
This policy applies to transporting classified information to the Meta service. To enable this policy, addenable_meta_ssl = true
to each component.apiVersion: apps.nebula-graph.io/v1alpha1 kind: NebulaCluster metadata: name: nebula namespace: default spec: sslCerts: serverSecret: "server-cert" clientSecret: "client-cert" caSecret: "ca-cert" graphd: config: enable_meta_ssl: "true" metad: config: enable_meta_ssl: "true" storaged: config: enable_meta_ssl: "true"
-
Encrypt the data transmission related to the Storage service in the cluster.
This policy applies to transporting classified information to the Storage service. To enable this policy, addenable_storage_ssl = true
to each component.apiVersion: apps.nebula-graph.io/v1alpha1 kind: NebulaCluster metadata: name: nebula namespace: default spec: sslCerts: serverSecret: "server-cert" clientSecret: "client-cert" caSecret: "ca-cert" graphd: config: enable_storage_ssl: "true" metad: config: enable_storage_ssl: "true" storaged: config: enable_storage_ssl: "true"
The Kubernetes community has provided a standard method to store certificates and associated keys in secrets.
An example is the popular cert-manager. To comply with the standard,
we have provided such functionality in nebula-operator to allow users to specify the certs stored in secrets
in sslCerts
.
Users need to manage the certs stored in Kubernetes secrets
themselves.
The full configuration of sslCerts:
sslCerts:
# Name of the server cert secret
serverSecret: "server-cert"
# The key to server PEM encoded public key certificate, default name is tls.crt
serverCert: ""
# The key to server private key associated with given certificate, default name is tls.key
serverKey: ""
# Name of the client cert secret
clientSecret: "client-cert"
# The key to server PEM encoded public key certificate, default name is tls.crt
clientCert: ""
# The key to client private key associated with given certificate, default name is tls.key
clientKey: ""
# Name of the CA cert secret
caSecret: "ca-cert"
# The key to CA PEM encoded public key certificate, default name is ca.crt
caCert: ""
# InsecureSkipVerify controls whether a client verifies the server's certificate chain and host name
insecureSkipVerify: false
# ServerName is used to verify the hostname on the returned certificates unless InsecureSkipVerify is given.
# It is also included in the client's handshake to support virtual hosting unless it is an IP address.
serverName: ""
# AutoMountServerCerts controls whether operator mounts server's certificate from secret.
autoMountServerCerts: false
The nebula-operator chart supports the configuration of init-container, sidecar-container, volumes, and volumeMounts in the controller-manager Pod.
It reads the certificates generated by sidecar-container through the environment variables CA_CERT_PATH, CLIENT_CERT_PATH, and CLIENT_KEY_PATH.
If you can provide a program to generate certificates, then you need put the sidecar-container and the controller-manager container in the same Pod
and share the certificate directory credentials
. The controller-manager reads the client-side certificates from the environments then establishes
an mTLS connection with the nebula service.
Below is the controller-manager related configuration block in nebula-operator chart values.yaml, nebula-certs is the sidecar-container that generates and rotates certificates.
controllerManager:
env:
- name: CA_CERT_PATH
value: /credentials/root.crt
- name: CLIENT_CERT_PATH
value: /credentials/client.crt
- name: CLIENT_KEY_PATH
value: /credentials/client.key
## Additional InitContainers to initialize the pod
extraInitContainers:
- name: init-auth-sidecar
command:
- /bin/sh
- -c
args:
- cp -R /certs/* /credentials/
imagePullPolicy: Always
image: reg.vesoft-inc.com/cloud-dev/nebula-certs:latest
volumeMounts:
- name: credentials
mountPath: /credentials
# sidecarContainers - add more containers to controller-manager
# Key/Value where Key is the sidecar `- name: <Key>`
sidecarContainers:
auth-sidecar:
imagePullPolicy: Always
image: reg.vesoft-inc.com/cloud-dev/nebula-certs:latest
volumeMounts:
- name: credentials
mountPath: /credentials
## Additional controller-manager Volumes
extraVolumes:
- name: credentials
emptyDir:
medium: Memory
## Additional controller-manager Volume mounts
extraVolumeMounts:
- name: credentials
mountPath: /credentials