diff --git a/docs/config.json b/docs/config.json index 12e5f1a7a1155..e07a4cd27c447 100644 --- a/docs/config.json +++ b/docs/config.json @@ -10,6 +10,7 @@ { "title": "User Manual", "slug": "/user-manual/" }, { "title": "Application Guide", "slug": "/application-access/" }, { "title": "Kubernetes Guide", "slug": "/kubernetes-access/" }, + { "title": "Database Access", "slug": "/database-access/" }, { "title": "Admin Manual", "slug": "/admin-guide/" }, { "title": "Production Guide", "slug": "/production/" }, { "title": "FAQ", "slug": "/faq/" }, @@ -21,7 +22,6 @@ "title": "Preview", "entries": [ { "title": "Upcoming Releases", "slug": "/preview/upcoming-releases/" }, - { "title": "Database Access", "slug": "/preview/database-access/" }, { "title": "Cloud", "slug": "/preview/cloud/" } ] }, @@ -35,6 +35,28 @@ { "title": "OpenSSH Guide", "slug": "/openssh-teleport/" } ] }, + { + "icon": "database", + "title": "Database Access", + "entries": [ + { "title": "Getting Started", "slug": "/database-access/getting-started/" }, + { + "title": "Guides", + "slug": "/database-access/guides/", + "entries": [ + { "title": "PostgreSQL on AWS", "slug": "/database-access/guides/postgres-aws" }, + { "title": "MySQL on AWS", "slug": "/database-access/guides/mysql-aws" }, + { "title": "Self-Hosted PostgreSQL", "slug": "/database-access/guides/postgres-self-hosted/" }, + { "title": "Self-Hosted MySQL", "slug": "/database-access/guides/mysql-self-hosted/" }, + { "title": "Database GUI Clients", "slug": "/database-access/guides/gui-clients/" } + ] + }, + { "title": "RBAC", "slug": "/database-access/rbac/" }, + { "title": "Architecture", "slug": "/database-access/architecture/" }, + { "title": "Reference", "slug": "/database-access/reference/" }, + { "title": "FAQ", "slug": "/database-access/faq/" } + ] + }, { "icon": "building", "title": "Teleport Enterprise", diff --git a/docs/img/database-access/diagram.png b/docs/img/database-access/diagram.png new file mode 100644 index 0000000000000..b29c72417e5d0 Binary files /dev/null and b/docs/img/database-access/diagram.png differ diff --git a/docs/img/database-access/pgadmin-add-server.png b/docs/img/database-access/pgadmin-add-server.png new file mode 100644 index 0000000000000..de62d45dad8b3 Binary files /dev/null and b/docs/img/database-access/pgadmin-add-server.png differ diff --git a/docs/img/database-access/pgadmin-connection.png b/docs/img/database-access/pgadmin-connection.png new file mode 100644 index 0000000000000..ebb184accdca3 Binary files /dev/null and b/docs/img/database-access/pgadmin-connection.png differ diff --git a/docs/img/database-access/pgadmin-general.png b/docs/img/database-access/pgadmin-general.png new file mode 100644 index 0000000000000..5e3bb2dc9fd15 Binary files /dev/null and b/docs/img/database-access/pgadmin-general.png differ diff --git a/docs/img/database-access/pgadmin-ssl.png b/docs/img/database-access/pgadmin-ssl.png new file mode 100644 index 0000000000000..5ae18b27b37c3 Binary files /dev/null and b/docs/img/database-access/pgadmin-ssl.png differ diff --git a/docs/img/database-access/workbench-parameters.png b/docs/img/database-access/workbench-parameters.png new file mode 100644 index 0000000000000..4e4c7d78b2481 Binary files /dev/null and b/docs/img/database-access/workbench-parameters.png differ diff --git a/docs/img/database-access/workbench-ssl.png b/docs/img/database-access/workbench-ssl.png new file mode 100644 index 0000000000000..d9e541e8ce8e6 Binary files /dev/null and b/docs/img/database-access/workbench-ssl.png differ diff --git a/docs/img/database-access/workbench-test.png b/docs/img/database-access/workbench-test.png new file mode 100644 index 0000000000000..c48ea39ffb68f Binary files /dev/null and b/docs/img/database-access/workbench-test.png differ diff --git a/docs/pages/database-access.mdx b/docs/pages/database-access.mdx new file mode 100644 index 0000000000000..527d582e4d7ed --- /dev/null +++ b/docs/pages/database-access.mdx @@ -0,0 +1,56 @@ +--- +title: Database Access +description: Teleport Database Access introduction, demo and resources +--- + +# Database Access + +Teleport can provide secure access to PostgreSQL and MySQL databases, while +improving both access control and visibility. + +Some of the things you can do with Database Access: + +* Users can retrieve short-lived database certificates using single sign-on + flow thus maintaining their organization-wide identity. +* Configure role-based access controls for databases and implement custom + [access workflows](./enterprise/workflow/index.mdx). +* Capture database access events as well as query activity in the audit log. + +## Demo + +Let's connect to a PostgreSQL server with `psql` and pgAdmin 4 after authenticating +with Github, execute a few SQL queries and observe them in the audit log: + + + +## Getting Started + +Configure Database Access in a 10 minute [Getting Started](./database-access/getting-started.mdx) +guide. + +## Guides + +* [AWS RDS/Aurora PostgreSQL](./database-access/guides/postgres-aws.mdx) +* [AWS RDS/Aurora MySQL](./database-access/guides/mysql-aws.mdx) +* [Self-hosted PostgreSQL](./database-access/guides/postgres-self-hosted.mdx) +* [Self-hosted MySQL](./database-access/guides/mysql-self-hosted.mdx) +* [GUI clients](./database-access/guides/gui-clients.mdx) + +## Resources + +To learn more about configuring role-based access control for Database Access, +check out [RBAC](./database-access/rbac.mdx) section. + +[Architecture](./database-access/architecture.mdx) provides a more in-depth +look at Database Access internals such as networking and security. + +See [Reference](./database-access/reference.mdx) for an overview of +Database Access related configuration and CLI commands. + +## FAQ + +Finally, check out [Frequently Asked Questions](./database-access/faq.mdx). diff --git a/docs/pages/database-access/architecture.mdx b/docs/pages/database-access/architecture.mdx new file mode 100644 index 0000000000000..7d8dba5bc5ee7 --- /dev/null +++ b/docs/pages/database-access/architecture.mdx @@ -0,0 +1,132 @@ +--- +title: Database Access Architecture +description: How Teleport Database Access works +--- + +# Database Access Architecture + +This section provides an overview of Teleport Database Access inner workings. + +## How It Works + +Let's take a look at a sample Database Access deployment: + +![Teleport Database Access Diagram](../../img/database-access/diagram.png) + +In it, we have the following Teleport components: + +* [Teleport Proxy](../architecture/proxy.mdx). A stateless service + that performs a function of an authentication gateway, serves web UI and + accepts database (and other) client connections. +* [Teleport Auth](../architecture/authentication.mdx). Serves as + cluster's certificate authority, handles user authentication/authorization + and issues short-lived client certificates. +* Teleport Database Service. The Database Access' "brain" that connects + to the databases, performs database authentication and protocol parsing. + +Database Service establishes an SSH reverse tunnel to the Proxy. As such, users +do not need to have direct connectivity to the Database Service, or the databases +it's connected to. As long as it can dial back to the cluster's Proxy server, it +can be located behind a firewall. + + +You can have multiple Database Services connected to the cluster. Each +Database Service can be also connected to multiple databases. + + +Let's take a look at the typical flow Database Access users go through to +connect to a database. + +1. A user logs into the cluster with `tsh login` command and retrieves + a client certificate. See [Issuing User Certificates](../architecture/authentication.mdx#issuing-user-certificates) + for more details on how it works. +2. The user picks the database they want to connect to from the list of available + databases shown in `tsh db ls` command and retrieves a short-lived X.509 + certificate for it with `tsh db login`. +3. The user uses a standard database client (e.g. `psql`, `mysql` or one of the + [graphical clients](./guides/gui-clients.mdx)) to connect to the Proxy, authenticating + with the client certificate from step 2. +4. The Proxy authenticates the connection and dispatches it to the appropriate + Database Service based on the routing information encoded in the client + certificate, over the reverse tunnel. +5. The Database Service authenticates the connection, performs an authorization + check, and then establishes the connection to the database. +6. The Database Service begins proxying traffic between the user's database + client and the database. Additionally, it interprets the database wire + protocol messages and submits events to the Teleport audit log. + +## Authentication + +Teleport relies on short-lived X.509 certificates for user authentication, as +well as authentication between internal components. + +Authentication happens in 3 places: + +* Database client connecting to Proxy +* Proxy connecting to Database Service +* Database Service connecting database. + +Let's take a detailed look at each authentication point. + +### Database Client to Proxy + +Database clients authenticate with the Proxy using X.509 client certificates +obtained from the `tsh db login` command. + + +Many database clients/servers refer to these certificates as SSL which is +legacy terminology. In Teleport documentation we most often refer to them as +TLS or x509 certificates. + + +The login command updates database-specific local configuration files (e.g. +PostgreSQL [connection service file](https://www.postgresql.org/docs/13/libpq-pgservice.html) +or MySQL [option file](https://dev.mysql.com/doc/refman/8.0/en/option-files.html) +to group connection information for a particular database, which CLI clients +can refer to. + +For configuring graphical clients, there is a `tsh db config` command that +prints detailed information about the connection such as host/port and location +of the secrets. See [GUI Clients](./gui-clients.mdx) for details. + +### Proxy to Database Service + +The connection between the Proxy and the Database Service is also authenticated +with mutual TLS. + +The Proxy generates a short-lived X.509 certificate signed by the +cluster's host authority, with the client's identity and database routing +information encoded in it, and uses it to authenticate with the Database Service. + +### Database Service to Database + +Database authentication is handled differently for self-hosted databases and +databases hosted by AWS. + +#### Self-Hosted + +Teleport Database Service uses client certificate authentication with self-hosted +database servers. + +See respective configuration guides for [PostgreSQL](./guides/postgres-self-hosted.mdx) +and [MySQL](./guides/mysql-self-hosted.mdx) for details on configuring client certificate +authentication. + +#### AWS RDS / Aurora + +With RDS and Aurora database instances, the Database Service authenticates using +[IAM Authentication](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html). + +The Database Service automatically generates an IAM token for each connection +and uses the token as a password. + +See respective configuration guides for [PostgreSQL](./guides/postgres-aws.mdx) and +[MySQL](./guides/mysql-aws.mdx) for details on configuring IAM authentication. + +## Next Steps + +Please refer to the [RFD #11](https://github.com/gravitational/teleport/blob/024fd582e62560ffc925cd4b4d42c156043c041b/rfd/0011-database-access.md) +for a more in-depth description of the feature scope and design. + +See [Architecture Overview](../architecture/overview.mdx) for general Teleport +architecture principles. diff --git a/docs/pages/database-access/faq.mdx b/docs/pages/database-access/faq.mdx new file mode 100644 index 0000000000000..1989078498224 --- /dev/null +++ b/docs/pages/database-access/faq.mdx @@ -0,0 +1,40 @@ +--- +title: Database Access FAQ +description: Frequently asked questions about Teleport Database Access +--- + +# Database Access FAQ + +## Which database protocols does Teleport Database Access support? + +Teleport Database Access currently supports PostgreSQL and MySQL protocols. + +## Which PostgreSQL protocol features are not supported? + +The following PostgreSQL protocol features aren't currently supported: + +* [Canceling requests in progress](https://www.postgresql.org/docs/current/protocol-flow.html#id-1.10.5.7.9). + Cancel requests issued by the PostgreSQL clients connected to Teleport proxy + won't be passed to the database server. +* Any of the [authentication methods](https://www.postgresql.org/docs/current/auth-methods.html) + except for client certificate authentication and IAM authentication for AWS + RDS and Aurora databases. + +## Do you support X database client? + +Teleport relies on client certificates for authentication so any database client +that supports this method of authentication and uses modern TLS (1.2+) should +work. + +Standard command-line clients such as `psql` and `mysql` are supported, there +are also instructions for configuring select [graphical clients](./guides/gui-clients.mdx). + +## When will you support X database? + +We're focusing on PostgreSQL and MySQL initially but planning to support more +databases in the future based on the customer demand. + +See if the database you're interested in has already been requested among +[Github issues](https://github.com/gravitational/teleport/labels/database-access) +or open a [new issue](https://github.com/gravitational/teleport/issues/new/choose) +to register your interest. diff --git a/docs/pages/database-access/getting-started.mdx b/docs/pages/database-access/getting-started.mdx new file mode 100644 index 0000000000000..2d6e4dc348d03 --- /dev/null +++ b/docs/pages/database-access/getting-started.mdx @@ -0,0 +1,179 @@ +--- +title: Database Access Getting Started Guide +description: Getting started with Teleport Database Access and AWS Aurora PostgreSQL +--- + +# Getting Started + +In this getting started guide we will use Teleport Database Access to connect +to a PostgreSQL AWS Aurora database. + +Here's an overview of what we will do: + +1. Configure AWS Aurora database with IAM authentication. +2. Download and install Teleport and connect it to the Aurora database. +3. Connect to the Aurora database via Teleport. + +## Step 1/3. Setup Aurora + +In order to allow Teleport connections to an Aurora instance, it needs to support +IAM authentication. + +If you don't have a database provisioned yet, create an instance of an Aurora +PostgreSQL in the [RDS control panel](https://console.aws.amazon.com/rds/home). +Make sure to choose "Standard create" database creation method and enable +"Password and IAM database authentication" in the Database Authentication dialog. + +For existing Aurora instances, the status of IAM authentication is displayed on +the Configuration tab and can be enabled by modifying the database instance. + +Next, create the following IAM policy and attach it to the AWS user or service +account. Teleport Database Service will need to use credentials of this AWS user +or service account in order to use this policy. + +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Action": [ + "rds-db:connect" + ], + "Resource": [ + "arn:aws:rds-db:::dbuser:/*" + ] + } + ] +} +``` + +This policy allows any database account to connect to the Aurora instance specified +with resource ID using IAM auth. + + +Database resource ID is shown on the Configuration tab of a particular +database instance in RDS control panel, under "Resource id". For regular +RDS database it starts with `db-` prefix. For Aurora, use the database +cluster resource ID (`cluster-`), not individual instance ID. + + +Finally, connect to the database and create a database account with IAM auth +support (or update an existing one). Once connected, execute the following +SQL statements to create a new database account and allow IAM auth for it: + +```sql +CREATE USER alice; +GRANT rds_iam TO alice; +``` + +For more information about connecting to the PostgreSQL instance directly, +see Amazon [documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html). + +## Step 2/3. Setup Teleport + +Teleport Database Access is available starting from `6.0.0` release. + +Download the appropriate version of Teleport for your platform from the table +below, or visit our [downloads page](https://goteleport.com/teleport/download). + +{!docs/pages/preview/releases-table.mdx!} + +Teleport requires a valid TLS certificate to operate and can fetch one automatically +using Let's Encrypt [ACME](https://letsencrypt.org/how-it-works/) protocol. + +We will assume that you have configured DNS records for `teleport.example.com` and +`*.teleport.example.com` to point to the node where you're launching Teleport. + +Let's generate a Teleport config with ACME enabled: + +```shell +$ teleport configure --cluster-name=teleport.example.com --acme --acme-email=alice@example.com > /tmp/teleport.yaml +``` + + +Teleport's ACME protocol integration currently requires web proxy to run on +port 443 so open /tmp/teleport.yaml and update `proxy_service.web_listen_addr` +and `proxy_service.public_addr` to use port 443 instead of the default 3080. + + +Now start Teleport and point it to your Aurora database instance. Make sure to +update the database endpoint and region appropriately. + +```shell +$ sudo teleport start --config=/tmp/teleport.yaml \ + --roles=proxy,auth,db \ + --db-name=aurora \ + --db-protocol=postgres \ + --db-uri=postgres-aurora-instance-1.abcdefghijklm.us-west-1.rds.amazonaws.com:5432 \ + --db-aws-region=us-west-1 +``` + + +The node that connects to the database should have AWS credentials configured +with the policy from [step 1](#step-13-setup-aurora). + + +Create the role that will allow a user to connect to any database using any +database account: + +```sh +$ tctl create <-aurora user=alice dbname=postgres" +``` + +## Next Steps + +For the next steps, dive deeper into the topics relevant to your Database +Access use-case, for example: + +* Learn in more detail about AWS hosted [PostgreSQL](./guides/postgres-aws.mdx) or [MySQL](./guides/mysql-aws.mdx). +* Learn how to connect to a self-hosted [PostgreSQL](./guides/postgres-self-hosted.mdx) or [MySQL](./guides/mysql-self-hosted.mdx). +* Learn how to configure [GUI clients](./guides/gui-clients.mdx). +* Learn about Database Access [role-based access control](./rbac.mdx). +* See [frequently asked questions](./faq.mdx). diff --git a/docs/pages/database-access/guides.mdx b/docs/pages/database-access/guides.mdx new file mode 100644 index 0000000000000..dace81034b4cd --- /dev/null +++ b/docs/pages/database-access/guides.mdx @@ -0,0 +1,12 @@ +--- +title: Database Access Guides +description: Guides for configuring Teleport Database Access with self-hosted or AWS RDS/Aurora PostgreSQL and MySQL +--- + +# Guides + +* [AWS RDS/Aurora PostgreSQL](./guides/postgres-aws.mdx) +* [AWS RDS/Aurora MySQL](./guides/mysql-aws.mdx) +* [Self-hosted PostgreSQL](./guides/postgres-self-hosted.mdx) +* [Self-hosted MySQL](./guides/mysql-self-hosted.mdx) +* [GUI clients](./guides/gui-clients.mdx) diff --git a/docs/pages/database-access/guides/gui-clients.mdx b/docs/pages/database-access/guides/gui-clients.mdx new file mode 100644 index 0000000000000..9ffbd70f2c3fb --- /dev/null +++ b/docs/pages/database-access/guides/gui-clients.mdx @@ -0,0 +1,79 @@ +--- +title: Database Access GUI Clients +description: How to configure graphical database clients +--- + +# Graphical Database Clients + +This page provides instructions on how to configure various graphical database +clients to work with Teleport Database Access. + +Pick the client you're interested in from the table of contents on the right. + +## pgAdmin 4 + +[pgAdmin 4](https://www.pgadmin.org/) is a popular graphical client for +PostgreSQL servers. + +pgAdmin runs as a server that stores connection information for databases and +serves a management web UI. As such, pgAdmin server must run on the machine +where `tsh db login` is executed and have access to the certificate authority +and client certificate/key pair produced by that command. + +To configure a new connection, right-click on Servers in the main browser view +and create a new server: + +![pgAdmin Add Server](../../../img/database-access/pgadmin-add-server.png) + +On the General tab of the new server dialog, enter the server connection name: + +![pgAdmin General](../../../img/database-access/pgadmin-general.png) + +On the Connection tab, enter the default database name (Maintenance database) +and the connection service name, same as when you specify connecting using +`psql`. Leave all the other fields blank: + +![pgAdmin Connection](../../../img/database-access/pgadmin-connection.png) + +On the SSL tab, set SSL mode to "full": + +![pgAdmin SSL](../../../img/database-access/pgadmin-ssl.png) + +Click Save, and pgAdmin should immediately connect. + +## MySQL Workbench + +[MySQL Workbench](https://www.mysql.com/products/workbench/) is a visual tool +that provides comprehensive MySQL administration and SQL development tools. + +To connect to a database using MySQL Workbench, first retrieve the database +credentials using `tsh db login` command. After logging in, take a note of +the database configuration parameters shown by `tsh db config` command: + +```bash +$ tsh db config +Name: aurora +Host: root.gravitational.io +Port: 3036 +User: r0mant +Database: +CA: /Users/r0mant/.tsh/keys/root.gravitational.io/certs.pem +Cert: /Users/r0mant/.tsh/keys/root.gravitational.io/r0mant-db/root/aurora-x509.pem +Key: /Users/r0mant/.tsh/keys/root.gravitational.io/r0mant +``` + +In MySQL Workbench Setup New Connection dialog, fill out Connection Name, Hostname, +Port and Username: + +![MySQL Workbench Parameters](../../../img/database-access/workbench-parameters.png) + +On the SSL tab, set SSL mode to "Require and Verify Identity" and enter paths +to CA, certificate and private key files from `tsh db config` command: + +![MySQL Workbench SSL](../../../img/database-access/workbench-ssl.png) + +Optionally, click Test Connection to verify connectivity: + +![MySQL Workbench Test](../../../img/database-access/workbench-test.png) + +Save the connection, and connect to the database. diff --git a/docs/pages/database-access/guides/mysql-aws.mdx b/docs/pages/database-access/guides/mysql-aws.mdx new file mode 100644 index 0000000000000..5302406f0f85d --- /dev/null +++ b/docs/pages/database-access/guides/mysql-aws.mdx @@ -0,0 +1,294 @@ +--- +title: Database Access with MySQL on AWS +description: How to configure Teleport Database Access with AWS RDS/Aurora MySQL +--- + +# MySQL on AWS + +## Enable IAM Authentication + +Teleport Database Access for AWS RDS and Aurora uses IAM authentication which +can be enabled with the following steps. + +Open [Amazon RDS console](https://console.aws.amazon.com/rds/) and create a new +database instance with IAM authentication enabled, or modify an existing one to +turn it on. Make sure to use MySQL database type. + +See [Enabling and disabling IAM database authentication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Enabling.html) +for more information. + +## Create IAM Policy + +To allow Teleport database service to log into the database instance using auth +token, create an IAM policy and attach it to the user whose credentials the +database service will be using. For example: + +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Action": [ + "rds-db:connect" + ], + "Resource": [ + "arn:aws:rds-db:us-east-2:1234567890:dbuser:cluster-ABCDEFGHIJKL01234/*" + ] + } + ] +} +``` + +The resource ARN in the policy has the following format: + +``` +arn:aws:rds-db:::dbuser:/ +``` + +Parameters: + +* `region`: AWS region where the database cluster is deployed. +* `account-id`: AWS account ID the database cluster is deployed under. +* `db-cluster-resource-id`: identifier for the database cluster, can be found + under Configuration section in the RDS control panel. +* `db-user-name`: name of the database account to associate with IAM + authentication. Can be a wildcard. + +See [Creating and using an IAM policy for IAM database access](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) +for more information. + +## Create Database User + +Database accounts must have IAM authentication enabled in order to be allowed +access. For MySQL: + +```sql +CREATE USER alice IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS'; +``` + +See [Creating a database account using IAM authentication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.DBAccounts.html) +for more information. + +## Configure Teleport + +Teleport Database Access is available starting from `6.0` release. + +Download the appropriate version of Teleport for your platform from the table +below, or visit our [downloads page](https://goteleport.com/teleport/download). + +{!docs/pages/preview/releases-table.mdx!} + +Follow the installation [instructions](../../installation.mdx). + +### Start Auth/Proxy Service + +Create a configuration file for a Teleport service that will be running +auth and proxy servers: + +```yaml +teleport: + data_dir: /var/lib/teleport + nodename: test +auth_service: + enabled: "yes" +proxy_service: + enabled: "yes" + # Set public address proxy will be reachable at. + public_addr: teleport.example.com:3080 + # MySQL proxy is listening on a separate port and needs to be enabled + # on the proxy server. + mysql_listen_addr: 0.0.0.0:3036 +ssh_service: + enabled: "no" +``` + +Start the service: + +```sh +$ teleport start --config=/path/to/teleport.yaml +``` + +Generate a short-lived join token for the database service and save it for +example in `/tmp/token`: + +```sh +$ tctl tokens add \ + --type=db \ + --db-name=aurora \ + --db-protocol=mysql \ + --db-uri=mysql-aurora-instance-1.xxx.us-east-1.rds.amazonaws.com:3306 +``` + +### Create Role and User + +Create the role that will allow a user to connect to any database using any +database account: + +```sh +$ tctl --config=/path/to/teleport.yaml create < +A single Teleport process can run multiple different services, for example +multiple database access proxies as well as running other services such an +SSH service or an application access proxy. + + +Start the database service: + +```sh +$ teleport start --config=/path/to/teleport-db.yaml --token=/tmp/token +``` + +### AWS Credentials + +When setting up Teleport database service with AWS RDS or Aurora, it must have +an IAM role allowing it to connect to that particular database instance. An +example of such a policy is shown in the [Create IAM Policy](#create-iam-policy) +section above. See [Creating and using an IAM policy for IAM database access](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) +in AWS documentation. + +Teleport database service uses the default credential provider chain to find AWS +credentials. See [Specifying Credentials](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials) +for more information. + +## Connect + +Once the database service has joined the cluster, login to see the available +databases: + +```sh +$ tsh login --proxy=teleport.example.com:3080 --user=testuser +$ tsh db ls +Name Description Labels +------ ---------------- -------- +aurora AWS Aurora MySQL env=dev +``` + +Note that you will only be able to see databases your role has access to. See +[RBAC](../rbac.mdx) section for more details. + +To connect to a particular database server, first retrieve credentials from +Teleport using `tsh db login` command: + +```sh +$ tsh db login aurora +``` + + +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: + +```sh +$ tsh db login --db-user=root --db-name=mysql aurora +``` + +When logging into a MySQL database, `tsh` automatically configures a section +in the [option file](https://dev.mysql.com/doc/refman/8.0/en/option-files.html) +with the name of `client_-` which `mysql` +client can refer to via "group suffix" flag. + +Suppose the cluster name is "root", then you can connect to the database using +the following `mysql` command: + +```sh +# Use default database user and database name. +$ mysql --defaults-group-suffix=_root-aurora +# Specify database user and database name explicitly. +$ mysql --defaults-group-suffix=_root-aurora --user=alice --database=metrics +``` + +To log out of the database and remove credentials: + +```sh +# Remove credentials for a particular database instance. +$ tsh db logout aurora +# Remove credentials for all database instances. +$ tsh db logout +``` diff --git a/docs/pages/database-access/guides/mysql-self-hosted.mdx b/docs/pages/database-access/guides/mysql-self-hosted.mdx new file mode 100644 index 0000000000000..c09695f3710c5 --- /dev/null +++ b/docs/pages/database-access/guides/mysql-self-hosted.mdx @@ -0,0 +1,273 @@ +--- +title: Database Access with Self-Hosted MySQL +description: How to configure Teleport Database Access with self-hosted MySQL +--- + +# Self-Hosted MySQL + +## Create Certificate/Key Pair + +Teleport uses mutual TLS for authentication to MySQL instances. As such, +self-hosted MySQL instances must be configured with Teleport's certificate +authority and a certificate/key pair that Teleport can validate. + +To create these secrets, use `tctl auth sign` command. Note that it requires a +running Teleport cluster and [should be run](../../architecture/overview.mdx#tctl) +on the auth server. + +```sh +# Export Teleport's certificate authority and generate certificate/key pair +# for host db.example.com with a one year validity period. +$ tctl auth sign --format=db --host=db.example.com --out=server --ttl=8760h +``` + +Flag descriptions: + +* `--format=db`: instructs the command to produce secrets in the format suitable + for configuring a database server. +* `--host=db.example.com`: server name to encode in the certificate, should + match the hostname Teleport will be connecting to the database at. +* `--out=server`: name prefix for output files. +* `--ttl=8760h`: certificate validity period. + +The command will create 3 files: `server.cas` with Teleport's certificate +authority and `server.crt`/`server.key` with generated certificate/key pair. + + +Teleport signs database certificates with the host authority. As such, +when performing [host certificates rotation](../../admin-guide.mdx#certificate-rotation), +the database certificates must be updated as well. + + +## Configure MySQL Server + +To configure MySQL server to accept TLS connections, add the following to +MySQL configuration file `mysql.cnf`: + +```conf +[mysqld] +require_secure_transport=ON +ssl-ca=/path/to/server.cas +ssl-cert=/path/to/server.crt +ssl-key=/path/to/server.key +``` + +Additionally, MySQL database user accounts must be configured to require a +valid client certificate: + +```sql +CREATE USER 'alice'@'%' REQUIRE X509; +ALTER USER 'alice'@'%' REQUIRE X509; +``` + +See [Configuring MySQL to Use Encrypted Connections](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html) +in MySQL documentation for more details. + +## Configure Teleport + +Teleport Database Access is available starting from `6.0` release. + +Download the appropriate version of Teleport for your platform from the table +below, or visit our [downloads page](https://goteleport.com/teleport/download). + +{!docs/pages/preview/releases-table.mdx!} + +Follow the installation [instructions](../../installation.mdx). + +### Start Auth/Proxy Service + +Create a configuration file for a Teleport service that will be running +auth and proxy servers: + +```yaml +teleport: + data_dir: /var/lib/teleport + nodename: test +auth_service: + enabled: "yes" +proxy_service: + enabled: "yes" + # Set public address proxy will be reachable at. + public_addr: teleport.example.com:3080 + # MySQL proxy is listening on a separate port and needs to be enabled + # on the proxy server. + mysql_listen_addr: 0.0.0.0:3036 +ssh_service: + enabled: "no" +``` + +Start the service: + +```sh +$ teleport start --config=/path/to/teleport.yaml +``` + +Generate a short-lived join token for the database service and save it for +example in `/tmp/token`: + +```sh +$ tctl tokens add \ + --type=db \ + --db-name=test \ + --db-protocol=postgres \ + --db-uri=postgres.example.com:5432 +``` + +### Create Role and User + +Create the role that will allow a user to connect to any database using any +database account: + +```sh +$ tctl --config=/path/to/teleport.yaml create < +A single Teleport process can run multiple different services, for example +multiple database access proxies as well as running other services such an +SSH service or an application access proxy. + + +Start the database service: + +```sh +$ teleport start --config=/path/to/teleport-db.yaml --token=/tmp/token +``` + +## Connect + +Once the database service has joined the cluster, login to see the available +databases: + +```sh +$ tsh login --proxy=teleport.example.com:3080 --user=testuser +$ tsh db ls +Name Description Labels +------- ------------- -------- +example Example MySQL env=dev +``` + +Note that you will only be able to see databases your role has access to. See +[RBAC](../rbac.mdx) section for more details. + +To connect to a particular database server, first retrieve credentials from +Teleport using `tsh db login` command: + +```sh +$ tsh db login example +``` + + +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: + +```sh +$ tsh db login --db-user=root --db-name=mysql example +``` + +When logging into a MySQL database, `tsh` automatically configures a section +in the [option file](https://dev.mysql.com/doc/refman/8.0/en/option-files.html) +with the name of `client_-` which `mysql` +client can refer to via "group suffix" flag. + +Suppose the cluster name is "root", then you can connect to the database using +the following `mysql` command: + +```sh +# Use default database user and database name. +$ mysql --defaults-group-suffix=_root-example +# Specify database user and database name explicitly. +$ mysql --defaults-group-suffix=_root-example --user=alice --database=metrics +``` + +To log out of the database and remove credentials: + +```sh +# Remove credentials for a particular database instance. +$ tsh db logout example +# Remove credentials for all database instances. +$ tsh db logout +``` diff --git a/docs/pages/database-access/guides/postgres-aws.mdx b/docs/pages/database-access/guides/postgres-aws.mdx new file mode 100644 index 0000000000000..95a068b1b9a44 --- /dev/null +++ b/docs/pages/database-access/guides/postgres-aws.mdx @@ -0,0 +1,293 @@ +--- +title: Database Access with PostgreSQL on AWS +description: How to configure Teleport Database Access with AWS RDS/Aurora PostgreSQL +--- + +# PostgreSQL on AWS + +## Enable IAM Authentication + +Teleport Database Access for AWS RDS and Aurora uses IAM authentication which +can be enabled with the following steps. + +Open [Amazon RDS console](https://console.aws.amazon.com/rds/) and create a new +database instance with IAM authentication enabled, or modify an existing one to +turn it on. Make sure to use PostgreSQL database type. + +See [Enabling and disabling IAM database authentication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Enabling.html) +for more information. + +## Create IAM Policy + +To allow Teleport database service to log into the database instance using auth +token, create an IAM policy and attach it to the user whose credentials the +database service will be using. For example: + +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Action": [ + "rds-db:connect" + ], + "Resource": [ + "arn:aws:rds-db:us-east-2:1234567890:dbuser:cluster-ABCDEFGHIJKL01234/*" + ] + } + ] +} +``` + +The resource ARN in the policy has the following format: + +``` +arn:aws:rds-db:::dbuser:/ +``` + +Parameters: + +* `region`: AWS region where the database cluster is deployed. +* `account-id`: AWS account ID the database cluster is deployed under. +* `db-cluster-resource-id`: identifier for the database cluster, can be found + under Configuration section in the RDS control panel. +* `db-user-name`: name of the database account to associate with IAM + authentication. Can be a wildcard. + +See [Creating and using an IAM policy for IAM database access](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) +for more information. + +## Create Database User + +Database users must have a `rds_iam` role in order to be allowed access. For +PostgreSQL: + +```sql +CREATE USER alice; +GRANT rds_iam TO alice; +``` + +See [Creating a database account using IAM authentication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.DBAccounts.html) +for more information. + +## Configure Teleport + +Teleport Database Access is available starting from `6.0` release. + +Download the appropriate version of Teleport for your platform from the table +below, or visit our [downloads page](https://goteleport.com/teleport/download). + +{!docs/pages/preview/releases-table.mdx!} + +Follow the installation [instructions](../../installation.mdx). + +### Start Auth/Proxy Service + +Create a configuration file for a Teleport service that will be running +auth and proxy servers: + +```yaml +teleport: + data_dir: /var/lib/teleport + nodename: test +auth_service: + enabled: "yes" +proxy_service: + enabled: "yes" + # Set public address proxy will be reachable at. + public_addr: teleport.example.com:3080 + # PostgreSQL proxy is listening on a regular web proxy port. + web_listen_addr: 0.0.0.0:3080 +ssh_service: + enabled: "no" +``` + +Start the service: + +```sh +$ teleport start --config=/path/to/teleport.yaml +``` + +Generate a short-lived join token for the database service and save it for +example in `/tmp/token`: + +```sh +$ tctl tokens add \ + --type=db \ + --db-name=test \ + --db-protocol=postgres \ + --db-uri=postgres.example.com:5432 +``` + +### Create Role and User + +Create the role that will allow a user to connect to any database using any +database account: + +```sh +$ tctl --config=/path/to/teleport.yaml create < +A single Teleport process can run multiple different services, for example +multiple database access proxies as well as running other services such an +SSH service or an application access proxy. + + +Start the database service: + +```sh +$ teleport start --config=/path/to/teleport-db.yaml --token=/tmp/token +``` + +### AWS Credentials + +When setting up Teleport database service with AWS RDS or Aurora, it must have +an IAM role allowing it to connect to that particular database instance. An +example of such a policy is shown in the [Create IAM Policy](#create-iam-policy) +section above. See [Creating and using an IAM policy for IAM database access](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) +in AWS documentation. + +Teleport database service uses the default credential provider chain to find AWS +credentials. See [Specifying Credentials](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials) +for more information. + +## Connect + +Once the database service has joined the cluster, login to see the available +databases: + +```sh +$ tsh login --proxy=teleport.example.com:3080 --user=testuser +$ tsh db ls +Name Description Labels +------ --------------------- -------- +aurora AWS Aurora PostgreSQL env=dev +``` + +Note that you will only be able to see databases your role has access to. See +[RBAC](../rbac.mdx) section for more details. + +To connect to a particular database server, first retrieve credentials from +Teleport using `tsh db login` command: + +```sh +$ tsh db login aurora +``` + + +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: + +```sh +$ tsh db login --db-user=postgres --db-name=postgres aurora +``` + +When logging into a PostgreSQL database, `tsh` automatically configures a section +in the [connection service file](https://www.postgresql.org/docs/current/libpq-pgservice.html) +with the name of `-`. + +Suppose the cluster name is "root", then you can connect to the database using +the following `psql` command: + +```sh +# Use default database user and database name. +$ psql "service=root-aurora" +# Specify database user and database name explicitly. +$ psql "service=root-aurora user=alice dbname=metrics" +``` + +To log out of the database and remove credentials: + +```sh +# Remove credentials for a particular database instance. +$ tsh db logout aurora +# Remove credentials for all database instances. +$ tsh db logout +``` diff --git a/docs/pages/database-access/guides/postgres-self-hosted.mdx b/docs/pages/database-access/guides/postgres-self-hosted.mdx new file mode 100644 index 0000000000000..63339c5159f82 --- /dev/null +++ b/docs/pages/database-access/guides/postgres-self-hosted.mdx @@ -0,0 +1,274 @@ +--- +title: Database Access with Self-Hosted PostgreSQL +description: How to configure Teleport Database Access with self-hosted PostgreSQL +--- + +# Self-Hosted PostgreSQL + +## Create Certificate/Key Pair + +Teleport uses mutual TLS for authentication to PostgreSQL instances. As such, +self-hosted PostgreSQL instances must be configured with Teleport's certificate +authority and a certificate/key pair that Teleport can validate. + +To create these secrets, use `tctl auth sign` command. Note that it requires a +running Teleport cluster and [should be run](../../architecture/overview.mdx#tctl) +on the auth server. + +```sh +# Export Teleport's certificate authority and generate certificate/key pair +# for host db.example.com with a one year validity period. +$ tctl auth sign --format=db --host=db.example.com --out=server --ttl=8760h +``` + +Flag descriptions: + +* `--format=db`: instructs the command to produce secrets in the format suitable + for configuring a database server. +* `--host=db.example.com`: server name to encode in the certificate, should + match the hostname Teleport will be connecting to the database at. +* `--out=server`: name prefix for output files. +* `--ttl=8760h`: certificate validity period. + +The command will create 3 files: `server.cas` with Teleport's certificate +authority and `server.crt`/`server.key` with generated certificate/key pair. + + +Teleport signs database certificates with the host authority. As such, +when performing [host certificates rotation](../../admin-guide.mdx#certificate-rotation), +the database certificates must be updated as well. + + +## Configure PostgreSQL Server + +To configure PostgreSQL server to accept TLS connections, add the following +to PostgreSQL configuration file `postgresql.conf`: + +```conf +ssl = on +ssl_cert_file = '/path/to/server.crt' +ssl_key_file = '/path/to/server.key' +ssl_ca_file = '/path/toa/server.cas' +``` + +See [Secure TCP/IP Connections with SSL](https://www.postgresql.org/docs/current/ssl-tcp.html) +in PostgreSQL documentation for more details. + +Additionally, PostgreSQL should be configured to require client certificate +authentication from clients connecting over TLS. This can be done by adding +the following entries to PostgreSQL host-based authentication file `pg_hba.conf`: + +```conf +hostssl all all ::/0 cert +hostssl all all 0.0.0.0/0 cert +``` + +See [The pg_hba.conf File](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html) +in PostgreSQL documentation for more details. + +## Configure Teleport + +Teleport Database Access is available starting from `6.0` release. + +Download the appropriate version of Teleport for your platform from the table +below, or visit our [downloads page](https://goteleport.com/teleport/download). + +{!docs/pages/preview/releases-table.mdx!} + +Follow the installation [instructions](../../installation.mdx). + +### Start Auth and Proxy Services + +Create a configuration file for a Teleport service that will be running +auth and proxy servers: + +```yaml +teleport: + data_dir: /var/lib/teleport + nodename: test +auth_service: + enabled: "yes" +proxy_service: + enabled: "yes" + # Set public address proxy will be reachable at. + public_addr: teleport.example.com:3080 + # PostgreSQL proxy is listening on a regular web proxy port. + web_listen_addr: 0.0.0.0:3080 +ssh_service: + enabled: "no" +``` + +Start the service: + +```sh +$ teleport start --config=/path/to/teleport.yaml +``` + +Generate a short-lived join token for the database service and save it for +example in `/tmp/token`: + +```sh +$ tctl --config=/path/to/teleport.yaml tokens add \ + --type=db \ + --db-name=test \ + --db-protocol=postgres \ + --db-uri=postgres.example.com:5432 +``` + +### Create Role and User + +Create the role that will allow a user to connect to any database using any +database account: + +```sh +$ tctl --config=/path/to/teleport.yaml create < +A single Teleport process can run multiple different services, for example +multiple database access proxies as well as running other services such as an +SSH service or an application access proxy. + + +Start the database service: + +```sh +$ teleport start --config=/path/to/teleport-db.yaml --token=/tmp/token +``` + +## Connect + +Once the database service has joined the cluster, login to see the available +databases: + +```sh +$ tsh login --proxy=teleport.example.com:3080 --user=testuser +$ tsh db ls +Name Description Labels +------- ------------------ -------- +example Example PostgreSQL env=dev +``` + +Note that you will only be able to see databases your role has access to. See +[RBAC](../rbac.mdx) section for more details. + +To connect to a particular database server, first retrieve credentials from +Teleport using `tsh db login` command: + +```sh +$ tsh db login example +``` + + +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: + +```sh +$ tsh db login --db-user=postgres --db-name=postgres example +``` + +When logging into a PostgreSQL database, `tsh` automatically configures a section +in the [connection service file](https://www.postgresql.org/docs/current/libpq-pgservice.html) +with the name of `-`. + +Suppose the cluster name is "root", then you can connect to the database using +the following `psql` command: + +```sh +# Use default database user and database name. +$ psql "service=root-example" +# Specify database user and database name explicitly. +$ psql "service=root-example user=alice dbname=metrics" +``` + +To log out of the database and remove credentials: + +```sh +# Remove credentials for a particular database instance. +$ tsh db logout example +# Remove credentials for all database instances. +$ tsh db logout +``` diff --git a/docs/pages/database-access/rbac.mdx b/docs/pages/database-access/rbac.mdx new file mode 100644 index 0000000000000..a2660b596be45 --- /dev/null +++ b/docs/pages/database-access/rbac.mdx @@ -0,0 +1,134 @@ +--- +title: Database Access RBAC +description: Role-based access control (RBAC) for Teleport Database Access +--- + +# Database Access Role-Based Access Control + +Role-based access control (or RBAC, for short) allows administrators to set up +granular access policies for databases connected to Teleport. + +An example of a policy could be, _"database administrators have access to +everything, QA team and engineers have full access to staging databases, and +engineers can gain temporary access to the production database in case of +emergency"_. + +For a more general description of Teleport roles and examples see [RBAC](../enterprise/ssh-rbac.mdx), as +this section focuses on configuring RBAC for Database Access. + +## Role Configuration + +Teleport's "role" resource provides the following instruments for restricting +database access: + +```yaml +kind: role +version: v3 +metadata: + name: developer +spec: + allow: + # Label selectors for database instances this role has access to. + # + # These will be matched against the static/dynamic labels set on the + # database service. + db_labels: + environment: ["dev", "stage"] + + # Database account names this role can connect as. + db_users: ["viewer", "editor"] + + # Database names this role will be able to connect to. + # + # Note, this is not the same as the "name" field in "db_service", this is + # the database names within a particular database instance. + # + # Also note, this setting has effect only for PostgreSQL. It does not + # currently have any effect on MySQL databases/schemas. + db_names: ["main", "metrics", "postgres"] +``` + +It is possible to use wildcards to match any database names/users. + +For example, the following role permits access to any database/user within a +production database except for the internal "postgres" database/user: + +```yaml +kind: role +version: v3 +metadata: + name: developer +spec: + allow: + db_labels: + environment: ["prod"] + db_users: ["*"] + db_names: ["*"] + deny: + db_users: ["postgres"] + db_names: ["postgres"] +``` + + +Deny rules will match greedily. In the example above, a database connection +attempting to use "postgres" database account (regardless of database instance +or database name) or "postgres" database name (regardless of database instance +or database account) will be rejected. + + +## Database Names + +There's a distinction in how different database servers handle logical databases +which leads to a difference in how `db_names` role field is applied to a connection +attempt. + +PostgreSQL supports multiple logical databases, and each logical database can +contain multiple schemas. In order to change to a different database, a user +disconnects from the current one and establishes a new connection. During a +PostgreSQL connection attempt, `db_names` field is checked against the name +of the logical database that the user is connecting to. + +In MySQL a logical "database" and a "schema" are synonyms for each other, and +the scope of permissions a user has once connected is determined by the permission +grants set on the account within the database. As such, `db_names` role field +is not currently enforced on MySQL connection attempts. + +## Template Variables + +Similar to other role fields, `db_*` fields support templating variables. + +The `{{external.xyz}}` variables are replaced with values from external [SSO](../enterprise/sso/ssh-sso.mdx) +providers. For OIDC, they will be expanded with a value of an "xyz" claim; for +SAML — with an "xyz" assertion value. + +For example, here is what a role may look like if you want to assign allowed +database names from the user's Okta `databases` assertion: + +```yaml +spec: + allow: + db_names: ["{% raw %}{{external.databases}}{% endraw %}"] +``` + +The `{{internal.db_users}}` and `{{internal.db_names}}` variables permit sharing +allowed database accounts and names with remote clusters. They will be replaced +with the respective properties of a remote user connecting from a root cluster. + +For example, suppose a user in the root cluster has the following role: + +```yaml +spec: + allow: + db_users: ["postgres"] + db_names: ["postgres"] +``` + +The role on the leaf cluster can be set up to use the user's allowed database +accounts and names: + +```yaml +spec: + allow: + db_users: ["{% raw %}{{internal.db_users}}{% endraw %}"] + db_names: ["{% raw %}{{internal.db_names}}{% endraw %}"] +``` diff --git a/docs/pages/database-access/reference.mdx b/docs/pages/database-access/reference.mdx new file mode 100644 index 0000000000000..6e195ae3c6898 --- /dev/null +++ b/docs/pages/database-access/reference.mdx @@ -0,0 +1,137 @@ +--- +title: Database Access Reference +description: Configuration and CLI reference for Teleport Database Access +--- + +# Database Access Reference + +## Configuration + +The following snippet shows full YAML configuration of a Database Service +appearing in `teleport.yaml` configuration file: + +```yaml +db_service: + # Enables the Database Service. + enabled: "yes" + # This section contains definitions of all databases proxied by this + # service, it can contain multiple database instances. + databases: + # Name of the database proxy instance, used to reference in CLI. + - name: "prod" + # Free-form description of the database proxy instance. + description: "Production database" + # Database protocol. Can be "postgres" or "mysql". + protocol: "postgres" + # Database connection endpoint. Must be reachable from Database Service. + uri: "postgres.example.com:5432" + # Optional path to the CA used to validate the database certificate. + ca_cert_file: /path/to/ca.pem + # AWS specific configuration, only required for RDS and Aurora. + aws: + # Region the database is deployed in. + region: "us-east-1" + # Static labels to assign to the database. Used in RBAC. + static_labels: + env: "prod" + # Dynamic labels ("commands"). Used in RBAC. + dynamic_labels: + - name: "hostname" + command: ["hostname"] + period: 1m0s +``` + +The following Proxy configuration is relevant for Database Access: + +```yaml +proxy_service: + enabled: "yes" + listen_addr: 0.0.0.0:3023 + tunnel_listen_addr: 0.0.0.0:3024 + # Database clients will be connecting to the Proxy over this hostname. + public_addr: teleport.example.com:3080 + # PostgreSQL proxy is listening on the regular web proxy port. + web_listen_addr: 0.0.0.0:3080 + # MySQL proxy is listening on a separate port and needs to be enabled + # on the proxy server. + mysql_listen_addr: 0.0.0.0:3036 +``` + +## CLI + +This section shows CLI commands relevant for Database Access. + +### tctl auth sign + +When invoked with a `--format=db` flag, produces a certificate authority, a +client certificate and a private key file used for configuring Database +Access with self-hosted database instances. + +```shell +$ tctl auth sign --format=db --host=db.example.com --out=server --ttl=8760h +``` + +| Flag | Description | +|------------|-------------| +| `--format` | When given value `db`, produces secrets in database compatible format. | +| `--host` | Server name to encode in the certificate. Must match the hostname Teleport will be connecting to the database at. | +| `--out` | Name prefix for output files. | +| `--ttl` | Certificate validity period. | + +### tsh db ls + +Lists available databases and their connection information. + +```shell +$ tsh db ls +``` + +### tsh db login + +Retrieves database credentials. + +```shell +$ tsh db login example +$ tsh db login --db-user=postgres --db-name=postgres example +``` + +| Flag | Description | +|-------------|-------------| +| `--db-user` | Optionally, set default database account name to connect as. | +| `--db-name` | Optionally, set default database name to connect to. | + +### tsh db logout + +Removes database credentials. + +```shell +$ tsh db logout example +$ tsh db logout +``` + +### tsh db env + +Outputs environment variables for a particular database. + +```shell +$ tsh db env +$ tsh db env --db=example +$ eval $(tsh db env) +``` + +| Flag | Description | +|--------|-------------| +| `--db` | Database server name to print environment for. Required, if logged into multiple databases simultaneously. | + +### tsh db config + +Prints database connection information. Useful when configuring GUI clients. + +```shell +$ tsh db config +$ tsh db config --db=example +``` + +| Flag | Description | +|--------|-------------| +| `--db` | Database server name to print configuration for. Required, if logged into multiple databases simultaneously. | diff --git a/docs/pages/preview/database-access.mdx b/docs/pages/preview/database-access.mdx deleted file mode 100644 index b969a92027646..0000000000000 --- a/docs/pages/preview/database-access.mdx +++ /dev/null @@ -1,645 +0,0 @@ ---- -title: Teleport Database Access -description: Secure and Audited Access to Postgres Databases. Documentation to outline our preview. -h1: Teleport Database Access Preview ---- - -Teleport Database Access allows organizations to use Teleport as a proxy to -provide secure access to their databases while improving both visibility and -access control. - -To find out whether you can benefit from using Database Access, see if you're -facing any of the following challenges in your organization: - -* Do you need to protect and segment access to your databases? -* Do you need provide SSO and auditing for the database access? -* Do you have compliance requirements for data protection and access monitoring - like PCI/FedRAMP? - -If so, Database Access might help you solve some of these challenges. - -## Features - -With Database Access users can: - -* Provide secure access to databases without exposing them over the public - network through Teleport's reverse tunnel subsystem. -* Control access to specific database instances as well as individual - databases and database users through Teleport's RBAC model. -* Track individual users' access to databases as well as query activity - through Teleport's audit log. - -## Demo - - - -## Getting Started - -In this guide we will use Teleport Database Access to connect to a PostgreSQL -flavored AWS Aurora database. Here's an overview of what we will do: - -1. Configure AWS Aurora database with IAM authentication. -2. Download and install Teleport and connect it to the Aurora database. -3. Connect to the Aurora database via Teleport. - -### Step 1/3. Setup Aurora - -In order to allow Teleport connections to an Aurora instance, it needs to support -IAM authentication. - -If you don't have a database provisioned yet, create an instance of an Aurora -PostgreSQL in the [RDS control panel](https://console.aws.amazon.com/rds/home). -Make sure to choose "Standard create" database creation method and enable -"Password and IAM database authentication" in the Database Authentication dialog. - -For existing Aurora instances, the status of IAM authentication is displayed on -the Configuration tab and can be enabled by modifying the database instance. - -Next, create the following IAM policy attached to a user whose credentials a -Teleport process will be using to allow it to connect to the database: - -```json -{ - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": [ - "rds-db:connect" - ], - "Resource": [ - "arn:aws:rds-db:::dbuser:/*" - ] - } - ] -} -``` - - -Database resource ID is shown on the Configuration tab of a particular -database instance in RDS control panel, under "Resource id". For regular -RDS database it starts with `db-` prefix. For Aurora, use the database -cluster resource ID (`cluster-`), not individual instance ID. - - -Finally, connect to the database and create a database account with IAM auth -support (or update an existing one). Once connected, execute the following -SQL statements to create a new database account and allow IAM auth for it: - -```sql -CREATE USER alice; -GRANT rds_iam TO alice; -``` - -For more information about connecting to the PostgreSQL instance directly, -see Amazon [documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html). - -See a more detailed description of these steps in the [reference](#aws-rdsaurora-postgresql) below. - -### Step 2/3. Setup Teleport - -Teleport Database Access is available starting from `6.0.0-alpha.1` pre-release. - -Download the appropriate version of Teleport for your platform from the table -below, or visit our [downloads page](https://goteleport.com/teleport/download). - -{!docs/pages/preview/releases-table.mdx!} - - -Note, pre-releases are not suitable for production usage! - - -Start Teleport using the following command and point it to your Aurora database -instance. Make sure to update the database endpoint and region appropriately. - -```shell -sudo teleport start \ - --roles=proxy,auth,db \ - --db-name=aurora \ - --db-protocol=postgres \ - --db-uri=postgres-aurora-instance-1.abcdefghijklm.us-west-1.rds.amazonaws.com:5432 \ - --db-aws-region=us-west-1 -``` - - -The node where the Teleport process is started should have AWS credentials -configured with the policy from [step 1](#step-13-setup-aurora). - - -Create a Teleport user that is allowed to connect to a particular database -(e.g. `postgres`) within the Aurora instance as a particular database account -(e.g. `alice`). - -```shell -sudo tctl users add alice root \ - --db-names=postgres \ - --db-users=alice -``` - -### Step 3/3. Connect to Database - -Now that Aurora is configured with IAM authentication, Teleport is running and -the local user is created, we're ready to connect to the database. - -Log into Teleport with the user we've just created. Make sure to use `tsh` -version `6.0.0-alpha.2` or newer that includes Database Access support. - -For simplicity, we're using an `--insecure` flag to accept Teleport's -self-signed certificate. For production usage make sure to configure proxy -with a proper certificate/key pair. See Teleport's general -[quickstart guide](../quickstart.mdx#step-1c-configure-domain-name-and-obtain-tls-certificates-using-lets-encrypt). - -```shell -tsh login --insecure --proxy=localhost:3080 --user=alice -``` - -Now we can inspect available databases and retrieve credentials for the -configured Aurora instance: - -```shell -tsh db ls -tsh db login aurora -``` - -Finally, connect to the database using `psql` command shown in the output of -`tsh db login` command, which may look like this: - -```shell -psql "service=-aurora user=alice dbname=postgres" -``` - -### Next Steps - -Congratulations on completing the Teleport Database Access getting started -guide! - -For the next steps, dive deeper into the topics relevant to your Database -Access use-case, for example: - -* Learn how to connect to a [self-hosted database](#self-hosted-postgresql). -* Learn how to configure Database Access via Teleport [configuration file](#configure-teleport). -* Learn about Database Access [RBAC](#rbac). -* See [frequently asked questions](#faq). - -## Diagram - -The following diagram shows an example Database Access setup: - -* Root cluster provides access to an onprem instance of PostgreSQL. -* Leaf cluster, connected to the root cluster, provides access to an - onprem instance of MySQL and PostgreSQL-compatible AWS Aurora. -* Node connects another on-premise PostgreSQL instance (perhaps, a - metrics database) via tunnel to the root cluster. - -![Teleport database access diagram](../../img/dbaccess.svg) - -## Release Schedule - -Teleport Database Access is under active development and is available starting -from `6.0.0-alpha.1` release. The alpha version includes support for self-hosted -PostgreSQL as well as PostgreSQL compatible AWS RDS and Aurora. - -See [release schedule](./upcoming-releases.mdx#release-schedule). - -## Configure PostgreSQL - -### Self-Hosted PostgreSQL - - -This section explains how to configure a self-hosted instance of PostgreSQL -to work with Teleport Database Access. For information about configuring -AWS RDS/Aurora see the [section below](#aws-rdsaurora-postgresql). - - -#### Create Certificate/Key Pair - -Teleport uses mutual TLS for authentication to PostgreSQL instances. As such, -self-hosted PostgreSQL instances must be configured with Teleport's certificate -authority and a certificate/key pair that Teleport can validate. - -To create these secrets, use `tctl auth sign` command. Note that it requires a -running Teleport cluster and [should be run](https://goteleport.com/teleport/docs/architecture/overview/#tctl) -on the auth server. - -```sh -# Export Teleport's certificate authority and generate certificate/key pair -# for host db.example.com with a one year validity period. -$ tctl auth sign --format=db --host=db.example.com --out=server --ttl=8760h -``` - -Flag descriptions: - -* `--format=db`: instructs the command to produce secrets in the format suitable - for configuring a database server. -* `--host=db.example.com`: server name to encode in the certificate, should - match the hostname Teleport will be connecting to the database at. -* `--out=server`: name prefix for output files. -* `--ttl=8760h`: certificate validity period. - -The command will create 3 files: `server.cas` with Teleport's certificate -authority and `server.crt`/`server.key` with generated certificate/key pair. - - -Teleport signs database certificates with the host authority. As such, -when performing [host certificates rotation](../admin-guide.mdx#certificate-rotation), -the database certificates must be updated as well. - - -#### Configure PostgreSQL Server - -To configure PostgreSQL server to accept TLS connections, add the following -to PostgreSQL configuration file `postgresql.conf`: - -```conf -ssl = on -ssl_cert_file = '/path/to/server.crt' -ssl_key_file = '/path/to/server.key' -ssl_ca_file = '/path/toa/server.cas' -``` - -See [Secure TCP/IP Connections with SSL](https://www.postgresql.org/docs/current/ssl-tcp.html) -in PostgreSQL documentation for more details. - -Additionally, PostgreSQL should be configured to require client certificate -authentication from clients connecting over TLS. This can be done by adding -the following entries to PostgreSQL host-based authentication file `pg_hba.conf`: - -```conf -hostssl all all ::/0 cert -hostssl all all 0.0.0.0/0 cert -``` - -See [The pg_hba.conf File](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html) -in PostgreSQL documentation for more details. - -### AWS RDS/Aurora PostgreSQL - - -This section explains how to configure a PostgreSQL-flavored instance of -AWS RDS or Aurora database to work with Teleport Database Access. For -information about configuring a self-hosted PostgreSQL see the [section above](#self-hosted-postgresql). - - -Teleport Database Access for AWS RDS and Aurora uses IAM authentication which -can be enabled with the following steps. - -#### Enable IAM Authentication - -Open [Amazon RDS console](https://console.aws.amazon.com/rds/) and create a new -database instance with IAM authentication enabled, or modify an existing one to -turn it on. Make sure to use PostgreSQL database type. - -See [Enabling and disabling IAM database authentication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Enabling.html) -for more information. - -#### Create IAM Policy - -To allow Teleport database service to log into the database instance using auth -token, create an IAM policy and attach it to the user whose credentials the -database service will be using, for example: - -```json -{ - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": [ - "rds-db:connect" - ], - "Resource": [ - "arn:aws:rds-db:us-east-2:1234567890:dbuser:cluster-ABCDEFGHIJKL01234/*" - ] - } - ] -} -``` - -The resource ARN in the policy has the following format: - -``` -arn:aws:rds-db:::dbuser:/ -``` - -Parameters: - -* `region`: AWS region where the database cluster is deployed. -* `account-id`: AWS account ID the database cluster is deployed under. -* `db-cluster-resource-id`: identifier for the database cluster, can be found - under Configuration section in the RDS control panel. -* `db-user-name`: name of the database account to associate with IAM - authentication. Can be a wildcard. - -See [Creating and using an IAM policy for IAM database access](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) -for more information. - -#### Create Database User - -Database users must have a `rds_iam` role in order to be allowed access. For -PostgreSQL: - -```sql -CREATE USER alice; -GRANT rds_iam TO alice; -``` - -See [Creating a database account using IAM authentication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.DBAccounts.html) -for more information. - -## Configure Teleport - -Teleport Database Access is available starting from `6.0.0-alpha.1` pre-release. - -Download the appropriate version of Teleport for your platform from the table -below, or visit our [downloads page](https://goteleport.com/teleport/download). - -{!docs/pages/preview/releases-table.mdx!} - - -Note, pre-releases are not suitable for production usage! - - -Follow the installation [instructions](../installation.mdx). - -### Start Auth/Proxy Service - -Create a configuration file for a Teleport service that will be running -auth and proxy servers: - -```yaml -teleport: - data_dir: /var/lib/teleport - nodename: test -auth_service: - enabled: "yes" - cluster_name: "test" - listen_addr: 0.0.0.0:3025 - tokens: - - proxy,node,database:cbdeeab9-6f88-436d-a673-44d14bd86bb7 -proxy_service: - enabled: "yes" - listen_addr: 0.0.0.0:3023 - web_listen_addr: 0.0.0.0:3080 - tunnel_listen_addr: 0.0.0.0:3024 - public_addr: teleport.example.com:3080 -ssh_service: - enabled: "no" -``` - -Start the service: - -```sh -$ teleport start --debug --config=/path/to/teleport.yaml -``` - -### Start Database Service with CLI Flags - -For a quick try-out, Teleport database service doesn't require a configuration -file and can be launched using a single CLI command: - -```sh -$ teleport start --debug \ - --roles=db \ - --token=cbdeeab9-6f88-436d-a673-44d14bd86bb7 \ - --auth-server=teleport.example.com:3080 \ - --db-name=test \ - --db-protocol=postgres \ - --db-uri=db.example.com:5432 \ - --labels=env=test -``` - -Note that the `--auth-server` flag must point to cluster's proxy endpoint -because database service always connects back to the cluster over a reverse -tunnel. - -Instead of using a static auth token, a short-lived dynamic token can also -be generated for a database service: - -```sh -$ tctl tokens add \ - --type=db \ - --db-name=test \ - --db-protocol=postgres \ - --db-uri=db.example.com:5432 -``` - -### Start Database Service with Config File - -Below is an example of a database service configuration file that proxies -a single AWS Aurora database: - -```yaml -teleport: - data_dir: /var/lib/teleport-db - nodename: test - # Auth token to connect to the auth server. - auth_token: cbdeeab9-6f88-436d-a673-44d14bd86bb7 - # Proxy address to connect to. Note that it has to be the proxy address - # because database service always connects to the cluster over reverse - # tunnel. - auth_servers: - - teleport.example.com:3080 -db_service: - enabled: "yes" - # This section contains definitions of all databases proxied by this - # service, can contain multiple items. - databases: - # Name of the database proxy instance, used to reference in CLI. - - name: "aurora" - # Free-form description of the database proxy instance. - description: "AWS Aurora instance of PostgreSQL 13.0" - # Database protocol. - protocol: "postgres" - # Database address, example of a AWS Aurora endpoint in this case. - uri: "postgres-aurora-instance-1.xxx.us-east-1.rds.amazonaws.com:5432" - # AWS specific configuration, only required for RDS and Aurora. - aws: - # Region the database is deployed in. - region: us-east-1 - # Labels to assign to the database, used in RBAC. - labels: - env: dev -auth_service: - enabled: "no" -ssh_service: - enabled: "no" -proxy_service: - enabled: "no" -``` - - -A single Teleport process can run multiple different services, for example -multiple database access proxies as well as running other services such an -SSH service or an application access proxy. - - -Start the database service: - -```sh -$ teleport start --debug --config=/path/to/teleport-db.yaml -``` - -### AWS Credentials - -When setting up Teleport database service with AWS RDS or Aurora, it must have -an IAM role allowing it to connect to that particular database instance. An -example of such a policy is shown in the [AWS RDS/Aurora](#aws-rdsaurora-postgresql) -section above. See [Creating and using an IAM policy for IAM database access](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) -in AWS documentation. - -Teleport database service uses the default credential provider chain to find AWS -credentials. See [Specifying Credentials](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials) -for more information. - -## Connect - -Once the database service has joined the cluster, login to see the available -databases: - -```sh -$ tsh login --proxy=teleport.example.com:3080 -$ tsh db ls -Name Description Labels ------- ----------- -------- -aurora AWS Aurora env=dev -``` - -Note that you will only be able to see databases your role has access to. See -[RBAC](#rbac) section for more details. - -To connect to a particular database server, first retrieve credentials from -Teleport using `tsh db login` command: - -```sh -$ tsh db login aurora -``` - - -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: - -```sh -$ tsh db login --db-user=postgres --db-name=postgres aurora -``` - -When logging into a PostgreSQL database, `tsh` automatically configures a section -in the [connection service file](https://www.postgresql.org/docs/current/libpq-pgservice.html) -with the name of `-`. - -Suppose the cluster name is "root", then you can connect to the database using -the following `psql` command: - -```sh -# Use default database user/name. -$ psql "service=root-aurora" -# Specify database name/user explicitly. -$ psql "service=root-aurora user=alice dbname=metrics" -``` - -To log out of the database and remove credentials: - -```sh -# Log out of a particular database instance. -$ tsh db logout aurora -# Log out of all database instances. -$ tsh db logout -``` - -## RBAC - -Teleport's "role" resource provides the following instruments for restricting -database access: - -```yaml -kind: role -version: v3 -metadata: - name: developer -spec: - allow: - # Label selectors for database instances this role has access to. These - # will be matched against the static/dynamic labels set on the database - # service. - db_labels: - environment: ["dev", "stage"] - # Database names this role will be able to connect to. Note: this is not - # the same as the "name" field in "db_service", this is the database names - # within a particular database instance. - db_names: ["main", "metrics", "postgres"] - # Database users this role can connect as. - db_users: ["alice", "bob"] -``` - -It is possible to use wildcards to match any database names/users. For example, -the following role permits access to any database/user within a production -database except for the internal "postgres" database/user: - -```yaml -kind: role -version: v3 -metadata: - name: developer -spec: - allow: - db_labels: - environment: ["dev", "prod"] - db_names: ["*"] - db_users: ["*"] - deny: - db_labels: - environment: ["dev", "prod"] - db_names: ["postgres"] - db_users: ["postgres"] -``` - -Similar to other role fields, these support templating variables to allow -propagating information from identity providers: - -```yaml -spec: - allow: - db_names: ["{% raw %}{{internal.db_names}}{% endraw %}", "{% raw %}{{external.xxx}}{% endraw %}"] - db_users: ["{% raw %}{{internal.db_users}}{% endraw %}", "{% raw %}{{external.yyy}}{% endraw %}"] -``` - -See general [RBAC](../enterprise/ssh-rbac.mdx) documentation for more details. - -## FAQ - -### Which database protocols does Teleport Database Access support? - -Currently Teleport Database Access Preview supports only PostgreSQL. - -MySQL support is planned for [Teleport 6.0 release](./upcoming-releases.mdx#release-schedule), -with other databases to follow over the course of 2021 and beyond. - -### Which PostgreSQL protocol features are not supported? - -The following PostgreSQL protocol features aren't currently supported: - -* [Canceling requests in progress](https://www.postgresql.org/docs/current/protocol-flow.html#id-1.10.5.7.9). - Cancel requests issued by the PostgreSQL clients connected to Teleport proxy - won't be passed to the database server. -* Any of the [authentication methods](https://www.postgresql.org/docs/current/auth-methods.html) - except for client certificate authentication. - -## RFD - -Please refer to the [RFD document](https://github.com/gravitational/teleport/blob/024fd582e62560ffc925cd4b4d42c156043c041b/rfd/0011-database-access.md) -for a more in-depth description of the feature scope and design. - -## Feedback - -We value your feedback. Please schedule a Zoom call with us to get in-depth -demo and give us feedback using [this](https://calendly.com/benarent/teleport-database-access?month=2020-11) -link. - -If you found a bug, please create a [Github -Issue](https://github.com/gravitational/teleport/issues/new/choose). diff --git a/docs/pages/preview/releases-table.mdx b/docs/pages/preview/releases-table.mdx index 05ebcbd95996f..389062d052960 100644 --- a/docs/pages/preview/releases-table.mdx +++ b/docs/pages/preview/releases-table.mdx @@ -2,25 +2,25 @@ | OPERATING SYSTEM | CHECKSUM | DOWNLOAD LINK | |-|-|-| -| Linux 32-bit | [SHA256](https://get.gravitational.com/teleport-v6.0.0-alpha.2-linux-386-bin.tar.gz.sha256) | [teleport-v6.0.0-alpha.2-linux-386-bin.tar.gz](https://get.gravitational.com/teleport-v6.0.0-alpha.2-linux-386-bin.tar.gz) | -| Linux 64-bit | [SHA256](https://get.gravitational.com/teleport-v6.0.0-alpha.2-linux-amd64-bin.tar.gz.sha256) | [teleport-v6.0.0-alpha.2-linux-amd64-bin.tar.gz](https://get.gravitational.com/teleport-v6.0.0-alpha.2-linux-amd64-bin.tar.gz) | -| Linux 64-bit (RHEL/CentOS 6.x compatible) | [SHA256](https://get.gravitational.com/teleport-v6.0.0-alpha.2-linux-amd64-centos6-bin.tar.gz.sha256) | [teleport-v6.0.0-alpha.2-linux-amd64-centos6-bin.tar.gz](https://get.gravitational.com/teleport-v6.0.0-alpha.2-linux-amd64-centos6-bin.tar.gz) | -| Linux ARMv7 | [SHA256](https://get.gravitational.com/teleport-v6.0.0-alpha.2-linux-arm-bin.tar.gz.sha256) | [teleport-v6.0.0-alpha.2-linux-arm-bin.tar.gz](https://get.gravitational.com/teleport-v6.0.0-alpha.2-linux-arm-bin.tar.gz) | -| Linux 64-bit DEB | [SHA256](https://get.gravitational.com/teleport_6.0.0-alpha.2_amd64.deb.sha256) | [teleport_v6.0.0-alpha.2_amd64.deb](https://get.gravitational.com/teleport_6.0.0-alpha.2_amd64.deb) | -| Linux 32-bit DEB | [SHA256](https://get.gravitational.com/teleport_6.0.0-alpha.2_i386.deb.sha256) | [teleport_v6.0.0-alpha.2_i386.deb](https://get.gravitational.com/teleport_6.0.0-alpha.2_amd64.deb) | -| Linux 64-bit RPM | [SHA256](https://get.gravitational.com/teleport-6.0.0-alpha.2-1.x86_64.rpm.sha256) | [teleport-6.0.0-alpha.2-1.x86_64.rpm](https://get.gravitational.com/teleport-6.0.0-alpha.2-1.x86_64.rpm) -| Docker Image | [SHA256](https://quay.io/repository/gravitational/teleport?tab=tags) | `docker pull quay.io/gravitational/teleport:6.0.0-alpha.2` | +| Linux 32-bit | [SHA256](https://get.gravitational.com/teleport-v6.0.0-rc.1-linux-386-bin.tar.gz.sha256) | [teleport-v6.0.0-rc.1-linux-386-bin.tar.gz](https://get.gravitational.com/teleport-v6.0.0-rc.1-linux-386-bin.tar.gz) | +| Linux 64-bit | [SHA256](https://get.gravitational.com/teleport-v6.0.0-rc.1-linux-amd64-bin.tar.gz.sha256) | [teleport-v6.0.0-rc.1-linux-amd64-bin.tar.gz](https://get.gravitational.com/teleport-v6.0.0-rc.1-linux-amd64-bin.tar.gz) | +| Linux 64-bit (RHEL/CentOS 6.x compatible) | [SHA256](https://get.gravitational.com/teleport-v6.0.0-rc.1-linux-amd64-centos6-bin.tar.gz.sha256) | [teleport-v6.0.0-rc.1-linux-amd64-centos6-bin.tar.gz](https://get.gravitational.com/teleport-v6.0.0-rc.1-linux-amd64-centos6-bin.tar.gz) | +| Linux ARMv7 | [SHA256](https://get.gravitational.com/teleport-v6.0.0-rc.1-linux-arm-bin.tar.gz.sha256) | [teleport-v6.0.0-rc.1-linux-arm-bin.tar.gz](https://get.gravitational.com/teleport-v6.0.0-rc.1-linux-arm-bin.tar.gz) | +| Linux 64-bit DEB | [SHA256](https://get.gravitational.com/teleport_6.0.0-rc.1_amd64.deb.sha256) | [teleport_v6.0.0-rc.1_amd64.deb](https://get.gravitational.com/teleport_6.0.0-rc.1_amd64.deb) | +| Linux 32-bit DEB | [SHA256](https://get.gravitational.com/teleport_6.0.0-rc.1_i386.deb.sha256) | [teleport_v6.0.0-rc.1_i386.deb](https://get.gravitational.com/teleport_6.0.0-rc.1_amd64.deb) | +| Linux 64-bit RPM | [SHA256](https://get.gravitational.com/teleport-6.0.0-rc.1-1.x86_64.rpm.sha256) | [teleport-6.0.0-rc.1-1.x86_64.rpm](https://get.gravitational.com/teleport-6.0.0-rc.1-1.x86_64.rpm) +| Docker Image | [SHA256](https://quay.io/repository/gravitational/teleport?tab=tags) | `docker pull quay.io/gravitational/teleport:6.0.0-rc.1` | | OPERATING SYSTEM | CHECKSUM | DOWNLOAD LINK | |-|-|-| -| Linux 32-bit | [SHA256](https://get.gravitational.com/teleport-ent-v6.0.0-alpha.2-linux-386-bin.tar.gz.sha256) | [teleport-ent-v6.0.0-alpha.2-linux-386-bin.tar.gz](https://get.gravitational.com/teleport-ent-v6.0.0-alpha.2-linux-386-bin.tar.gz) | -| Linux 64-bit | [SHA256](https://get.gravitational.com/teleport-ent-v6.0.0-alpha.2-linux-amd64-bin.tar.gz.sha256) | [teleport-ent-v6.0.0-alpha.2-linux-amd64-bin.tar.gz](https://get.gravitational.com/teleport-ent-v6.0.0-alpha.2-linux-amd64-bin.tar.gz) | -| Linux 64-bit (RHEL/CentOS 6.x compatible) | [SHA256](https://get.gravitational.com/teleport-ent-v6.0.0-alpha.2-linux-amd64-centos6-bin.tar.gz.sha256) | [teleport-ent-v6.0.0-alpha.2-linux-amd64-centos6-bin.tar.gz](https://get.gravitational.com/teleport-ent-v6.0.0-alpha.2-linux-amd64-centos6-bin.tar.gz) | -| Linux ARMv7 | [SHA256](https://get.gravitational.com/teleport-ent-v6.0.0-alpha.2-linux-arm-bin.tar.gz.sha256) | [teleport-ent-v6.0.0-alpha.2-linux-arm-bin.tar.gz](https://get.gravitational.com/teleport-ent-v6.0.0-alpha.2-linux-arm-bin.tar.gz) | -| Linux 64-bit DEB | [SHA256](https://get.gravitational.com/teleport-ent_6.0.0-alpha.2_amd64.deb.sha256) | [teleport-ent_v6.0.0-alpha.2_amd64.deb](https://get.gravitational.com/teleport-ent_6.0.0-alpha.2_amd64.deb) | -| Linux 32-bit DEB | [SHA256](https://get.gravitational.com/teleport-ent_6.0.0-alpha.2_i386.deb.sha256) | [teleport-ent_v6.0.0-alpha.2_i386.deb](https://get.gravitational.com/teleport-ent_6.0.0-alpha.2_i386.deb) | -| Linux 64-bit RPM | [SHA256](https://get.gravitational.com/teleport-ent-6.0.0-alpha.2-1.x86_64.rpm.sha256) | [teleport-ent-6.0.0-alpha.2-1.x86_64.rpm](https://get.gravitational.com/teleport-ent-6.0.0-alpha.2-1.x86_64.rpm) -| Docker Image | [SHA256](https://quay.io/repository/gravitational/teleport-ent?tab=tags) | `docker pull quay.io/gravitational/teleport-ent:6.0.0-alpha.2` | +| Linux 32-bit | [SHA256](https://get.gravitational.com/teleport-ent-v6.0.0-rc.1-linux-386-bin.tar.gz.sha256) | [teleport-ent-v6.0.0-rc.1-linux-386-bin.tar.gz](https://get.gravitational.com/teleport-ent-v6.0.0-rc.1-linux-386-bin.tar.gz) | +| Linux 64-bit | [SHA256](https://get.gravitational.com/teleport-ent-v6.0.0-rc.1-linux-amd64-bin.tar.gz.sha256) | [teleport-ent-v6.0.0-rc.1-linux-amd64-bin.tar.gz](https://get.gravitational.com/teleport-ent-v6.0.0-rc.1-linux-amd64-bin.tar.gz) | +| Linux 64-bit (RHEL/CentOS 6.x compatible) | [SHA256](https://get.gravitational.com/teleport-ent-v6.0.0-rc.1-linux-amd64-centos6-bin.tar.gz.sha256) | [teleport-ent-v6.0.0-rc.1-linux-amd64-centos6-bin.tar.gz](https://get.gravitational.com/teleport-ent-v6.0.0-rc.1-linux-amd64-centos6-bin.tar.gz) | +| Linux ARMv7 | [SHA256](https://get.gravitational.com/teleport-ent-v6.0.0-rc.1-linux-arm-bin.tar.gz.sha256) | [teleport-ent-v6.0.0-rc.1-linux-arm-bin.tar.gz](https://get.gravitational.com/teleport-ent-v6.0.0-rc.1-linux-arm-bin.tar.gz) | +| Linux 64-bit DEB | [SHA256](https://get.gravitational.com/teleport-ent_6.0.0-rc.1_amd64.deb.sha256) | [teleport-ent_v6.0.0-rc.1_amd64.deb](https://get.gravitational.com/teleport-ent_6.0.0-rc.1_amd64.deb) | +| Linux 32-bit DEB | [SHA256](https://get.gravitational.com/teleport-ent_6.0.0-rc.1_i386.deb.sha256) | [teleport-ent_v6.0.0-rc.1_i386.deb](https://get.gravitational.com/teleport-ent_6.0.0-rc.1_i386.deb) | +| Linux 64-bit RPM | [SHA256](https://get.gravitational.com/teleport-ent-6.0.0-rc.1-1.x86_64.rpm.sha256) | [teleport-ent-6.0.0-rc.1-1.x86_64.rpm](https://get.gravitational.com/teleport-ent-6.0.0-rc.1-1.x86_64.rpm) +| Docker Image | [SHA256](https://quay.io/repository/gravitational/teleport-ent?tab=tags) | `docker pull quay.io/gravitational/teleport-ent:6.0.0-rc.1` |