Fork me on GitHub

Database Access with Redis Cluster


Database Access for Redis is available starting from Teleport 9.0.

If you want to configure Redis Standalone, please read Database Access with Redis.

This guide will help you to:

  • Install and configure Teleport.
  • Configure mutual TLS authentication between Teleport and Redis Cluster.
  • Connect to Redis through Teleport.

Teleport Database Access Redis Cluster Self-Hosted


  • Teleport version 9.0 or newer.
  • Redis version 6.0 or newer.
  • redis-cli installed and added to your system's PATH environment variable.

Redis 7.0 and RESP3 (REdis Serialization Protocol) are currently not supported.

Step 1/6. Set up Teleport Auth and Proxy

On the host where you will run the Auth Service and Proxy Service, download the latest version of Teleport for your platform from our downloads page and follow the installation instructions.

Teleport requires a valid TLS certificate to operate and can fetch one automatically using Let's Encrypt's ACME protocol. Before Let's Encrypt can issue a TLS certificate for the Teleport Proxy host's domain, the ACME protocol must verify that an HTTPS server is reachable on port 443 of the host.

You can configure the Teleport Proxy service to complete the Let's Encrypt verification process when it starts up.

Run the following teleport configure command, where is the domain name of your Teleport cluster and [email protected] is an email address used for notifications (you can use any domain):

teleport configure --acme [email protected] > /etc/teleport.yaml

The --acme, --acme-email, and --cluster-name flags will add the following settings to your Teleport configuration file:

  enabled: "yes"
  web_listen_addr: :443
    enabled: "yes"
    email: [email protected]

Port 443 on your Teleport Proxy Service host must allow traffic from all sources.

Next, start the Teleport Auth and Proxy Services:

sudo teleport start

You will run subsequent tctl commands on the host where you started the Auth and Proxy Services.

If you do not have a Teleport Cloud account, use our signup form to get started. Teleport Cloud manages instances of the Proxy Service and Auth Service, and automatically issues and renews the required TLS certificate.

You must log in to your cluster before you can run tctl commands.

tsh login
tctl status

Install Teleport on the host where you will run the Teleport Database Service:

Download Teleport's PGP public key

sudo curl \ -o /usr/share/keyrings/teleport-archive-keyring.asc

Add the Teleport APT repository

echo "deb [signed-by=/usr/share/keyrings/teleport-archive-keyring.asc] stable main" \| sudo tee /etc/apt/sources.list.d/teleport.list > /dev/null
sudo apt-get update
sudo apt-get install teleport
sudo yum-config-manager --add-repo
sudo yum install teleport

Optional: Using DNF on newer distributions

$ sudo dnf config-manager --add-repo

$ sudo dnf install teleport


<checksum> <filename>

curl -O
shasum -a 256 teleport-v9.2.4-linux-amd64-bin.tar.gz

Verify that the checksums match

tar -xzf teleport-v9.2.4-linux-amd64-bin.tar.gz
cd teleport
sudo ./install

<checksum> <filename>

curl -O
shasum -a 256 teleport-v9.2.4-linux-arm-bin.tar.gz

Verify that the checksums match

tar -xzf teleport-v9.2.4-linux-arm-bin.tar.gz
cd teleport
sudo ./install

<checksum> <filename>

curl -O
shasum -a 256 teleport-v9.2.4-linux-arm64-bin.tar.gz

Verify that the checksums match

tar -xzf teleport-v9.2.4-linux-arm64-bin.tar.gz
cd teleport
sudo ./install

Step 2/6. Create a Teleport user

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

tctl users add \ --roles=access \ --db-users=\* \ --db-names=\* \ alice
--rolesList of roles to assign to the user. The builtin access role allows them to connect to any database server registered with Teleport.
--db-usersList of database usernames the user will be allowed to use when connecting to the databases. A wildcard allows any user.
--db-namesList of logical databases (aka schemas) the user will be allowed to connect to within a database server. A wildcard allows any database.

Database names are only enforced for PostgreSQL and MongoDB databases.

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

Step 3/6. Create Redis users

Each Redis user must be protected by a strong password. We recommend using OpenSSL to generate passwords:

openssl rand -hex 32

If you have access to Redis you can also generate a password by using the below command from the Redis console:


Create a users.acl file, which defines users for your Redis deployment, passwords required to log in as a given user, and sets of ACL rules. Redis allows you to provide passwords in plaintext or an SHA256 hash. We strongly recommend using an SHA256 hash instead of plaintext passwords.

You can use the command below to generate an SHA256 hash from a password.

user alice on #57639ed88a85996453555f22f5aa4147b4c9614056585d931e5d976f610651e9 allcommands allkeys
user default off

For more ACL examples refer to the Redis documentation.


It's very important to either disable or protect with a password the default user. Otherwise, everyone with access to the database can log in as the default user, which by default has administrator privileges.

