Database Access with MongoDB Atlas

Teleport can provide secure access to MongoDB Atlas via the Teleport Database Service. This allows for fine-grained access control through Teleport's RBAC.

In this guide, you will:

1. Configure your MongoDB Atlas database with either mutual TLS or AWS IAM authentication.
2. Add the database to your Teleport cluster.
3. Connect to the database via Teleport.

How it works

The Teleport Database Service communicates with MongoDB Atlas using mutual TLS or AWS IAM:

• Mutual TLS: You configure MongoDB Atlas to trust the Teleport certificate authority for database clients, and Teleport to trust the Let's Encrypt CA, which signs certificates for MongoDB Atlas. When a user connects to MongoDB Atlas via Teleport, the Teleport Database Service authenticates using a certificate and forwards user traffic to MongoDB Atlas.
• AWS IAM: You configure MongoDB users to use "MONGODB-AWS" authentication mechanism, and Teleport to trust Let's Encrypt CA, which signs certificates for MongoDB Atlas. When a user connects to MongoDB Atlas via Teleport, the Teleport Database Service assumes the associated IAM role for authentication and forwards user traffic to MongoDB Atlas.

Self-Hosted

Teleport Enterprise Cloud

Prerequisites

• A running Teleport cluster version 17.0.0-dev or above. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.

• The tctl admin tool and tsh client tool.

  Visit Installation for instructions on downloading tctl and tsh.

• MongoDB Atlas cluster.
• A host, e.g., an Amazon EC2 instance, where you will run the Teleport Database Service.
• To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials. For example:

  tsh login --proxy=teleport.example.com --user=email@example.com
  tctl status
  Cluster  teleport.example.com
  Version  17.0.0-dev
  CA pin   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

  If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

Step 1/4. Configure Atlas

Teleport MongoDB Atlas integration supports two methods of authentication:

• Self-managed X.509: This method relies on certificates for authentication, with MongoDB Atlas trusting the Teleport certificates.
• AWS IAM: The authentication is done using AWS credentials fetched by Teleport.

Self-managed X.509

First, obtain Teleport CA certificate by running the following tctl auth sign command against your Teleport cluster:

tctl auth sign --format=mongodb --host=mongo --out=mongo

The --host and --ttl flag value doesn't matter in this case since you'll only use the CA certificate which this command will output to mongo.cas file. You can discard the other mongo.crt file.

Go to the Security / Advanced configuration section of your Atlas cluster and toggle "Self-managed X.509 Authentication" on:

Paste the contents of mongo.cas file in the Certificate Authority edit box and click Save.

Create a MongoDB user

On the Security / Database Access page add a new database user with Certificate authentication method:

Make sure to specify the user as CN=<user> as shown above since MongoDB treats the entire certificate subject as a username. When connecting to a MongoDB cluster, say, as a user alice, Teleport will sign an ephemeral certificate with CN=alice subject.

note

Case matters so make sure to specify Common Name in the username with capital letters CN=.

AWS IAM

You must provide the Teleport Database Service access to AWS credentials.

Grant the Database Service access to credentials that it can use to authenticate to AWS.

• If you are running the Database Service on an EC2 instance, you may use the EC2 Instance Metadata Service method
• If you are running the Database Service in Kubernetes, you can use IAM Roles for Service Accounts (IRSA)
• Otherwise, you must use environment variables

Instance Metadata Service

Teleport will detect when it is running on an EC2 instance and use the Instance Metadata Service to fetch credentials.

The EC2 instance should be configured to use an EC2 instance profile. For more information, see: Using Instance Profiles.

Kubernetes IRSA

Refer to IAM Roles for Service Accounts (IRSA) to set up an OIDC provider in AWS and configure an AWS IAM role that allows the pod's service account to assume the role.

Environment Variables

Teleport's built-in AWS client reads credentials from the following environment variables:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_DEFAULT_REGION

When you start the Database Service, the service reads environment variables from a file at the path /etc/default/teleport. Obtain these credentials from your organization. Ensure that /etc/default/teleport has the following content, replacing the values of each variable:

AWS_ACCESS_KEY_ID=00000000000000000000
AWS_SECRET_ACCESS_KEY=0000000000000000000000000000000000000000
AWS_DEFAULT_REGION=<YOUR_REGION>

Have multiple sources of AWS credentials?

Teleport's AWS client loads credentials from different sources in the following order:

• Environment Variables
• Shared credentials file
• Shared configuration file (Teleport always enables shared configuration)
• EC2 Instance Metadata (credentials only)

While you can provide AWS credentials via a shared credentials file or shared configuration file, you will need to run the Database Service with the AWS_PROFILE environment variable assigned to the name of your profile of choice.

If you have a specific use case that the instructions above do not account for, consult the documentation for the AWS SDK for Go for a detailed description of credential loading behavior.

