From 1fcb3d7c000fd804a4985755ef0e83e012eae701 Mon Sep 17 00:00:00 2001 From: Roman Tkachenko Date: Wed, 24 May 2023 12:05:32 -0700 Subject: [PATCH 1/6] Add docs for database auto user provisioning --- docs/config.json | 12 +- .../guides/postgres-self-hosted.mdx | 4 + docs/pages/database-access/guides/rds.mdx | 1 + docs/pages/database-access/rbac.mdx | 132 +------------- .../rbac/configuring-access.mdx | 135 ++++++++++++++ .../configuring-auto-user-provisioning.mdx | 166 ++++++++++++++++++ .../reference/configuration.mdx | 5 + docs/pages/includes/role-spec.mdx | 5 +- 8 files changed, 328 insertions(+), 132 deletions(-) create mode 100644 docs/pages/database-access/rbac/configuring-access.mdx create mode 100644 docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx diff --git a/docs/config.json b/docs/config.json index 7384680bcd7a7..8aeb8eb35fbce 100644 --- a/docs/config.json +++ b/docs/config.json @@ -1280,7 +1280,17 @@ }, { "title": "Access Controls", - "slug": "/database-access/rbac/" + "slug": "/database-access/rbac/", + "entries": [ + { + "title": "Configuring Access", + "slug": "/database-access/rbac/configuring-access/" + }, + { + "title": "Automatic User Provisioning (Preview)", + "slug": "/database-access/rbac/configuring-auto-user-provisioning/" + } + ] }, { "title": "Architecture", diff --git a/docs/pages/database-access/guides/postgres-self-hosted.mdx b/docs/pages/database-access/guides/postgres-self-hosted.mdx index f6572dd3d1577..d9b0b826a083c 100644 --- a/docs/pages/database-access/guides/postgres-self-hosted.mdx +++ b/docs/pages/database-access/guides/postgres-self-hosted.mdx @@ -157,3 +157,7 @@ $ tsh db logout example-postgres # Remove credentials for all database instances. $ tsh db logout ``` + +## Next steps + +- Set up [automatic database user provisioning](../rbac/configuring-auto-user-provisioning.mdx). diff --git a/docs/pages/database-access/guides/rds.mdx b/docs/pages/database-access/guides/rds.mdx index ce65405fcc1fd..f98d1ded9bce7 100644 --- a/docs/pages/database-access/guides/rds.mdx +++ b/docs/pages/database-access/guides/rds.mdx @@ -215,3 +215,4 @@ $ tsh db logout postgres-rds ## Next steps (!docs/pages/includes/database-access/guides-next-steps.mdx!) +- Set up [automatic database user provisioning](../rbac/configuring-auto-user-provisioning.mdx). diff --git a/docs/pages/database-access/rbac.mdx b/docs/pages/database-access/rbac.mdx index 28c5237d85342..f138709bbe250 100644 --- a/docs/pages/database-access/rbac.mdx +++ b/docs/pages/database-access/rbac.mdx @@ -3,133 +3,5 @@ title: Database Role-Based Access Controls description: Role-based access control (RBAC) for Teleport database access. --- -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](../access-controls/introduction.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: v5 -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: v5 -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](../access-controls/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: ["{{external.databases}}"] -``` - -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: ["{{internal.db_users}}"] - db_names: ["{{internal.db_names}}"] -``` +- [Configuring Access](./rbac/configuring-access.mdx) +- [Configuring Automatic User Provisioning](./rbac/configuring-auto-user-provisioning.mdx) diff --git a/docs/pages/database-access/rbac/configuring-access.mdx b/docs/pages/database-access/rbac/configuring-access.mdx new file mode 100644 index 0000000000000..28c5237d85342 --- /dev/null +++ b/docs/pages/database-access/rbac/configuring-access.mdx @@ -0,0 +1,135 @@ +--- +title: Database Role-Based Access Controls +description: Role-based access control (RBAC) for Teleport database access. +--- + +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](../access-controls/introduction.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: v5 +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: v5 +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](../access-controls/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: ["{{external.databases}}"] +``` + +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: ["{{internal.db_users}}"] + db_names: ["{{internal.db_names}}"] +``` diff --git a/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx b/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx new file mode 100644 index 0000000000000..6d19004b9ae3e --- /dev/null +++ b/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx @@ -0,0 +1,166 @@ +--- +title: Database Automatic User Provisioning (Preview) +description: Configure automatic user provisioning for Database Access. +--- + +
+ Automatic user provisioning for Database Access is available starting from + Teleport 13.1. +
+ +Teleport can automatically create users in your database, removing the need for +having to create each individual user account in advance, or using the same set +of shared database accounts for all users. + + +Currently, automatic user provisioning is only supported for self-hosted and +RDS PostgreSQL databases. + + +## Prerequisites + +- Teleport cluster with a configured [self-hosted](../guides/postgres-self-hosted.mdx) + or [RDS](../guides/rds.mdx) PostgreSQL database. +- Ability to connect to and create user accounts in the target database. + +## Step 1/3. Configure database admin + +Teleport should be able to connect to the database as a user that can create +other users and assign them roles. We recommend creating a separate user +designated specifically for Teleport automatic user provisioning. Let's call it +`teleport-admin`. + +Teleport will use the same authentication mechanism when connecting as an admin +user as for regular user connections: X.509 for self-hosted databases and AWS +IAM for RDS. The admin user must have privileges within the database to create +users and grant them privileges. + + + +RDS PostgreSQL admin user must have `rds_iam` role attached to allow IAM +authentication as described in the [RDS guide](../guides/rds.mdx#step-56-create-a-database-iam-user). +```sql +CREATE USER "teleport-admin" login createrole; +GRANT rds_iam TO "teleport-admin"; +``` + + +Self-hosted PostgreSQL admin user must have X.509 authentication configured as +described in the [self-hosted guide](../guides/postgres-self-hosted.mdx#step-35-configure-your-postgresql-server). +```sql +CREATE USER "teleport-admin" login createrole; +``` + + + +Users created by Teleport will be placed in the `teleport-auto-users` group in +the database, which will be created automatically if it doesn't exist. + +Teleport will not delete the automatically created user at the end of the session. +Instead, the user will be stripped of all roles, updated with `nologin` trait +and reactivated during the next connection. + +Next, enable the database admin on the Teleport database configuration: + + + +```yaml +db_service: + enabled: "yes" + databases: + - name: "example" + protocol: "postgres" + uri: "localhost:5432" + admin_user: + name: "teleport-admin" +``` + + +```yaml +kind: db +version: v3 +metadata: + name: example +spec: + protocol: "postgres" + uri: "localhost:5432" + admin_user: + name: "teleport-admin" +``` + + + + +For auto-discovered cloud databases, the name of the admin user is taken from +the `teleport.dev/db-admin` label. + + +## Step 2/3. Configure Teleport role + +To specify the database roles a user should be assigned within the database, +use `db_roles` role option: + +```yaml +kind: role +version: v6 +metadata: + name: auto-db-users +spec: + options: + # create_db_user enables automatic user provisioning for matching databases + create_db_user: true + allow: + db_labels: + "*": "*" + db_names: + - "*" + # db_roles is a list of roles the database user will be assigned + db_roles: + - reader + - "{{internal.db_roles}}" + - "{{external.db_roles}}" +``` + +With automatic user provisioning, users always connect to the database with +their Teleport username so the `db_users` role field is ignored for roles +that have database user provisioning enabled. + +The `db_roles` role option supports all the same [interpolation rules](../../access-controls/guides/role-templates.mdx#interpolation-rules) +as other role fields. + +User created within the database will: + +- Have the same name as Teleport username. +- Be a part of the `teleport-auto-users` role. +- Assigned all roles from the Teleport user's roleset that match the database. + The role names must be valid and exist in the database. See PostgreSQL + [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) + documentation for details. + +Note that in case of the name conflict where the user with the same name already +exists in the database and is not managed by Teleport (i.e. not a part of the +`teleport-auto-users` group), the connection will be aborted. + +## Step 3/3. Connect to the database + +Now, log into your Teleport cluster and connect to the database: + +``` +$ tsh login --proxy=teleport.example.com +$ tsh db connect example +``` + +If using a [GUI database client](../../connect-your-client/gui-clients.mdx) like +pgAdmin, make sure to use your Teleport username as a database username. +`tsh db connect` will default to it automatically when connecting to a database +with user provisioning enabled. + +## Next steps + +- Read automatic user provisioning [RFD](https://github.com/gravitational/teleport/blob/master/rfd/0113-automatic-database-users.md). diff --git a/docs/pages/database-access/reference/configuration.mdx b/docs/pages/database-access/reference/configuration.mdx index c9e644c8a5498..9d144c7ed9728 100644 --- a/docs/pages/database-access/reference/configuration.mdx +++ b/docs/pages/database-access/reference/configuration.mdx @@ -116,6 +116,11 @@ spec: ... -----END CERTIFICATE----- + # Database admin user for automatic user provisioning. + admin_user: + # Database admin user name. + name: "teleport-admin" + # MySQL only options. mysql: # The MySQL server version reported by the Teleport Proxy Service. diff --git a/docs/pages/includes/role-spec.mdx b/docs/pages/includes/role-spec.mdx index 5cff6f23e7a6f..3ecdb82b34931 100644 --- a/docs/pages/includes/role-spec.mdx +++ b/docs/pages/includes/role-spec.mdx @@ -97,8 +97,10 @@ spec: mode: extension name: login@github.com value: "{{ external.github_login }}" - # Controls whether this role supports auto provisioning of users. + # Controls whether this role supports auto provisioning of SSH users. create_host_user: true + # Controls whether this role requires automatic database user provisioning. + create_db_user: true # Specifies role specific options for identity provider access. idp: # Specifies role specific options for SAML identity provider access. @@ -171,6 +173,7 @@ spec: # Functions transform variables. db_users: ['{{email.local(external.email)}}'] db_names: ['{{external.db_names}}'] + db_roles: ['{{external.db_roles}}'] db_labels: 'env': '{{regexp.replace(external.access["env"], "^(staging)$", "$1")}}' From b281b54670036f8b65ef61d731af43457cc5feb8 Mon Sep 17 00:00:00 2001 From: Roman Tkachenko Date: Wed, 31 May 2023 11:44:58 -0700 Subject: [PATCH 2/6] Address feedback --- docs/config.json | 2 +- docs/cspell.json | 7 ++- docs/pages/database-access/rbac.mdx | 10 +++- .../configuring-auto-user-provisioning.mdx | 47 ++++++++++++------- 4 files changed, 45 insertions(+), 21 deletions(-) diff --git a/docs/config.json b/docs/config.json index 8aeb8eb35fbce..575d5d1496a27 100644 --- a/docs/config.json +++ b/docs/config.json @@ -1283,7 +1283,7 @@ "slug": "/database-access/rbac/", "entries": [ { - "title": "Configuring Access", + "title": "RBAC", "slug": "/database-access/rbac/configuring-access/" }, { diff --git a/docs/cspell.json b/docs/cspell.json index 52e12a84f02c7..8ad3564be15e6 100644 --- a/docs/cspell.json +++ b/docs/cspell.json @@ -297,6 +297,7 @@ "cqlsh", "createkey", "createnongalleryapp", + "createrole", "creds", "crond", "customizability", @@ -752,5 +753,7 @@ "znmqk", "zxvf" ], - "flagWords": ["hte"] -} + "flagWords": [ + "hte" + ] +} \ No newline at end of file diff --git a/docs/pages/database-access/rbac.mdx b/docs/pages/database-access/rbac.mdx index f138709bbe250..6efd81371b4a9 100644 --- a/docs/pages/database-access/rbac.mdx +++ b/docs/pages/database-access/rbac.mdx @@ -3,5 +3,11 @@ title: Database Role-Based Access Controls description: Role-based access control (RBAC) for Teleport database access. --- -- [Configuring Access](./rbac/configuring-access.mdx) -- [Configuring Automatic User Provisioning](./rbac/configuring-auto-user-provisioning.mdx) +These guides cover configuring access control policies for database users. + +Read the [RBAC](./rbac/configuring-access.mdx) guide to get a general understanding +of how to configure Teleport roles to grant or deny access to your database users. + +The [Automatic User Provisioning](./rbac/configuring-auto-user-provisioning.mdx) +guide explains how to get Teleport to create accounts for your PostgreSQL users +on-demand. diff --git a/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx b/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx index 6d19004b9ae3e..a752d39ed96d2 100644 --- a/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx +++ b/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx @@ -25,8 +25,8 @@ RDS PostgreSQL databases. ## Prerequisites -- Teleport cluster with a configured [self-hosted](../guides/postgres-self-hosted.mdx) - or [RDS](../guides/rds.mdx) PostgreSQL database. +- Teleport cluster with a configured [self-hosted PostgreSQL](../guides/postgres-self-hosted.mdx) + or [RDS PostgreSQL](../guides/rds.mdx) database. - Ability to connect to and create user accounts in the target database. ## Step 1/3. Configure database admin @@ -44,18 +44,35 @@ users and grant them privileges. RDS PostgreSQL admin user must have `rds_iam` role attached to allow IAM -authentication as described in the [RDS guide](../guides/rds.mdx#step-56-create-a-database-iam-user). +authentication. + ```sql CREATE USER "teleport-admin" login createrole; GRANT rds_iam TO "teleport-admin"; ``` + +Note that the RDS database must have IAM authentication enabled. + +Refer to the [RDS guide](../guides/rds.mdx#step-56-create-a-database-iam-user) +for more information. -Self-hosted PostgreSQL admin user must have X.509 authentication configured as -described in the [self-hosted guide](../guides/postgres-self-hosted.mdx#step-35-configure-your-postgresql-server). +Self-hosted PostgreSQL admin user must have X.509 authentication configured. + ```sql CREATE USER "teleport-admin" login createrole; ``` + +Note that the database must be configured to accept client certificate auth +for the admin user by having the following entries in `pg_hba.conf`: + +```conf +hostssl all all ::/0 cert +hostssl all all 0.0.0.0/0 cert +``` + +Refer to the [self-hosted PostgreSQL guide](../guides/postgres-self-hosted.mdx#step-35-configure-your-postgresql-server) +for more information. @@ -104,7 +121,7 @@ the `teleport.dev/db-admin` label. ## Step 2/3. Configure Teleport role To specify the database roles a user should be assigned within the database, -use `db_roles` role option: +use the `db_roles` role option: ```yaml kind: role @@ -131,19 +148,16 @@ With automatic user provisioning, users always connect to the database with their Teleport username so the `db_users` role field is ignored for roles that have database user provisioning enabled. -The `db_roles` role option supports all the same [interpolation rules](../../access-controls/guides/role-templates.mdx#interpolation-rules) -as other role fields. - User created within the database will: - Have the same name as Teleport username. - Be a part of the `teleport-auto-users` role. -- Assigned all roles from the Teleport user's roleset that match the database. +- Be assigned all roles from the Teleport user's roleset that match the database. The role names must be valid and exist in the database. See PostgreSQL [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) - documentation for details. + for information on how to create database roles. -Note that in case of the name conflict where the user with the same name already +Note that in case of a name conflict where a user with the same name already exists in the database and is not managed by Teleport (i.e. not a part of the `teleport-auto-users` group), the connection will be aborted. @@ -156,11 +170,12 @@ $ tsh login --proxy=teleport.example.com $ tsh db connect example ``` -If using a [GUI database client](../../connect-your-client/gui-clients.mdx) like -pgAdmin, make sure to use your Teleport username as a database username. -`tsh db connect` will default to it automatically when connecting to a database -with user provisioning enabled. +If using a GUI database client like pgAdmin, make sure to use your Teleport +username as a database username. `tsh db connect` will default to it automatically +when connecting to a database with user provisioning enabled. ## Next steps +- Connect using your [GUI database client](../../connect-your-client/gui-clients.mdx). +- Learn about [role templating](../../access-controls/guides/role-templates.mdx#interpolation-rules). - Read automatic user provisioning [RFD](https://github.com/gravitational/teleport/blob/master/rfd/0113-automatic-database-users.md). From 9ad6ae72e7178c8876d08314be823d485e20c388 Mon Sep 17 00:00:00 2001 From: Roman Tkachenko Date: Wed, 31 May 2023 11:51:24 -0700 Subject: [PATCH 3/6] Fix --- .../database-access/rbac/configuring-auto-user-provisioning.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx b/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx index a752d39ed96d2..637e7cf2fda0d 100644 --- a/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx +++ b/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx @@ -152,7 +152,7 @@ User created within the database will: - Have the same name as Teleport username. - Be a part of the `teleport-auto-users` role. -- Be assigned all roles from the Teleport user's roleset that match the database. +- Be assigned all roles from the Teleport user's role set that match the database. The role names must be valid and exist in the database. See PostgreSQL [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) for information on how to create database roles. From 0b5e9d2d2e9dfc3dcd492062e4270a89334986d2 Mon Sep 17 00:00:00 2001 From: Roman Tkachenko Date: Wed, 31 May 2023 11:59:50 -0700 Subject: [PATCH 4/6] More lint fixes --- docs/pages/database-access/rbac/configuring-access.mdx | 6 +++--- .../rbac/configuring-auto-user-provisioning.mdx | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/pages/database-access/rbac/configuring-access.mdx b/docs/pages/database-access/rbac/configuring-access.mdx index 28c5237d85342..f90d2d8b9ac7b 100644 --- a/docs/pages/database-access/rbac/configuring-access.mdx +++ b/docs/pages/database-access/rbac/configuring-access.mdx @@ -1,5 +1,5 @@ --- -title: Database Role-Based Access Controls +title: Database Access RBAC description: Role-based access control (RBAC) for Teleport database access. --- @@ -11,7 +11,7 @@ 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](../access-controls/introduction.mdx), as +For a more general description of Teleport roles and examples see [RBAC](../../access-controls/introduction.mdx), as this section focuses on configuring RBAC for database access. ## Role configuration @@ -98,7 +98,7 @@ is not currently enforced on MySQL connection attempts. Similar to other role fields, `db_*` fields support templating variables. -The `{{external.xyz}}` variables are replaced with values from external [SSO](../access-controls/sso.mdx) +The `{{external.xyz}}` variables are replaced with values from external [SSO](../../access-controls/sso.mdx) providers. For OIDC, they will be expanded with a value of an "xyz" claim; for SAML — with an "xyz" assertion value. diff --git a/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx b/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx index 637e7cf2fda0d..eb5b1aeabf5a1 100644 --- a/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx +++ b/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx @@ -1,6 +1,6 @@ --- title: Database Automatic User Provisioning (Preview) -description: Configure automatic user provisioning for Database Access. +description: Configure automatic user provisioning for databases. ---
- Automatic user provisioning for Database Access is available starting from + Automatic user provisioning for PostgreSQL is available starting from Teleport 13.1.
From 149b455ab6293275b395eeba490419af200e0024 Mon Sep 17 00:00:00 2001 From: Roman Tkachenko Date: Wed, 31 May 2023 13:53:22 -0700 Subject: [PATCH 5/6] Fix --- docs/pages/database-access/rbac.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/pages/database-access/rbac.mdx b/docs/pages/database-access/rbac.mdx index 6efd81371b4a9..0447114728613 100644 --- a/docs/pages/database-access/rbac.mdx +++ b/docs/pages/database-access/rbac.mdx @@ -1,6 +1,6 @@ --- -title: Database Role-Based Access Controls -description: Role-based access control (RBAC) for Teleport database access. +title: Database Access Control guides +description: Role-based access control guides for Teleport database access. --- These guides cover configuring access control policies for database users. From 10a4cb12351ee5bfa8487dedc409b66e1c65c7c2 Mon Sep 17 00:00:00 2001 From: Roman Tkachenko Date: Thu, 1 Jun 2023 13:35:57 -0700 Subject: [PATCH 6/6] Apply suggestions from code review Co-authored-by: Paul Gottschling --- docs/pages/database-access/rbac.mdx | 2 +- .../rbac/configuring-auto-user-provisioning.mdx | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/pages/database-access/rbac.mdx b/docs/pages/database-access/rbac.mdx index 0447114728613..738df75e6d164 100644 --- a/docs/pages/database-access/rbac.mdx +++ b/docs/pages/database-access/rbac.mdx @@ -1,5 +1,5 @@ --- -title: Database Access Control guides +title: Database Access Control Guides description: Role-based access control guides for Teleport database access. --- diff --git a/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx b/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx index eb5b1aeabf5a1..136467349c364 100644 --- a/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx +++ b/docs/pages/database-access/rbac/configuring-auto-user-provisioning.mdx @@ -43,8 +43,8 @@ users and grant them privileges. -RDS PostgreSQL admin user must have `rds_iam` role attached to allow IAM -authentication. +The RDS PostgreSQL admin user must have the `rds_iam` role attached to allow IAM +authentication: ```sql CREATE USER "teleport-admin" login createrole; @@ -53,11 +53,11 @@ GRANT rds_iam TO "teleport-admin"; Note that the RDS database must have IAM authentication enabled. -Refer to the [RDS guide](../guides/rds.mdx#step-56-create-a-database-iam-user) +Refer to the [AWS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.DBAccounts.html) to make sure you are using the `rds_iam` role correctly. for more information. -Self-hosted PostgreSQL admin user must have X.509 authentication configured. +The self-hosted PostgreSQL admin user must have X.509 authentication configured. ```sql CREATE USER "teleport-admin" login createrole; @@ -72,7 +72,7 @@ hostssl all all 0.0.0.0/0 cert ``` Refer to the [self-hosted PostgreSQL guide](../guides/postgres-self-hosted.mdx#step-35-configure-your-postgresql-server) -for more information. +to ensure that your configuration is correct.