Step 4/6. Set up mutual TLS

Teleport uses mutual TLS authentication with self-hosted databases. These databases must be configured with Teleport's certificate authority to be able to verify client certificates. They also need a certificate/key pair that Teleport can verify.

We will show you how to use the tctl auth sign command below.

When connecting to Redis Cluster, sign certificates for each member using their hostnames and IP addresses. For example, if the first member is accessible at with IP and the second at with IP, run:

tctl auth sign --format=redis, --out=redis1 --ttl=2190h
tctl auth sign --format=redis, --out=redis2 --ttl=2190h

We recommend using a shorter TTL, but keep mind that you'll need to update the database server certificate before it expires to not lose the ability to connect. Pick the TTL value that best fits your use-case.

The command will create three files:

  • server.cas with Teleport's certificate authority
  • server.key with a generated private key
  • server.crt with a generated user certificate

You will need these files to enable mutual TLS on your Redis server.

Certificate Rotation

Teleport signs database certificates with the host authority. As such, when performing host certificates rotation, the database certificates must be updated as well.

Use the generated secrets to enable mutual TLS in your redis.conf configuration file and restart the database:

tls-port 7001
port 0
cluster-enabled yes
tls-replication yes
tls-cluster yes
aclfile /path/to/users.acl
masteruser replica-user
tls-cert-file /usr/local/etc/redis/certs/server.crt
tls-key-file /usr/local/etc/redis/certs/server.key
tls-ca-cert-file /usr/local/etc/redis/certs/server.cas
tls-protocols "TLSv1.2 TLSv1.3"

Once mutual TLS has been enabled, you will no longer be able to connect to the cluster without providing a valid client certificate. You can use the tls-auth-clients optional setting to allow connections from clients that do not present a certificate.

See TLS Support in the Redis documentation for more details.

Step 5/6. Create cluster

Use the following command to create the cluster. Please note redis-cli --cluster create accepts only IP addresses.

export CERTS_DIR=/path/to/certs/
export IP1= # update with the real node 1 IP
export IP2= # update with the real node 2 IP
export IP3= # update with the real node 3 IP
export IP4= # update with the real node 4 IP
export IP5= # update with the real node 5 IP
export IP6= # update with the real node 6 IP
redis-cli --user alice --cluster-replicas 1 --tls --cluster-yes \
--cluster create ${IP1}:7001 ${IP2}:7002 ${IP3}:7003 ${IP4}:7004 ${IP5}:7005 ${IP6}:7006 \
--cacert ${CERTS_DIR}/server.cas --key ${CERTS_DIR}/server.key --cert ${CERTS_DIR}/server.crt

Step 6/6. Connect

To enable Redis cluster mode in Teleport, add the mode=cluster parameter to the connection URI in your Teleport Database Service config file.

  - name: "redis-cluster"
    uri: "rediss://"

Log into your Teleport cluster and see available databases:

tsh login --user=alice
tsh db ls

Name Description Labels

------------- --------------- --------

example-redis Example Redis env=dev

tsh login --user=alice
tsh db ls

Name Description Labels

------------- --------------- --------

example-redis Example Redis env=dev

To connect to a particular database instance, first retrieve its certificate using the tsh db login command:

tsh db login example-redis

You can be logged into multiple databases simultaneously.

You can optionally specify the database name and the user to use by default when connecting to the database instance:

tsh db login --db-user=alice example-redis

If flag --db-user is not provided, Teleport logs in as the default user.

Once logged in, connect to the database:

tsh db connect example-redis

The redis-cli command-line client should be available in the system PATH in order to be able to connect.

Now you can log in as the previously created user using the below command:


To log out of the database and remove credentials:

Remove credentials for a particular database instance.

tsh db logout example-redis

Remove credentials for all database instances.

tsh db logout

Supported Redis Cluster commands

Redis in cluster mode does not support the following commands. If one of the listed commands above is called Teleport returns the ERR Teleport: command not supported error.

  • ACL
  • EXEC
  • INFO
  • ROLE
  • SCAN
  • SYNC
  • TIME
  • WAIT

Teleport conducts additional processing on the following commands before communicating with Redis Cluster:

DBSIZESends the query to all nodes and returns the number of keys in the whole cluster.
KEYSSends the query to all nodes and returns a list of all keys in the whole cluster.
MGETTranslates the commands to multiple GETs and sends them to multiple nodes. Result is merged in Teleport and returned back to the client. If Teleport fails to fetch at least one key an error is returned.
FLUSHDBSends the query to all nodes.
FLUSHALLWorks the same as FLUSHDB.
SCRIPT EXISTSSends the query to all nodes. 1 is returned only if script exists on all nodes.
SCRIPT LOADSends the script to all nodes.
SCRIPT FLUSHSends the query to all nodes. ASYNC parameter is ignored.

Next steps