Create a MongoDB IAM role

Navigate to the AWS IAM console. In the navigation pane, choose Roles and then choose Create role. Next, select the "Custom trust policy" type. Edit the trust policy to allow the Teleport Database service IAM role to assume this role so that the Teleport can fetch the necessary credentials to authenticate to MongoDB:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111111111111:role/teleport-database-access",
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Your role won’t require any permission, so you can leave it empty on the Add Permissions step. Then, choose a name for it and create it. In this guide, we will the name teleport-access.

Create a MongoDB User

On the Security / Database Access page add a new database user with AWS IAM authentication method, and choose "IAM Role" as the IAM User type. Then, fill in the AWS ARN field with the ARN of the newly created IAM role. In the Database User Privileges section, give the user sufficient privileges to access the desired database data.

Please note that Teleport does not support authentication using AWS IAM users; it exclusively supports authentication using AWS IAM roles.

Step 2/4. Create a Teleport user

tip

To modify an existing user to provide access to the Database Service, see Database Access Controls

Teleport Community Edition

Create a local Teleport user with the built-in access role:

tctl users add \  --roles=access \  --db-users="*" \  --db-names="*" \  alice

Teleport Enterprise/Enterprise Cloud

Create a local Teleport user with the built-in access and requester roles:

tctl users add \  --roles=access,requester \  --db-users="*" \  --db-names="*" \  alice

Flag	Description
--roles	List of roles to assign to the user. The builtin access role allows them to connect to any database server registered with Teleport.
--db-users	List of database usernames the user will be allowed to use when connecting to the databases. A wildcard allows any user.
--db-names	List of logical databases (aka schemas) the user will be allowed to connect to within a database server. A wildcard allows any database.

warning

Database names are only enforced for PostgreSQL, MongoDB, and Cloud Spanner databases.

For more detailed information about database access controls and how to restrict access see RBAC documentation.

If you opt for a stricter selection of database names for your user, which differs from the wildcard approach illustrated in this guide, it is essential to include the admin database. This ensures MongoDB clients won't have issues while connecting and executing operations such as retrieving server information, listing databases, and aborting transactions.

Step 3/4. Set up the Teleport Database Service

The Database Service requires a valid join token to join your Teleport cluster. Run the following tctl command and save the token output in /tmp/token on the server that will run the Database Service:

tctl tokens add --type=db --format=text
abcd123-insecure-do-not-use-this

Install and configure Teleport where you will run the Teleport Database Service:

Linux Server

Install Teleport on your Linux server:

1. Assign edition to one of the following, depending on your Teleport edition:

   Edition	Value
   Teleport Enterprise Cloud	cloud
   Teleport Enterprise (Self-Hosted)	enterprise
   Teleport Community Edition	oss

2. Get the version of Teleport to install. If you have automatic agent updates enabled in your cluster, query the latest Teleport version that is compatible with the updater:

   TELEPORT_DOMAIN=example.teleport.com
   TELEPORT_VERSION="$(curl https://$TELEPORT_DOMAIN/v1/webapi/automaticupgrades/channel/default/version | sed 's/v//')"

   Otherwise, get the version of your Teleport cluster:

   TELEPORT_DOMAIN=example.teleport.com
   TELEPORT_VERSION="$(curl https://$TELEPORT_DOMAIN/v1/webapi/ping | jq -r '.server_version')"

3. Install Teleport on your Linux server:

   curl https://cdn.teleport.dev/install-v15.4.11.sh | bash -s ${TELEPORT_VERSION} edition

   The installation script detects the package manager on your Linux server and uses it to install Teleport binaries. To customize your installation, learn about the Teleport package repositories in the installation guide.

On the host where you will run the Teleport Database Service, start Teleport with the appropriate configuration.

Note that a single Teleport process can run multiple different services, for example multiple Database Service agents as well as the SSH Service or Application Service. The step below will overwrite an existing configuration file, so if you're running multiple services add --output=stdout to print the config in your terminal, and manually adjust /etc/teleport.yaml.

Generate a configuration file at /etc/teleport.yaml for the Database Service:

Teleport Enterprise/Enterprise Cloud

sudo teleport db configure create \   -o file \   --token=/tmp/token \   --proxy=teleport.example.com:443 \   --name=mongodb-atlas \   --protocol=mongodb \   --uri=mongodb+srv://cluster0.abcde.mongodb.net \   --labels=env=dev 

Teleport Community Edition

sudo teleport db configure create \   -o file \   --token=/tmp/token \   --proxy=mytenant.teleport.sh:443 \   --name=mongodb-atlas \   --protocol=mongodb \   --uri=mongodb+srv://cluster0.abcde.mongodb.net \   --labels=env=dev

Configure the Teleport Database Service to start automatically when the host boots up by creating a systemd service for it. The instructions depend on how you installed the Teleport Database Service.

