- Deploy and Configure Ops Manager Resources >
- Secure Application Database using TLS
Secure Application Database using TLS¶
On this page
The MongoDB Enterprise Kubernetes Operator can use TLS certificates to encrypt connections between members of the application database replica set.
Prerequisites¶
Before you secure your application database using TLS encryption, complete the following:
Deploy the Ops Manager application that you want to secure.
Create one TLS certificate for the Application Database’s replica set.
This TLS certificate requires the following attributes:
DNS Names Ensure that you add SANs or Subject Names for each Pod that hosts a member of the Application Database replica set. The SAN for each pod must use the following format:
Key Usages Ensure that the TLS certificates include the following key-usages (5280):
- “server auth”
- “client auth”
Important
For fresh Kubernetes Operator installations starting with version 1.13, the Kubernetes Operator uses kubernetes.io/tls secrets to store TLS certificates and private keys for Ops Manager and MongoDB resources.
Previous Kubernetes Operator versions required you to concatenate your TLS certificates and private keys into a PEM file and store this file in an Opaque secret.
To maintain backwards compatibility, the Kubernetes Operator continues to support storing PEM files in Opaque secrets. Support of this feature might be removed in a future release.
We recommend that you upgrade to Kubernetes Operator version 1.15.1 or later.
If you have a broken Application Database after upgrading to Kubernetes Operator version 1.14.0 or 1.15.0, see Ops Manager in Failed State.
Procedure¶
Create a secret with your Application Database TLS certificate.¶
Run this kubectl
command to create a new secret that stores
the Application Database’s TLS certificate:
If you’re using HashiCorp Vault as your secret storage tool, you can Create a Vault Secret instead.
To learn about your options for secret storage, see Configure Secret Storage.
Optional: Create a ConfigMap that contains the Certificate Authority.¶
You must provide a CA certificate when the CA that signed the certificates might be not “recognized” as an official authority. You can create valid certificates with cert-manager or HashiCorp Vault.
If you signed the certificates using a Kubernetes certificate management tool, such as cert-manager or HashiCorp Vault, you must create a ConfigMap containing the CA’s certificate file.
If you output the certificate as a file, name this file ca-pem
.
This simplifies creating the ConfigMap.
Warning
You must concatenate your custom CA file and the entire
TLS certificate chain from downloads.mongodb.com
to prevent
Ops Manager from becoming inoperable if the application database
restarts.
Obtain the entire TLS certificate chain from
downloads.mongodb.com
. The followingopenssl
command outputs each certificate in the chain to your current working directory, in.crt
format:Concatenate your CA’s certificate file with the entire TLS certificate chain from
downloads.mongodb.com
that you obtained in the previous step:Create the ConfigMap:
This creates a ConfigMap named ca
. This
ConfigMap contains one entry called ca-pem
with the
contents of the CA file and the certificate chain for
downloads.mongodb.com
.
Specify the Secret with certificates to the Ops Manager yaml definition.¶
Note
The Kubernetes Operator mounts the CA you add using the
spec.applicationDatabase.security.tls.ca
setting to
both the Ops Manager and the Application Database pods.
Apply changes to your Ops Manager deployment.¶
Invoke the following kubectl
command on the filename of the
Ops Manager resource definition:
Track the status of your Ops Manager instance.¶
To check the status of your Ops Manager resource, invoke the following command:
When Ops Manager is running, the command returns the following
output under the status
field:
See Troubleshoot the Kubernetes Operator for information about the resource deployment statuses.