Deploy and Configure MongoDB Database Resources >
Configure the Kubernetes Operator for MongoDB Database Resources >
Create Credentials for the Kubernetes Operator

Create Credentials for the Kubernetes Operator¶

On this page

Prerequisites
Procedure

For the Kubernetes Operator to create or update objects in your Cloud Manager or Ops Manager Project, you need to store your Programmatic API Key in your secret storage tool.

Multiple secrets can exist in the same namespace. Each user should have their own secret.

You can follow the Procedure below to manually store the Programmatic API Key as a Kubernetes secret. Alternatively, you can:

Use the MongoDB Cloud Manager UI or the Ops Manager UI to automatically generate the Kubernetes secret YAML file, which you can then apply to your Kubernetes environment.
Store the Programmatic API Key as a Vault secret using the procedure to Create a Vault Secret. To use Vault, you must also configure the secret storage.

Prerequisites¶

To create credentials for the Kubernetes Operator, you must:

Have or create an Ops Manager Organization.
Have or generate a Programmatic API Key.
Grant this new Programmatic API Key:
- The Organization Owner role, if you want the Kubernetes Operator to create projects and manage them.
- The Project Owner role, if you want the Kubernetes Operator to only manage projects.
Add the IP or CIDR block of any hosts that serve the Kubernetes Operator to the API Access List.

Procedure¶

To create your Kubernetes secret:

1

Create a new Kubernetes secret¶

Ensure you have the Public and Private Keys for your desired Ops Manager Programmatic API Key.
Invoke the following Kubernetes command to create your secret:
copy
```
kubectl -n <metadata.namespace> \
create secret generic <mycredentials> \
--from-literal="publicKey=<publicKey>" \
--from-literal="privateKey=<privateKey>"
```
The -n flag limits the namespace to which this secret applies. All MongoDB Kubernetes resources must exist in the same namespace as the secrets and ConfigMaps. The Kubernetes Operator doesn’t use either the secrets or ConfigMaps.

Note

The deprecated version of this command specifies a user and publicApiKey instead of a publicKey and privateKey. Kubernetes Operator accepts either version for authentication.

2

Verify your new Kubernetes secret¶

Invoke the following Kubernetes command to verify your secret:

copy

kubectl describe secrets/<mycredentials> -n <metadata.namespace>

This command returns a secret description in the shell:

copy

Name:         <mycredentials>
Namespace:    <metadata.namespace>
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
privateKey:  31 bytes
publicKey:          22 bytes

← Configure the Kubernetes Operator for MongoDB Database Resources Create One Project using a ConfigMap →