Package Manager

On the host where you will run the Teleport Database Service, enable and start Teleport:

sudo systemctl enable teleport
sudo systemctl start teleport

TAR Archive

On the host where you will run the Teleport Database Service, create a systemd service configuration for Teleport, enable the Teleport service, and start Teleport:

sudo teleport install systemd -o /etc/systemd/system/teleport.service
sudo systemctl enable teleport
sudo systemctl start teleport

You can check the status of the Teleport Database Service with systemctl status teleport and view its logs with journalctl -fu teleport.

Kubernetes Cluster

Teleport provides Helm charts for installing the Teleport Database Service in Kubernetes Clusters.

Set up the Teleport Helm repository.

Allow Helm to install charts that are hosted in the Teleport Helm repository:

helm repo add teleport https://charts.releases.teleport.dev

Update the cache of charts from the remote repository so you can upgrade to all available releases:

helm repo update

Self-Hosted

Install the Teleport Kube Agent into your Kubernetes Cluster with the Teleport Database Service configuration.

JOIN_TOKEN=$(cat /tmp/token)
helm install teleport-kube-agent teleport/teleport-kube-agent \  --create-namespace \  --namespace teleport-agent \  --set roles=db \  --set proxyAddr=teleport.example.com:443 \  --set authToken=${JOIN_TOKEN?} \  --set "databases[0].name=mongodb-atlas" \  --set "databases[0].uri=mongodb+srv://cluster0.abcde.mongodb.net" \  --set "databases[0].protocol=mongodb" \  --set "databases[0].static_labels.env=dev" \  --version 17.0.0-dev

Cloud-Hosted

Install the Teleport Kube Agent into your Kubernetes Cluster with the Teleport Database Service configuration.

JOIN_TOKEN=$(cat /tmp/token)
helm install teleport-kube-agent teleport/teleport-kube-agent \  --create-namespace \  --namespace teleport-agent \  --set roles=db \  --set proxyAddr=mytenant.teleport.sh:443 \  --set authToken=${JOIN_TOKEN?} \  --set "databases[0].name=mongodb-atlas" \  --set "databases[0].uri=mongodb+srv://cluster0.abcde.mongodb.net" \  --set "databases[0].protocol=mongodb" \  --set "databases[0].static_labels.env=dev" \  --version 16.4.11

Make sure that the Teleport Agent pod is running. You should see one teleport-kube-agent pod with a single ready container:

kubectl -n teleport-agent get pods
NAME                    READY   STATUS    RESTARTS   AGEteleport-kube-agent-0   1/1     Running   0          32s

Tip

A single Teleport process can run multiple services, for example multiple Database Service instances as well as other services such the SSH Service or Application Service.

Connection endpoint

You will need to provide your Atlas cluster's connection endpoint for the db_service.databases[*].uri configuration option or --uri CLI flag. You can find this via the Connect dialog on the Database Deployments overview page:

Go through the "Setup connection security" step and select "Connect with the MongoDB shell" to view the connection string:

Use only the scheme and hostname parts of the connection string in the URI:

--uri=mongodb+srv://cluster0.abcde.mongodb.net

Step 4/4. Connect

Log into your Teleport cluster and see available databases:

Self-Hosted

tsh login --proxy=teleport.example.com --user=alice
tsh db ls
Name          Description Labels
------------- ----------- --------
mongodb-atlas             env=dev

Cloud-Hosted

tsh login --proxy=mytenant.teleport.sh --user=alice
tsh db ls
Name          Description Labels
------------- ----------- --------
mongodb-atlas             env=dev

Self-managed X.509 authentication

To retrieve credentials for a database and connect to it:

tsh db connect --db-user=alice --db-name dev mongodb-atlas

AWS IAM authentication

To retrieve credentials for a database and connect to it, you must provide the database username in the role/<role-name> format:

tsh db connect --db-user=role/teleport-access --db-name dev mongodb-atlas

Alternatively, you provide the full ARN as the database username when connecting to the database instance:

tsh db connect --db-user=arn:aws:iam::111111111111:role/teleport-access --db-name dev mongodb-atlas

Either the mongosh or mongo command-line clients should be available in PATH in order to be able to connect. The Database Service attempts to run mongosh first and, if mongosh is not in PATH, runs mongo.

To log out of the database and remove credentials:

Remove credentials for a particular database instance.
tsh db logout mongodb-atlas
Remove credentials for all database instances.
tsh db logout

Next steps

• Learn how to restrict access to certain users and databases.

• View the High Availability (HA) guide.

• Take a look at the YAML configuration reference.

• See the full CLI reference.

Further reading

• Which certificate authority signs MongoDB Atlas cluster TLS certificates?
• Self-managed X.509 authentication
• AWS IAM authentication