There are various ways to backup and restore Percona Server for MongoDB clusters when you run them on Kubernetes. Percona Operator for MongoDB utilizes Percona Backup for MongoDB (PBM) to take physical and logical backups, continuously upload oplogs to object storage, and maintain the backup lifecycle. Cloud providers and various storage solutions provide the capability […]
08
2024
Unlocking the Power of Cloud Snapshots: Backup and Restore Your MongoDB Clusters on Kubernetes
12
2024
Simplify User Management with Percona Operator for MongoDB
Managing database users within complex CICD pipelines and GitOps workflows has long been a challenge for MongoDB deployments. With Percona Operator for MongoDB 1.17, we introduce a new feature, currently in technical preview, that streamlines this process. Now, you can create the database users you need directly within the operator, eliminating the need to wait […]
27
2024
Adding TLS to LDAP Authentication in Percona Operator for MongoDB
As per K8SPSMDB-732, TLS is now supported with LDAP authentication on Percona Operator for MongoDB 1.16.0 and above. This feature has been documented here as well. I’ve written a previous article on using LDAP authentication and authorization without TLS, so let me provide the instructions here on incorporating TLS with LDAP. First, you need to […]
26
2024
Benchmarking MongoDB Performance on Kubernetes
Cloud-native databases are becoming the norm, and containerized databases are a common trend (see the report from Dynatrace and Figure 1). Kubernetes—the de facto standard for platform engineers—and operators simplify database deployment and management. But what are the performance implications of running databases in Kubernetes? To answer this question, we compared the performance of Percona Server for […]
19
2022
Testing LDAP Authentication and Authorization on Percona Operator for MongoDB
As of Percona Operator for MongoDB 1.12.0, the documentation now has instructions on how to configure LDAP Authentication and Authorization. It already contains an example of how to configure the operator if OpenLDAP is your LDAP server. Here is another example of setting it up but using Samba as your LDAP server.
To simplify the installation and configuration, I will use Ubuntu Jammy 22.04 LTS since the distribution repository contains the packages to install Samba and Kubernetes.
This is the current configuration of the test server:
OS: Ubuntu Jammy 22.04 LTS
Hostname: samba.percona.local
IP Address: 192.168.0.101
Setting up Samba
Let’s install the necessary packages to install Samba as PDC and troubleshooting tools:
$ sudo apt update $ sudo apt -y upgrade $ sudo apt -y install samba net-tools winbind ldap-utils
Disable smbd, winbind, and systemd-resolved services because we will need to reconfigure samba as a PDC and DNS resolver. Also remove current samba configuration, /etc/samba/smb.conf.
$ sudo systemctl stop smbd $ sudo systemctl stop systemd-resolved $ sudo systemctl stop winbind $ sudo systemctl disable smbd $ sudo systemctl disable systemd-resolved $ sudo systemctl disable winbind $ sudo rm /etc/samba/smb.conf
Delete the symlink on /etc/resolv.conf and replace the content with “nameserver 127.0.0.1” to use the samba’s DNS service:
$ sudo rm -f /etc/resolv.conf $ sudo echo -e "nameserver 127.0.0.1" | sudo tee /etc/resolv.conf
Create a domain environment with the following settings:
Realm: PERCONA.LOCAL
Domain: PERCONA
Administrator Password: PerconaLDAPTest2022
$ sudo samba-tool domain provision --realm percona.local --domain percona --admin=PerconaLDAPTest2022
Edit /etc/samba/smb.conf and set DNS forwarder to 8.8.8.8 to resolve other zones. We will also disable mandatory TLS authentication since Percona Operator does not support LDAP with TLS at the time of writing this article.
$ cat /etc/samba/smb.conf # Global parameters [global] dns forwarder = 8.8.8.8 netbios name = SAMBA realm = PERCONA.LOCAL server role = active directory domain controller workgroup = PERCONA ldap server require strong auth = No [sysvol] path = /var/lib/samba/sysvol read only = No [netlogon] path = /var/lib/samba/sysvol/percona.local/scripts read only = No
Symlink krb5.conf configuration.
$ sudo ln -s /var/lib/samba/private/krb5.conf /etc
Unmask samba-ad-dc service and start it. Ensure it will start at boot time.
$ sudo systemctl unmask samba-ad-dc $ sudo systemctl start samba-ad-dc $ sudo systemctl enable samba-ad-dc
Check if the Samba services are up and running
$ sudo netstat -tapn|grep samba tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 4376/samba: task[ld tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 4406/samba: task[dn tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 4376/samba: task[ld tcp 0 0 0.0.0.0:135 0.0.0.0:* LISTEN 4371/samba: task[rp tcp6 0 0 :::389 :::* LISTEN 4376/samba: task[ld tcp6 0 0 :::53 :::* LISTEN 4406/samba: task[dn tcp6 0 0 :::636 :::* LISTEN 4376/samba: task[ld tcp6 0 0 :::135 :::* LISTEN 4371/samba: task[rp $ host google.com google.com has address 172.217.194.101 $ host samba.percona.local samba.percona.local has address 192.168.0.101
Adding users and groups
Now that Samba is up and running, we can now perform user and group management. We will create Samba users and groups and assign users to groups with samba-tool.
$ sudo samba-tool user add dbauser01 --surname=User01 --given-name=Dba --mail-address=dbauser01@percona.local DbaPassword1 $ sudo samba-tool user add devuser01 --surname=User01 --given-name=Dev --mail-address=devuser01@percona.local DevPassword1 $ sudo samba-tool user add searchuser01 --surname=User01 --given-name=Search --mail-address=searchuser01@percona.local SearchPassword1 $ sudo samba-tool group add developers $ sudo samba-tool group add dbadmins $ sudo samba-tool group addmembers developers devuser01 $ sudo samba-tool group addmembers dbadmins dbauser01
Use samba-tool again to view the details of the users and groups:
$ sudo samba-tool user show devuser01 dn: CN=Dev User01,CN=Users,DC=percona,DC=local objectClass: person objectClass: user cn: Dev User01 sn: User01 givenName: Dev name: Dev User01 sAMAccountName: devuser01 mail: devuser01@percona.local memberOf: CN=developers,CN=Users,DC=percona,DC=local $ sudo samba-tool group show dbadmins dn: CN=dbadmins,CN=Users,DC=percona,DC=local objectClass: group cn: dbadmins name: dbadmins sAMAccountName: dbadmins member: CN=Dba User01,CN=Users,DC=percona,DC=local
Searching with ldapsearch
Troubleshooting LDAP starts with being able to use the ldapsearch tool to specify the credentials and filters. Once you are successful with authentication and searching, it’s easier to plug the same or similar parameters used in ldapsearch in the configuration of the Percona operator. Here are some examples of useful ldapsearch commands:
1. Logging in as “CN=Dev User01,CN=Users,DC=percona,DC=local”. If authenticated, return the DN, First Name, Last Name, email and sAMAccountName for that record.
$ ldapsearch -LLL -W -x -H ldap://samba.percona.local -b "CN=Dev User01,CN=Users,DC=percona,DC=local" -D "CN=Dev User01,CN=Users,DC=percona,DC=local" "givenName" "sn" "mail" "sAMAccountName" Enter LDAP Password: dn: CN=Dev User01,CN=Users,DC=percona,DC=local sn: User01 givenName: Dev sAMAccountName: devuser01 mail: devuser01@percona.local
Essentially, without mapping,you will need to supply the username as the full DN to login to MongoDB. Eg. mongo -u “CN=Dev User01,CN=Users,DC=percona,DC=local”
2. Logging in as “CN=Search User01,CN=Users,DC=percona,DC=local” and looking for users in “DC=percona,dc=local” where sAMAccountName is “dbauser01”. If there’s a match, it will return the DN, First Name, Last Name, mail and sAMAccountName for that record.
$ ldapsearch -LLL -W -x -H ldap://samba.percona.local -b "DC=percona,dc=local" -D "CN=Search User01,CN=Users,DC=percona,DC=local" "(&(objectClass=person)(sAMAccountName=dbauser01))" "givenName" "sn" "mail" "sAMAccountName" Enter LDAP Password: dn: CN=Dba User01,CN=Users,DC=percona,DC=local sn: User01 givenName: Dba sAMAccountName: dbauser01 mail: dbauser01@percona.local
With mapping, you can now authenticate by specifying sAMAaccountName or mail depending on how mapping is defined. Eg. mongo -u dbauser01 or mongo -u “dbauser01@percona.local”
3. Logging in as “CN=Search User01,CN=Users,DC=percona,DC=local”, looking for groups in “DC=percona,dc=local” where “CN=Dev User01,CN=Users,DC=percona,DC=local” is a member. If there’s a match, it will return the DN and common name of the group.
$ ldapsearch -LLL -W -x -H ldap://samba.percona.local -b "DC=percona,dc=local" -D "CN=Search User01,CN=Users,DC=percona,DC=local" "(&(objectClass=group)(member=CN=Dev User01,CN=Users,DC=percona,DC=local))" "cn" Enter LDAP Password: dn: CN=developers,CN=Users,DC=percona,DC=local cn: developers
This type of search is important to enumerate the groups of that user for we can define the privileges of that user based on its group membership.
Kubernetes installation and configuration
Now that authenticating to LDAP and search filters are working, we are ready to test this in the Percona Operator. Since this is just for testing, we might as well use the same server to deploy Kubernetes. In this example, we will use Microk8s.
$ sudo snap install microk8s --classic $ sudo usermod -a -G microk8s $USER $ sudo chown -f -R $USER ~/.kube $ newgrp microk8s $ microk8s status --wait-ready $ microk8s enable dns $ microk8s enable hostpath-storage $ alias kubectl='microk8s kubectl'
Once installed, check system pods when all are running before we continue to the next step:
$ kubectl get pods --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE kube-system calico-node-bj9c4 1/1 Running 0 3m12s kube-system coredns-66bcf65bb8-l9hwb 1/1 Running 0 65s kube-system calico-kube-controllers-644d5c79cb-fhhkc 1/1 Running 0 3m11s kube-system hostpath-provisioner-85ccc46f96-qmjrq 1/1 Running 0 3m
Deploying the Percona Operator for MongoDB
Now that Kubernetes is running, we can download the Percona Operator for MongoDB. Let’s download version 1.13.0 with git:
$ git clone -b v1.13.0 https://github.com/percona/percona-server-mongodb-operator
Then let’s go to the deploy directory and apply bundle.yaml to install the Percona operator:
$ cd percona-server-mongodb-operator/deploy $ kubectl apply -f bundle.yaml customresourcedefinition.apiextensions.k8s.io/perconaservermongodbs.psmdb.percona.com created customresourcedefinition.apiextensions.k8s.io/perconaservermongodbbackups.psmdb.percona.com created customresourcedefinition.apiextensions.k8s.io/perconaservermongodbrestores.psmdb.percona.com created role.rbac.authorization.k8s.io/percona-server-mongodb-operator created serviceaccount/percona-server-mongodb-operator created rolebinding.rbac.authorization.k8s.io/service-account-percona-server-mongodb-operator created deployment.apps/percona-server-mongodb-operator created
Check if the operator is up and running:
$ kubectl get pods NAME READY STATUS RESTARTS AGE percona-server-mongodb-operator-547c499bd8-p8k74 1/1 Running 0 41s
Now that it is running we need to apply cr.yaml to create the MongoDB instances and services. We will just use minimal deployment in cr-minimal.yaml which is provided in the deploy directory.
$ kubectl apply -f cr-minimal.yaml perconaservermongodb.psmdb.percona.com/my-cluster-name created
Wait until all pods are created:
$ kubectl get pods NAME READY STATUS RESTARTS AGE percona-server-mongodb-operator-547c499bd8-p8k74 1/1 Running 0 5m16s minimal-cluster-cfg-0 1/1 Running 0 3m25s minimal-cluster-rs0-0 1/1 Running 0 3m24s minimal-cluster-mongos-0 1/1 Running 0 3m24s
Setting up roles on the Percona Operator
Now that MongoDB pods are running, let’s add the groups for role-based mapping. We need to add this configuration from the primary config server which will be used by mongos and replicaset for authorization when logging in.
First, let’s get the username and password of the admin user:
$ kubectl get secrets NAME TYPE DATA AGE minimal-cluster Opaque 10 4m3s internal-minimal-cluster-users Opaque 10 4m3s minimal-cluster-mongodb-keyfile Opaque 1 4m3s minimal-cluster-mongodb-encryption-key Opaque 1 4m3s $ kubectl get secrets minimal-cluster -o yaml apiVersion: v1 data: MONGODB_BACKUP_PASSWORD: b2NNNkFjOHdEUU42OUpmYnE= MONGODB_BACKUP_USER: YmFja3Vw MONGODB_CLUSTER_ADMIN_PASSWORD: aElBWlVyajFkZWF0eEhWSzI= MONGODB_CLUSTER_ADMIN_USER: Y2x1c3RlckFkbWlu MONGODB_CLUSTER_MONITOR_PASSWORD: V1p6YkFhN1o3T2RkSm5Gbg== MONGODB_CLUSTER_MONITOR_USER: Y2x1c3Rlck1vbml0b3I= MONGODB_DATABASE_ADMIN_PASSWORD: U0hMR3Y3WlF2SVpxZ1dhcUFh MONGODB_DATABASE_ADMIN_USER: ZGF0YWJhc2VBZG1pbg== MONGODB_USER_ADMIN_PASSWORD: eW5TZjRzQjkybm5UdjdVdXduTQ== MONGODB_USER_ADMIN_USER: dXNlckFkbWlu kind: Secret metadata: creationTimestamp: "2022-09-15T15:57:42Z" name: minimal-cluster namespace: default resourceVersion: "5673" uid: d3f4f678-a3db-4578-b10c-69e8c4410b00 type: Opaque $ echo `echo "dXNlckFkbWlu"|base64 --decode` userAdmin $ echo `echo "eW5TZjRzQjkybm5UdjdVdXduTQ=="|base64 --decode` ynSf4sB92nnTv7UuwnM
Next, let’s connect to the primary config server:
$ kubectl get services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.152.183.1 443/TCP 22m minimal-cluster-cfg ClusterIP None 27017/TCP 7m27s minimal-cluster-rs0 ClusterIP None 27017/TCP 7m27s minimal-cluster-mongos ClusterIP 10.152.183.220 27017/TCP 7m27s $ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:5.0.11-10 --restart=Never -- bash -il [mongodb@percona-client /]$ mongo --host minimal-cluster-cfg -u userAdmin -p ynSf4sB92nnTv7UuwnM Percona Server for MongoDB shell version v5.0.11-10 connecting to: mongodb://minimal-cluster-cfg:27017/?compressors=disabled&gssapiServiceName=mongodb Implicit session: session { "id" : UUID("5f1f7db8-d75f-4658-a579-86b9bbf22471") } Percona Server for MongoDB server version: v5.0.11-10 cfg:PRIMARY>
From the console, we can create two roles “CN=dbadmins,CN=Users,DC=percona,DC=local” and “CN=developers,CN=Users,DC=percona,DC=local” with their corresponding privileges:
use admin db.createRole( { role: "CN=dbadmins,CN=Users,DC=percona,DC=local", roles: [ "root"], privileges: [] } ) db.createRole( { role: "CN=developers,CN=Users,DC=percona,DC=local", roles: [ "readWriteAnyDatabase" ], privileges: [] } )
Note that the role names defined here correspond to the Samba groups I created with samba-tool. Also, you will need to add the same roles in the replicaset endpoint if you want your LDAP users to have these privileges when connecting to the replicaset directly.
Finally, exit the mongo console by typing exit and pressing Enter. Do the same to exit the pod as well.
Applying the LDAP configuration to the replicaset, mongos, and config servers
Now, we can add the LDAP configuration to the config server. Our first test configuration is to supply the full DN when logging in so the configuration will be:
$ cat fulldn-config.yaml security: authorization: "enabled" ldap: authz: queryTemplate: 'DC=percona,DC=local??sub?(&(objectClass=group)(member:={PROVIDED_USER}))' servers: "192.168.0.101" transportSecurity: none bind: queryUser: "CN=Search User01,CN=Users,DC=percona,DC=local" queryPassword: "SearchPassword1" setParameter: authenticationMechanisms: 'PLAIN,SCRAM-SHA-1,SCRAM-SHA-256'
Next, apply the configuration to the config servers:
$ kubectl create secret generic minimal-cluster-cfg-mongod --from-file=mongod.conf=fulldn-config.yaml
Additionally, if you want to log in to the replica set with LDAP, you can apply the same configuration as well:
$ kubectl create secret generic minimal-cluster-rs0-mongod --from-file=mongod.conf=fulldn-config.yaml
As for mongos, you will still need to omit the settings for authorization because this will come from the config server:
$ cat fulldn-mongos-config.yaml security: ldap: servers: "192.168.0.101" transportSecurity: none bind: queryUser: "CN=Search User01,CN=Users,DC=percona,DC=local" queryPassword: "SearchPassword1" setParameter: authenticationMechanisms: 'PLAIN,SCRAM-SHA-1,SCRAM-SHA-256'
Then apply the configuration for mongos:
$ kubectl create secret generic minimal-cluster-mongos --from-file=mongos.conf=fulldn-mongos-config.yaml
One-by-one the pods will be recreated. Wait until all of them are recreated:
$ kubectl get pods NAME READY STATUS RESTARTS AGE percona-server-mongodb-operator-547c499bd8-p8k74 1/1 Running 0 24m minimal-cluster-cfg-0 1/1 Running 0 4m27s minimal-cluster-rs0-0 1/1 Running 0 3m34s minimal-cluster-mongos-0 1/1 Running 0 65s
Now you can test authentication in one of the endpoints:
$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:5.0.11-10 --restart=Never -- mongo --host minimal-cluster-mongos -u "CN=Dba User01,CN=Users,DC=percona,DC=local" -p DbaPassword1 --authenticationDatabase '$external' --authenticationMechanism 'PLAIN' --eval "db.runCommand({connectionStatus:1})" + exec mongo --host minimal-cluster-mongos -u 'CN=Dba User01,CN=Users,DC=percona,DC=local' -p DbaPassword1 --authenticationDatabase '$external' --authenticationMechanism PLAIN --eval 'db.runCommand({connectionStatus:1})' Percona Server for MongoDB shell version v5.0.11-10 connecting to: mongodb://minimal-cluster-mongos:27017/?authMechanism=PLAIN&authSource=%24external&compressors=disabled&gssapiServiceName=mongodb Implicit session: session { "id" : UUID("7eca812d-ad04-4ae2-8484-3b55dee1a673") } Percona Server for MongoDB server version: v5.0.11-10 { "authInfo" : { "authenticatedUsers" : [ { "user" : "CN=Dba User01,CN=Users,DC=percona,DC=local", "db" : "$external" } ], "authenticatedUserRoles" : [ { "role" : "CN=dbadmins,CN=Users,DC=percona,DC=local", "db" : "admin" }, { "role" : "root", "db" : "admin" } ] } } pod "percona-client" deleted
As you can see above, the user,”CN=Dba User01,CN=Users,DC=percona,DC=local” has assumed the role as root. You can test other endpoints using these commands.
$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:5.0.11-10 --restart=Never -- mongo --host minimal-cluster-rs0 -u "CN=Dba User01,CN=Users,DC=percona,DC=local" -p DbaPassword1 --authenticationDatabase '$external' --authenticationMechanism 'PLAIN' --eval "db.runCommand({connectionStatus:1})" $ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:5.0.11-10 --restart=Never -- mongo --host minimal-cluster-cfg -u "CN=Dba User01,CN=Users,DC=percona,DC=local" -p DbaPassword1 --authenticationDatabase '$external' --authenticationMechanism 'PLAIN' --eval "db.runCommand({connectionStatus:1})"
Using userToDNMapping to simplify usernames
Obviously, you may not want the users to authenticate with the full DN. Perhaps, you want the users to specify just the first CN. You can use match and substitution mapping for this:
$ cat mapping1-config.yaml security: authorization: "enabled" ldap: authz: queryTemplate: 'DC=percona,DC=local??sub?(&(objectClass=group)(member:={USER}))' servers: "192.168.0.101" transportSecurity: none bind: queryUser: "CN=Search User01,CN=Users,DC=percona,DC=local" queryPassword: "SearchPassword1" userToDNMapping: >- [ { match: "(.+)", substitution: "CN={0},CN=users,DC=percona,DC=local" } ] setParameter: authenticationMechanisms: 'PLAIN,SCRAM-SHA-1,SCRAM-SHA-256' $ cat mapping1-mongos-config.yaml security: ldap: servers: "192.168.0.101" transportSecurity: none bind: queryUser: "CN=Search User01,CN=Users,DC=percona,DC=local" queryPassword: "SearchPassword1" userToDNMapping: >- [ { match: "(.+)", substitution: "CN={0},CN=users,DC=percona,DC=local" } ] setParameter: authenticationMechanisms: 'PLAIN,SCRAM-SHA-1,SCRAM-SHA-256'
You will need to delete the old configuration and apply the new ones:
$ kubectl delete secret minimal-cluster-cfg-mongod $ kubectl delete secret minimal-cluster-rs0-mongod $ kubectl delete secret minimal-cluster-mongos $ kubectl create secret generic minimal-cluster-cfg-mongod --from-file=mongod.conf=mapping1-config.yaml $ kubectl create secret generic minimal-cluster-rs0-mongod --from-file=mongod.conf=mapping1-config.yaml $ kubectl create secret generic minimal-cluster-mongos --from-file=mongos.conf=mapping1-mongos-config.yaml
With userToDNMapping, match and substitution you can now just specify the first CN. Once all of the pods are restarted, try logging in with a shorter username:
$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:5.0.11-10 --restart=Never -- mongo --host minimal-cluster-mongos -u "Dba User01" -p DbaPassword1 --authenticationDatabase '$external' --authenticationMechanism 'PLAIN' --eval "db.runCommand({connectionStatus:1})"
Perhaps, it still seems awkward to have usernames with spaces and you would like to login based on other attributes such as sAMAccountName or mail. You can use an additional LDAP query in userToDBMapping to search for the record based on these properties. Once the record is found it will extract the user’s DN for authentication. For the example below, we will use sAMAccountName as input for the username:
$ cat mapping2-config.yaml security: authorization: "enabled" ldap: authz: queryTemplate: 'DC=percona,DC=local??sub?(&(objectClass=group)(member:={USER}))' servers: "192.168.0.101" transportSecurity: none bind: queryUser: "CN=Search User01,CN=Users,DC=percona,DC=local" queryPassword: "SearchPassword1" userToDNMapping: >- [ { match: "(.+)", ldapQuery: "dc=percona,dc=local??sub?(&(sAMAccountName={0})(objectClass=person))" } ] setParameter: authenticationMechanisms: 'PLAIN,SCRAM-SHA-1,SCRAM-SHA-256' $ cat mapping2-mongos-config.yaml security: ldap: servers: "192.168.0.101" transportSecurity: none bind: queryUser: "CN=Search User01,CN=Users,DC=percona,DC=local" queryPassword: "SearchPassword1" userToDNMapping: >- [ { match: "(.+)", ldapQuery: "dc=percona,dc=local??sub?(&(sAMAccountName={0})(objectClass=person))" } ] setParameter: authenticationMechanisms: 'PLAIN,SCRAM-SHA-1,SCRAM-SHA-256'
Again, we will need to delete the old configuration and apply new ones:
$ kubectl delete secret minimal-cluster-cfg-mongod $ kubectl delete secret minimal-cluster-rs0-mongod $ kubectl delete secret minimal-cluster-mongos $ kubectl create secret generic minimal-cluster-cfg-mongod --from-file=mongod.conf=mapping2-config.yaml $ kubectl create secret generic minimal-cluster-rs0-mongod --from-file=mongod.conf=mapping2-config.yaml $ kubectl create secret generic minimal-cluster-mongos --from-file=mongos.conf=mapping2-mongos-config.yaml
Once the pods are recreated, we can now authenticate with regular usernames.
$ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:5.0.11-10 --restart=Never -- mongo --host minimal-cluster-mongos -u devuser01 -p DevPassword1 --authenticationDatabase '$external' --authenticationMechanism 'PLAIN' --eval "db.runCommand({connectionStatus:1})" $ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:5.0.11-10 --restart=Never -- mongo --host minimal-cluster-mongos -u dbauser01 -p DbaPassword1 --authenticationDatabase '$external' --authenticationMechanism 'PLAIN' --eval "db.runCommand({connectionStatus:1})"
Summary
I hope this article gets you up to speed on setting up LDAP authentication and authorization with Percona Operator for MongoDB.