Using Self-Signed Certificates with the Data Fabric Cluster

NOTE
In this article, the term tenant refers to Data Fabric tenants (formerly '"MapR tenants") and not to Kubernetes tenants unless explicitly noted otherwise on a case-by-case basis.

An initialization script generates private keys and self-signed certificates when a Data Fabric cluster is created. The edftool includes several commands that allow these certificates to be self-signed using the following workflow:

  1. Generate Certificate Signing Requests (CSRs) for the Data Fabric cluster services.
  2. Custom-sign the certificates.
  3. Import the signed public certificates back into the cluster and insert them into the ssl_keystore and ssl_truststore for each service.
  4. Restart each service.

Workflow

An initialization pod generates self-signed certificates for the services supported by the Data Fabric when you create the Data Fabric and apply the example CRs. This information is saved as secrets in the data-platform namespace. Each service pulls its specific private and public keys from those secrets during cluster deployment.



Self-signed certificates may not meet environment security requirements, such as requiring certificates signed by a Certificate Authority (CA). The following diagram illustrates how you can generate new public certificates, sign them, and import them into the cluster:



Use the edftool to generate CSRs for each service:

NOTE
The edftool uses a .cnf template file to generate the CSRs. By default, this template is stored in /opt/mapr/kubernetes/template.cnf . If needed, you can specify a different template file by executing the edftool gen-csrs command.
NOTE
Certificates cannot be updated individually. They must be updated for all the Data Fabric services at once.

  1. Execute the following command on either the Kubernetes cluster or the client where the edftool is installed:

    kubectl exec -it -n <pod-namespace> admincli-0 -- /bin/bash

  2. Execute the following command to allow the files to be created:

    cd /tmp

  3. Execute the following command:

    edftool gen-csrs
    The tool examines the current secrets, looks up each service, and determines the current signing status. For example:

  4. Enter yes at the following prompt to continue the process:

    Would you like to proceed? y/n:
  5. Execute the ls command to verify CSR generation. For example:

  6. Use the .csr files and your company-specific processes to generate new, signed public certificates for each Data Fabric service using SCP or another tool to export each .csr file to your CA-signing server. This process generates .crt files (certificates) for each .csr file.
  7. Use SCP or another tool to move the resulting .crt files to the working directory on the Data Fabric cluster.

  8. Import the new certificates and replace the secrets in the Data Fabric namespace for each service by executing the following command:

    edftool import-certs

  9. Enter yes at the following prompt to continue the process:

    Would you like to proceed? y/n:

  10. Restart the CLDB and Zookeeper pods by executing the edf update cluster command in the admincli-0 pod in /usr/bin. For example:

    kubectl exec -it admincli-0 -n <pod-namespace> -- /bin/bash
edf update cluster

  11. For the other services, delete the pod for the service to cause a replacement pod to start, initialize, and use the certificates by executing the following command:

    kubectl delete pod <service-pod-name>

    For example: 

    kubectl delete pod mcs-0