Skip to content
logo
Percona Operator for MongoDB
Transport encryption (TLS/SSL)
Initializing search
    percona/k8spsmdb-docs
    percona/k8spsmdb-docs
    • Welcome
      • System requirements
      • Design and architecture
      • Comparison with other solutions
      • Install with Helm
      • Install with kubectl
      • Install on Minikube
      • Install on Google Kubernetes Engine (GKE)
      • Install on Amazon Elastic Kubernetes Service (AWS EKS)
      • Install on Microsoft Azure Kubernetes Service (AKS)
      • Generic Kubernetes installation
      • Install on OpenShift
      • Application and system users
      • Changing MongoDB options
      • Anti-affinity and tolerations
      • Labels and annotations
      • Exposing the cluster
      • Local storage support
      • Arbiter and non-voting nodes
      • MongoDB sharding
      • Transport encryption (TLS/SSL)
        • Install and use the cert-manager
          • About the cert-manager
          • Installation of the cert-manager
        • Generate certificates manually
        • Check your certificates for expiration
        • Run Percona Server for MongoDB without TLS
      • Data at rest encryption
      • Telemetry
        • About backups
        • Configure storage for backups
        • Making scheduled backups
        • Making on-demand backup
        • Storing operations logs for point-in-time recovery
        • Restore from a previously saved backup
        • Delete the unneeded backup
      • Upgrade MongoDB and the Operator
      • Horizontal and vertical scaling
      • Multi-cluster and multi-region deployment
      • Monitor with Percona Monitoring and Management (PMM)
      • Add sidecar containers
      • Restart or pause the cluster
      • Debug and troubleshoot
      • OpenLDAP integration
      • How to use private registry
      • Creating a private S3-compatible cloud for backups
      • Restore backup to a new Kubernetes-based environment
      • How to use backups to move the external database to Kubernetes
      • Install Percona Server for MongoDB in multi-namespace (cluster-wide) mode
      • Upgrading Percona Server for MongoDB manually
      • Custom Resource options
      • Percona certified images
      • Operator API
      • Frequently asked questions
      • Old releases (documentation archive)
      • Release notes index
      • Percona Operator for MongoDB 1.14.0 (2023-03-13)
      • Percona Operator for MongoDB 1.13.0 (2022-09-15)
      • Percona Operator for MongoDB 1.12.0 (2022-05-05)
      • Percona Distribution for MongoDB Operator 1.11.0 (2021-12-21)
      • Percona Distribution for MongoDB Operator 1.10.0 (2021-09-30)
      • Percona Distribution for MongoDB Operator 1.9.0 (2021-07-29)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.8.0 (2021-05-06)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.7.0 (2021-03-08)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.6.0 (2020-12-22)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.5.0 (2020-09-07)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.4.0 (2020-03-31)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.3.0 (2019-12-11)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.2.0 (2019-09-20)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.1.0 (2019-07-15)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.0.0 (2019-05-29)

    • Install and use the cert-manager
      • About the cert-manager
      • Installation of the cert-manager
    • Generate certificates manually
    • Check your certificates for expiration
    • Run Percona Server for MongoDB without TLS

    Transport Layer Security (TLS)¶

    The Percona Operator for MongoDB uses Transport Layer Security (TLS) cryptographic protocol for the following types of communication:

    • Internal - communication between Percona Server for MongoDB instances in the cluster
    • External - communication between the client application and the cluster

    The internal certificate is also used as an authorization method.

    Certificates for TLS security can be generated in several ways. By default, the Operator generates long-term certificates automatically if there are no certificate secrets available. Other options are the following ones:

    • the Operator can use a specifically installed cert-manager, which will automatically generate and renew short-term TLS certificates,
    • certificates can be generated manually.

    You can also use pre-generated certificates available in the deploy/ssl-secrets.yaml file for test purposes, but we strongly recommend avoiding their usage on any production system!

    The following subsections explain how to configure TLS security with the Operator yourself, as well as how to temporarily disable it if needed.

    Install and use the cert-manager¶

    About the cert-manager¶

    The cert-manager is a Kubernetes certificate management controller which widely used to automate the management and issuance of TLS certificates. It is community-driven, and open source.

    When you have already installed cert-manager and deploy the operator, the operator requests a certificate from the cert-manager. The cert-manager acts as a self-signed issuer and generates certificates. The Percona Operator self-signed issuer is local to the operator namespace. This self-signed issuer is created because Percona Server for MongoDB requires all certificates issued by the same CA (Certificate authority).

    Self-signed issuer allows you to deploy and use the Percona Operator without creating a cluster issuer separately.

    Installation of the cert-manager¶

    The steps to install the cert-manager are the following:

    • create a namespace,
    • disable resource validations on the cert-manager namespace,
    • install the cert-manager.

    The following commands perform all the needed actions:

    $ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.8.0/cert-manager.yaml --validate=false
    

    After the installation, you can verify the cert-manager by running the following command:

    $ kubectl get pods -n cert-manager
    

    The result should display the cert-manager and webhook active and running:

    NAME                                       READY   STATUS    RESTARTS   AGE
    cert-manager-7d59dd4888-tmjqq              1/1     Running   0          3m8s
    cert-manager-cainjector-85899d45d9-8ncw9   1/1     Running   0          3m8s
    cert-manager-webhook-84fcdcd5d-697k4       1/1     Running   0          3m8s
    

    Once you create the database with the Operator, it will automatically trigger cert-manager to create certificates. Whenever you check certificates for expiration, you will find that they are valid and short-term.

    Generate certificates manually¶

    To generate certificates manually, follow these steps:

    1. Provision a Certificate Authority (CA) to generate TLS certificates,
    2. Generate a CA key and certificate file with the server details,
    3. Create the server TLS certificates using the CA keys, certs, and server details.

    The set of commands generate certificates with the following attributes:

    • Server-pem - Certificate
    • Server-key.pem - the private key
    • ca.pem - Certificate Authority

    You should generate certificates twice: one set is for external communications, and another set is for internal ones. A secret created for the external use must be added to the spec.secrets.ssl key of the deploy/cr.yaml file. A certificate generated for internal communications must be added to the spec.secrets.sslInternal key of the deploy/cr.yaml file.

    Supposing that your cluster name is my-cluster-name, the instructions to generate certificates manually are as follows:

    $ CLUSTER_NAME=my-cluster-name
    $ NAMESPACE=default
    $ cat <<EOF | cfssl gencert -initca - | cfssljson -bare ca
      {
        "CN": "Root CA",
        "names": [
          {
            "O": "PSMDB"
          }
        ],
        "key": {
          "algo": "rsa",
          "size": 2048
        }
      }
    EOF
    
    $ cat <<EOF > ca-config.json
      {
        "signing": {
          "default": {
            "expiry": "87600h",
            "usages": ["signing", "key encipherment", "server auth", "client auth"]
          }
        }
      }
    EOF
    
    $ cat <<EOF | cfssl gencert -ca=ca.pem  -ca-key=ca-key.pem -config=./ca-config.json - | cfssljson -bare server
      {
        "hosts": [
          "localhost",
          "${CLUSTER_NAME}-rs0",
          "${CLUSTER_NAME}-rs0.${NAMESPACE}",
          "${CLUSTER_NAME}-rs0.${NAMESPACE}.svc.cluster.local",
          "*.${CLUSTER_NAME}-rs0",
          "*.${CLUSTER_NAME}-rs0.${NAMESPACE}",
          "*.${CLUSTER_NAME}-rs0.${NAMESPACE}.svc.cluster.local"
        ],
        "names": [
          {
            "O": "PSMDB"
          }
        ],
        "CN": "${CLUSTER_NAME/-rs0}",
        "key": {
          "algo": "rsa",
          "size": 2048
        }
      }
    EOF
    $ cfssl bundle -ca-bundle=ca.pem -cert=server.pem | cfssljson -bare server
    
    $ kubectl create secret generic my-cluster-name-ssl-internal --from-file=tls.crt=server.pem --from-file=tls.key=server-key.pem --from-file=ca.crt=ca.pem --type=kubernetes.io/tls
    
    $ cat <<EOF | cfssl gencert -ca=ca.pem  -ca-key=ca-key.pem -config=./ca-config.json - | cfssljson -bare client
      {
        "hosts": [
          "${CLUSTER_NAME}-rs0",
          "${CLUSTER_NAME}-rs0.${NAMESPACE}",
          "${CLUSTER_NAME}-rs0.${NAMESPACE}.svc.cluster.local",
          "*.${CLUSTER_NAME}-rs0",
          "*.${CLUSTER_NAME}-rs0.${NAMESPACE}",
          "*.${CLUSTER_NAME}-rs0.${NAMESPACE}.svc.cluster.local"
        ],
        "names": [
          {
            "O": "PSMDB"
          }
        ],
        "CN": "${CLUSTER_NAME/-rs0}",
        "key": {
          "algo": "rsa",
          "size": 2048
        }
      }
    EOF
    
    $ kubectl create secret generic my-cluster-name-ssl --from-file=tls.crt=client.pem --from-file=tls.key=client-key.pem --from-file=ca.crt=ca.pem --type=kubernetes.io/tls
    

    Check your certificates for expiration¶

    1. First, check the necessary secrets names (my-cluster-name-ssl and my-cluster-name-ssl-internal by default):

      $ kubectl get certificate
      

      You will have the following response:

      NAME                           READY   SECRET                         AGE
      my-cluster-name-ssl            True    my-cluster-name-ssl            49m
      my-cluster-name-ssl-internal   True    my-cluster-name-ssl-internal   49m
      
    2. Optionally you can also check that the certificates issuer is up and running:

      $ kubectl get issuer
      

      The response should be as follows:

      NAME                       READY   AGE
      my-cluster-name-psmdb-ca   True    61s
      
    3. Now use the following command to find out the certificates validity dates, substituting Secrets names if necessary:

      $ {
        kubectl get secret/my-cluster-name-ssl-internal -o jsonpath='{.data.tls\.crt}' | base64 --decode | openssl x509 -noout -dates
        kubectl get secret/my-cluster-name-ssl -o jsonpath='{.data.ca\.crt}' | base64 --decode | openssl x509 -noout -dates
        }
      

      The resulting output will be self-explanatory:

      notBefore=Apr 25 12:09:38 2022 GMT notAfter=Jul 24 12:09:38 2022 GMT
      notBefore=Apr 25 12:09:38 2022 GMT notAfter=Jul 24 12:09:38 2022 GMT
      

    Run Percona Server for MongoDB without TLS¶

    Omitting TLS is also possible, but we recommend that you run your cluster with the TLS protocol enabled.

    To disable TLS protocol (e.g. for demonstration purposes) set the spec.allowUnsafeConfigurations key to true in the deploy/cr.yaml file and and make sure that there are no certificate secrets available.

    Warning

    Normally, the Operator prevents users from configuring a cluster with unsafe parameters (starting it with less than 3 replica set instances or without TLS, etc.), automatically changing such unsafe parameters to safe defaults. If you switch the cluster to the unsafe configurations permissive mode, you will not be able to switch it back by setting spec.allowUnsafeConfigurations key to false, the flag will be ignored.

    Contact Us

    For free technical help, visit the Percona Community Forum.

    To report bugs or submit feature requests, open a JIRA ticket.

    For paid support and managed or consulting services , contact Percona Sales.


    Last update: 2023-03-22
    Percona LLC and/or its affiliates, © 2009 - 2023
    Made with Material for MkDocs

    Cookie consent

    We use cookies to recognize your repeated visits and preferences, as well as to measure the effectiveness of our documentation and whether users find what they're searching for. With your consent, you're helping us to make our documentation better.