Navigation

Considerations

On this page

Set MANAGED_SECURITY_CONTEXT for Kubernetes Operator OpenShift Deployments

When you deploy the Kubernetes Operator to OpenShift, you must set the MANAGED_SECURITY_CONTEXT flag to true. This value is set for you in the values-openshift.yaml file. To learn more, see the Operator installation and choose the installation method you want to use.

Understand the Default Permissions for Kubernetes Operator Objects

Objects in the Kubernetes Operator configuration use the following default permissions. These are the minumum permissions required for the Kubernetes Operator to deploy and manage Ops Manager and MongoDB resources in a Kubernetes cluster:

Kubernetes Resources Verbs
Configmaps

Require the following permissions:

  • get, list, watch. The Kubernetes Operator reads the organization and project data from the specified configmap.
  • create, update. The Kubernetes Operator creates and updates configmap objects for configuring the Application Database instances.
  • delete. The Kubernetes Operator needs the delete configmap permission to support its older versions. This permission will be deleted when older versions reach their End of Life Date.
Secrets

Require the following permissions:

  • get, list, watch. The Kubernetes Operator reads secret objects to retrieve sensitive data, such as TLS or X.509 access information. For example, it reads the credentials from a secret object to connect to the Ops Manager.
  • create, update. The Kubernetes Operator creates secret objects holding TLS or X.509 access information.
  • delete. The Kubernetes Operator deletes secret objects (containing passwords) related to the Application Database.
Services

Require the following permissions:

  • get, list, watch. The Kubernetes Operator reads and watches MongoDB services. For example, to communicate with the Ops Manager service, the Kubernetes Operator needs get, list and watch permissions to use the Ops Manager service’s URL.
  • create, update. To communicate with services, the Kubernetes Operator creates and updates service objects corresponding to Ops Manager and MongoDB custom resources.
StatefulSets

Require the following permissions:

  • get, list, watch. The Kubernetes Operator reacts to the changes in the StatefulSets it creates for the MongoDB custom resources. It also reads the fields of the StatefulSets it manages.
  • create, update. The Kubernetes Operator creates and updates StatefulSets corresponding to the mongoDB custom resources.
  • delete. The Kubernetes Operator needs permissions to delete the StatefulSets when you delete the MongoDB custom resource.
Pods

Require the following permissions:

  • get, list, watch. The Kubernetes Operator queries the Application Database Pods to get information about its state.
Namespaces

Require the following permissions:

  • list, watch. When you run the Kubernetes Operator in the cluster-wide mode, it needs list and watch permissions to all namespaces for the MongoDB custom resources.

Check Messages from the Validation Webhook

The Kubernetes Operator uses a validation Webhook to prevent users from applying invalid resource definitions. The webhook rejects invalid requests.

The ClusterRole and ClusterRoleBinding for the webhook are included in the default configuration files that you apply during the installation. To create the role and binding, you must have cluster-admin privileges.

If you create an invalid resource definition, the webhook returns a message similar to the following that describes the error to the shell:

error when creating "my-ops-manager.yaml":
admission webhook "ompolicy.mongodb.com" denied the request:
shardPodSpec field is not configurable for application databases as
it is for sharded clusters and appdb replica sets

When the Kubernetes Operator reconciles each resource, it also validates that resource. The Kubernetes Operator doesn’t require the validation webhook to create or update resources.

If you omit the validation webhook, or if you remove the webhook’s role and binding from the default configuration, or have insufficient privileges to run the configuration, the Kubernetes Operator issues warnings, as these are not critical errors. If the Kubernetes Operator encounters a critical error, it marks the resource as Failed.

GKE (Google Kubernetes Engine) deployments

GKE (Google Kubernetes Engine) has a known issue with the webhook when deploying to private clusters. To learn more, see Update Google Firewall Rules to Fix WebHook Issues.

Customize the CustomResourceDefinitions that the Kubernetes Operator Watches

Earlier versions of the Kubernetes Operator would crash on startup if any one of the MongoDB CustomResourceDefinitions was not present in the cluster. For instance, you had to install the CustomResourceDefinition for Ops Manager even if you did not plan to deploy it with the Kubernetes Operator.

You can now specify which custom resources you want the Kubernetes Operator to watch. This allows you to install the CustomResourceDefinition for only the resources that you want the Kubernetes Operator to manage.

You must use helm to configure the Kubernetes Operator to watch only the custom resources you specify. Follow the relevant helm installation instructions, but make the following adjustments:

  1. Decide which CustomResourceDefinitions you want to install. You can install any number of the following:

    Value Description
    mongodb Install the CustomResourceDefinitions for database resources and watch those resources.
    mongodbusers Install the CustomResourceDefinitions for MongoDB user resources and watch those resources.
    opsmanagers Install the CustomResourceDefinitions for Ops Manager resources and watch those resources.

  2. Install the Helm Chart and specify which CustomResourceDefinitions you want the Kubernetes Operator to watch.

    Separate each custom resource with a comma:

    copy 
    helm install <deployment-name> mongodb/enterprise-operator \
  --set operator.watchedResources="{mongodb,mongodbusers}" \
     --skip-crds

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.