From 34821385731fe2ad60a1c41de1ecd0fc40b98218 Mon Sep 17 00:00:00 2001 From: Paul Gottschling Date: Mon, 12 Feb 2024 10:31:35 -0500 Subject: [PATCH 1/3] Reorganize two Access Controls sections Partially addresses #37558 - Remove the Kubernetes Federation guide. This is more of a side note about `tsh login` with trusted clusters, and gets very little traffic. Consolidate it with the trusted cluster guide, which is more popular. This allows us to remove the "Manage Access" subsection of "Kubernetes Access", which only contains this and the RBAC how-to guide. - Collapse the Kubernetes RBAC how-to guide into "Manage Access" to make it more discoverable. - Collapse the "Configuring Access" guide for databases into "RBAC". The section contains a single guide, so this makes the content more discoverable. --- docs/config.json | 37 +- docs/pages/database-access/introduction.mdx | 5 + docs/pages/database-access/rbac.mdx | 143 +++++- .../rbac/configuring-access.mdx | 140 ------ docs/pages/kubernetes-access/introduction.mdx | 5 +- .../pages/kubernetes-access/manage-access.mdx | 461 +++++++++++++++++- .../manage-access/federation.mdx | 80 --- .../kubernetes-access/manage-access/rbac.mdx | 455 ----------------- .../management/admin/trustedclusters.mdx | 39 ++ 9 files changed, 642 insertions(+), 723 deletions(-) delete mode 100644 docs/pages/database-access/rbac/configuring-access.mdx delete mode 100644 docs/pages/kubernetes-access/manage-access/federation.mdx delete mode 100644 docs/pages/kubernetes-access/manage-access/rbac.mdx diff --git a/docs/config.json b/docs/config.json index aa6fa66f03bae..0fb9f5329abb7 100644 --- a/docs/config.json +++ b/docs/config.json @@ -1174,18 +1174,8 @@ ] }, { - "title": "Configuring Access", - "slug": "/kubernetes-access/manage-access/", - "entries": [ - { - "title": "Setting up Role-Based Access Controls", - "slug": "/kubernetes-access/manage-access/rbac/" - }, - { - "title": "Federation", - "slug": "/kubernetes-access/manage-access/federation/" - } - ] + "title": "Setting up Role-Based Access Controls", + "slug": "/kubernetes-access/manage-access/" }, { "title": "Access Controls Reference", @@ -1354,13 +1344,7 @@ }, { "title": "Access Controls", - "slug": "/database-access/rbac/", - "entries": [ - { - "title": "RBAC", - "slug": "/database-access/rbac/configuring-access/" - } - ] + "slug": "/database-access/rbac/" }, { "title": "Automatic User Provisioning", @@ -2759,11 +2743,6 @@ "destination": "/application-access/guides/dynamodb/", "permanent": true }, - { - "source": "/kubernetes-access/guides/federation/", - "destination": "/kubernetes-access/manage-access/federation/", - "permanent": true - }, { "source": "/kubernetes-access/guides/dynamic-registration/", "destination": "/kubernetes-access/register-clusters/dynamic-registration/", @@ -3198,6 +3177,16 @@ "source": "/choose-an-edition/teleport-team/", "destination": "/choose-an-edition/teleport-cloud/get-started/", "permanent": true + }, + { + "source": "/kubernetes-access/manage-access/rbac/", + "destination": "/kubernetes-access/manage-access/", + "permanent": true + }, + { + "source": "/database-access/rbac/configuring-access/", + "destination": "/database-access/rbac/", + "permanent": true } ] } diff --git a/docs/pages/database-access/introduction.mdx b/docs/pages/database-access/introduction.mdx index 1dd20584d3779..c1cdc8dea23d0 100644 --- a/docs/pages/database-access/introduction.mdx +++ b/docs/pages/database-access/introduction.mdx @@ -51,6 +51,11 @@ with GitHub, execute a few SQL queries and observe them in the audit log: To learn more about configuring role-based access control for database access, check out the [RBAC](./rbac.mdx) section. +Learn how to configure [automatic user +provisioning](./auto-user-provisioning.mdx), which removes the need for creating +individual user accounts in advance or using the same set of shared database +accounts for all users. + The [Architecture](./architecture.mdx) section provides a more in-depth look at Teleport Database Service internals such as networking and security. diff --git a/docs/pages/database-access/rbac.mdx b/docs/pages/database-access/rbac.mdx index a9e96d2b5c662..88c96f642d22e 100644 --- a/docs/pages/database-access/rbac.mdx +++ b/docs/pages/database-access/rbac.mdx @@ -1,13 +1,140 @@ --- -title: Database Access Control Guides -description: Role-based access control guides for Teleport database access. +title: Database Access RBAC +description: Role-based access control (RBAC) for Teleport database access. --- -These guides cover configuring access control policies for database users. +Role-based access control (or RBAC, for short) allows administrators to set up +granular access policies for databases connected to Teleport. -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. +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"*. -The [Automatic User Provisioning](./auto-user-provisioning.mdx) guides explain -how to get Teleport to create database user accounts on demand for MySQL, -PostgreSQL, and more. +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` traits are replaced with values from external [single +sign-on](../../access-controls/sso.mdx) providers. For OIDC, they will be +replaced with the value of an "xyz" claim. For SAML, they are replaced +with an "xyz" assertion value. + +For full details on how traits work in Teleport roles, see +the [Teleport Access Controls +Reference](../../access-controls/reference.mdx). + +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-access.mdx b/docs/pages/database-access/rbac/configuring-access.mdx deleted file mode 100644 index 88c96f642d22e..0000000000000 --- a/docs/pages/database-access/rbac/configuring-access.mdx +++ /dev/null @@ -1,140 +0,0 @@ ---- -title: Database Access RBAC -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` traits are replaced with values from external [single -sign-on](../../access-controls/sso.mdx) providers. For OIDC, they will be -replaced with the value of an "xyz" claim. For SAML, they are replaced -with an "xyz" assertion value. - -For full details on how traits work in Teleport roles, see -the [Teleport Access Controls -Reference](../../access-controls/reference.mdx). - -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/kubernetes-access/introduction.mdx b/docs/pages/kubernetes-access/introduction.mdx index 66abf3b769cf7..b9145b007665a 100644 --- a/docs/pages/kubernetes-access/introduction.mdx +++ b/docs/pages/kubernetes-access/introduction.mdx @@ -53,13 +53,10 @@ manually when you create the cluster. There are a few ways to do this: Once you register a Kubernetes cluster with Teleport, you can apply fine-grained access controls to manage the way users access your cluster. -Read our [Kubernetes RBAC guide](./manage-access/rbac.mdx) for step-by-step +Read our [Kubernetes RBAC guide](./manage-access.mdx) for step-by-step instructions on giving your users the correct access to Kubernetes clusters, groups, users, and resources. For a comprehensive reference to configuring access controls in your Teleport-registered Kubernetes clusters, see our [Access Controls Reference](./controls.mdx). - -See how to federate your Kubernetes access controls using [Teleport Trusted -Clusters](./manage-access/federation.mdx). diff --git a/docs/pages/kubernetes-access/manage-access.mdx b/docs/pages/kubernetes-access/manage-access.mdx index e44be1e143dd2..3e127e2390593 100644 --- a/docs/pages/kubernetes-access/manage-access.mdx +++ b/docs/pages/kubernetes-access/manage-access.mdx @@ -1,18 +1,455 @@ --- -title: Managing Access to Kubernetes Clusters -description: Use Teleport's sophisticated RBAC and trusted clusters to ensure that your teams have the correct access to your Kubernetes clusters. +title: Setting Up Teleport Access Controls for Kubernetes +description: How to configure Teleport roles to access clusters, groups, users, and resources in Kubernetes. --- -Once you register a Kubernetes cluster with Teleport, you can apply -sophisticated policies to manage the way users access your cluster. +The Teleport Kubernetes Service is a proxy that sits between Kubernetes users +and one or more Kubernetes clusters. -Read our [Kubernetes RBAC guide](./manage-access/rbac.mdx) for step-by-step -instructions on giving your users the correct access to Kubernetes clusters, -groups, users, and resources. +When a user authenticates to Teleport, they receive a kubeconfig that lets them +send requests to their authorized Kubernetes clusters via the Teleport +Kubernetes Service. The Kubernetes Service can then inspect, modify, or disallow +these requests depending on the privileges you have assigned to the Teleport +user via their roles. -See how to federate your Kubernetes access controls using [Teleport Trusted -Clusters](./manage-access/federation.mdx). +In this guide, we will use a local Kubernetes cluster to show you how to +configure Teleport's role-based access control (RBAC) system to manage access to +Kubernetes clusers, groups, users, and resources. + +## Prerequisites + +(!docs/pages/includes/edition-prereqs-tabs.mdx!) + +- (!docs/pages/includes/tctl.mdx!) + +To run the local demo environment, ensure that you have the following tools +installed on your workstation: + +| Tool | Purpose | Installation link | +|---------------------------------------------------------------------|----------------------------------|---------------------------------------------------------------| +| minikube | Local Kubernetes deployment tool | [Install minikube](https://minikube.sigs.k8s.io/docs/start/) | +| Helm | Kubernetes package manager | [Install Helm](https://helm.sh/docs/intro/install/) | +| kubectl | Kubernetes admin CLI | [Install kubectl](https://kubernetes.io/docs/tasks/tools/) | +| Docker | Required minikube driver | [Get Started With Docker](https://www.docker.com/get-started) | + +## Step 1/3. Prepare Kubernetes resources + +### Start minikube + +Start minikube with the Docker driver: + +```code +$ minikube start --driver=docker +``` + +This command should start a local Kubernetes cluster and set your context to +`minikube`. To verify this, run the following command: + +```code +$ kubectl config current-context +minikube +``` + +### Deploy demo pods + +On your workstation, create a manifest file called `pods.yaml` with the +following content: + +```yaml +apiVersion: v1 +kind: Namespace +metadata: + name: development + labels: + name: development +--- +apiVersion: v1 +kind: Namespace +metadata: + name: production + labels: + name: production +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: webapp + namespace: development +spec: + selector: + matchLabels: + app: nginx-webapp + template: + metadata: + labels: + app: nginx-webapp + spec: + containers: + - name: nginx + image: nginx:1.23 +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: webapp + namespace: production +spec: + selector: + matchLabels: + app: nginx-webapp + template: + metadata: + labels: + app: nginx-webapp + spec: + containers: + - name: nginx + image: nginx:1.23 +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: loadbalancer + namespace: development +spec: + selector: + matchLabels: + app: nginx-loadbalancer + template: + metadata: + labels: + app: nginx-loadbalancer + spec: + containers: + - name: nginx + image: nginx:1.23 +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: loadbalancer + namespace: production +spec: + selector: + matchLabels: + app: nginx-loadbalancer + template: + metadata: + labels: + app: nginx-loadbalancer + spec: + containers: + - name: nginx + image: nginx:1.23 +``` + +This manifest creates two namespaces, `development` and `production`, and +deploys two `nginx` pods into each one: `webapp` and `loadbalancer`. Apply the +new resources: + +```code +$ kubectl apply -f pods.yaml +``` + +Ensure that the resources are deployed: + +```code +$ kubectl -n development get pods +$ kubectl -n production get pods +``` + +You should see both the `loadbalancer` and `webapp` pods in each namespace. + +### Install Kubernetes RBAC resources + +Now that we have deployed our `webapp` and `loadbalancer` pods in our +`development` and `production` namespaces, we will create a Kubernetes role that +can view all pods in all namespaces. Later in this guide, we will define a +Teleport role that further restricts the access Teleport users can have to +resources in your cluster. + +Create a manifest file called `k8s-rbac.yaml` with the following content: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: pod-viewer +rules: +- apiGroups: [""] + resources: ["pods"] + verbs: ["get", "watch", "list"] +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: pod-viewer +subjects: +- kind: Group + name: developers + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: ClusterRole + name: pod-viewer + apiGroup: rbac.authorization.k8s.io +``` + +Apply your changes: + +```code +$ kubectl apply -f k8s-rbac.yaml +``` + +### Install the Teleport Kubernetes Service + +Now that you have some workloads running on Kubernetes and RBAC resources to +manage access to them, install the Teleport Kubernetes Service in your demo +cluster so you can get more control into the resources that Kubernetes users can +access. + +(!docs/pages/kubernetes-access/helm/includes/helm-repo-add.mdx!) + +Request a token that the Kubernetes Service will use to join your Teleport +cluster: + +```code +$ tctl tokens add --type=kube,app,discovery --ttl=1h --format=text +``` + +Copy this token so you can use it when running the Teleport Kubernetes Service. + +Install the Teleport Kubernetes Service in your cluster, assigning to the host **and port** of your Teleport Proxy Service +(e.g., `mytenant.teleport.sh:443`) and to the token you +requested earlier: + +```code +$ helm install teleport-agent teleport/teleport-kube-agent \ + --set kubeClusterName=minikube \ + --set roles="kube\,app\,discovery" \ + --set proxyAddr= \ + --set authToken= \ + --set labels.region=local --set labels.platform=minikube \ + --create-namespace \ + --namespace=teleport-agent \ + --version (=teleport.version=) +``` + +This `helm install` command supplies the soon-to-be-added Kubernetes Service +instance with two labels: `region:local` and `platform:minikube`. We will use +these to configure access controls for the cluster later in this guide. + +Verify that the `teleport` pod is running in your cluster: + +```code +$ kubectl -n teleport-agent get pods +``` + +You can check that the Teleport Kubernetes Service registered itself with your +Teleport cluster by executing the following command: + +```code +$ tctl get kube_servers +``` + +The output should resemble the following: + +```text +kind: kube_server +metadata: + expires: "2023-01-24T16:20:00.571214635Z" + id: 0000000000000000000 + name: minikube +spec: + cluster: + kind: kube_cluster + metadata: + labels: + platform: minikube + region: local + name: minikube + spec: + aws: {} + azure: {} + gcp: {} + version: v3 + host_id: 00000000-0000-0000-0000-000000000000 + hostname: remote.kube.proxy.teleport.cluster.local + rotation: + current_id: "" + last_rotated: "0001-01-01T00:00:00Z" + schedule: + standby: "0001-01-01T00:00:00Z" + update_clients: "0001-01-01T00:00:00Z" + update_servers: "0001-01-01T00:00:00Z" + started: "0001-01-01T00:00:00Z" + version: (=teleport.version=) +version: v3 +``` + +## Step 2/3. Define a Teleport role + +The Teleport Kubernetes Service determines how to proxy a Teleport user's +requests to a Kubernetes API server by looking up the user's roles. Based on +this information, the Kubernetes Service accepts or denies the request. + +For valid requests, the Kubernetes Service rewrites the request headers to +impersonate the Teleport user's desired Kubernetes user and groups, and forwards +the request to the API server. + +In this section, we will define a Teleport role that: + +- Authenticates the user to a Kubernetes cluster as a member of the `developers` + group. In the previous section, we authorized members of this group to view + pods in all namespaces. +- Enables the user to access `webapp` pods in the `production` namespace and all + pods in the `development` namespace. +- Denies the user access to all other pods. + +### Define a role + +Create a file called `kube-access.yaml` with the following content: + +```yaml +kind: role +metadata: + name: kube-access +version: v7 +spec: + allow: + kubernetes_labels: + 'region': '*' + 'platform': 'minikube' + kubernetes_resources: + - kind: pod + namespace: "production" + name: "^webapp-[a-z0-9-]+$" + - kind: pod + namespace: "development" + name: "*" + kubernetes_groups: + - developers + kubernetes_users: + - minikube + deny: {} +``` + +In this role, we have defined the following `allow` rules: + +- `kubernetes_labels`: Allows access to Kubernetes clusters in all regions, but + only with the `platform:minikube` label. +- `kubernetes_resources`: Allows access to pods in the `webapp` deployment in + the `production` namespace and all pods in the `development` namespace. Note + the use of a regular expression (beginning `^` and ending in `$`) to match pod + names that Kubernetes generates automatically. +- `kubernetes_groups`: Authenticates the user to your Kubernetes cluster as a + member of the Kubernetes group `developers`, which we associated with the + `pod-viewer` Kubernetes `Role` earlier in this guide. +- `kubernetes_users`: Authenticates the user to your Kubernetes cluster as the + default `minikube` user. + +### Create the role + +Once you have finished configuring the `kube-access` role, create it using the +following command: + +```code +$ tctl create kube-access.yaml +``` + +(!docs/pages/includes/add-role-to-user.mdx role="kube-access"!) + +## Step 3/3. Access resources + +At this point, you have configured the Teleport Kubernetes Service to give your +Teleport user access to the `webapp` pod in the `production` namespace. In this +step, we will authenticate to your Kubernetes cluster via Teleport and test our +new access controls. + +List the Kubernetes clusters you can access via Teleport: + +```code +$ tsh kube ls +``` + +You should see the `minikube` cluster you registered earlier: + +```text +Kube Cluster Name Labels Selected +----------------- ------------------------------ -------- +minikube platform=minikube region=local +``` + +To access your Kubernetes cluster via Teleport, authenticate to it and update +your kubeconfig: + +```code +$ tsh kube login minikube +``` + +When listing pods in all namespaces, the Teleport Kubernetes Service will filter +the pods it retrieves to show only those that your Teleport user can access. Run +the following command: + +```code +$ kubectl get pods --all-namespaces +``` + +The output will show the `webapp` pod in the `production` namespace and both the +`webapp` and `loadbalancer` pods in the `development` namespace: + +```text +NAMESPACE NAME READY STATUS RESTARTS AGE +development loadbalancer-000000000-00000 1/1 Running 0 36m +development webapp-0000000000-00000 1/1 Running 0 36m +production webapp-0000000000-00000 1/1 Running 0 36m +``` + +You can access information about the `webapp` pod in the `production` namespace: + +```code +$ kubectl -n production get pods/webapp-0000000000-00000 -o json +``` + +Also note that the `kube-access` role we created earlier mapped your Teleport +user to the `developers` Kubernetes group, which has permissions only to view +pods: + +```code +$ kubectl auth can-i create pods +no +``` + +By configuring Teleport roles and Kubernetes RBAC resources, you can fine-tune +the access that users in your organization have to your Kubernetes-based +infrastructure. + +When you authenticated to your `minikube` cluster via `tsh kube login`, Teleport +generated a kubeconfig that connects to your cluster via Teleport: + +```code +$ kubectl config current-context +teleport.example.com-minikube +``` + +If you want to regain full control of your `minikube` cluster, you can use the +default `minikube` context instead: + +```code +$ kubectl config use-context minikube +``` + +## Next steps + +For more detailed information on how Teleport RBAC for Kubernetes works, consult +the Kubernetes [Access Controls Guide](../controls.mdx). You can leave your +`minikube` cluster running so you can try out different Teleport and Kubernetes +RBAC configurations. + +Now that you know how to configure Teleport's RBAC system to control access to +Kubernetes clusters, learn how to set up [Resource Access +Requests](../../access-controls/access-requests/resource-requests.mdx) +for just-in-time access and [Access Request +plugins](../../access-controls/access-request-plugins/index.mdx) so you can manage +access with your communication workflow of choice. -For a comprehensive reference to configuring access controls in your -Teleport-registered Kubernetes clusters, see our [Access Controls -Reference](./controls.mdx). diff --git a/docs/pages/kubernetes-access/manage-access/federation.mdx b/docs/pages/kubernetes-access/manage-access/federation.mdx deleted file mode 100644 index 7ebb54d9052e9..0000000000000 --- a/docs/pages/kubernetes-access/manage-access/federation.mdx +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: Federated Kubernetes Access with Trusted Clusters -description: Federated Access using Teleport trusted clusters. ---- - -There are cases when you have Kubernetes clusters that have to operate independently, -for example, they are part of a different organization or have intermittent connectivity. - -You can take advantage of [trusted clusters](../../management/admin/trustedclusters.mdx) -to federate trust across Kubernetes clusters. - - - - -When multiple trusted clusters are present behind the Teleport Proxy Service, the -`kubeconfig` generated by [tsh login](../../reference/cli/tsh.mdx#tsh-login) contains the -Kubernetes API endpoint determined by the `` argument to [tsh -login](../../reference/cli/tsh.mdx#tsh-login). - -For example, consider the following scenario: - -- There are three Teleport/Kubernetes clusters: the root cluster named `main` and the leaf clusters - named `east` and `west` in the `cluster_name` setting for each cluster. -- The clusters `east` and `west` trust the `main` root cluster certificate authority. -- Users always authenticate against `main` but use their certificates to access - SSH nodes and the Kubernetes API in all three clusters. -- The DNS name of the root cluster Teleport Proxy Service is `main.example.com`. - -In this scenario, users usually log in using the following command: - -```code -# Using login without arguments -$ tsh --proxy=main.example.com login - -# User's `kubeconfig` now contains one entry for the main Kubernetes -# endpoint, i.e. `main.example.com`. - -# Receive a certificate for "east": -$ tsh --proxy=main.example.com login east - -# User's `kubeconfig` now contains the entry for the "east" Kubernetes -# endpoint, i.e. `east.main.example.com`. -``` - - - - -When multiple trusted clusters are present behind the Teleport Proxy Service, the -`kubeconfig` generated by [tsh login](../../reference/cli/tsh.mdx#tsh-login) contains the -Kubernetes API endpoint determined by the `` argument to the [tsh -login](../../reference/cli/tsh.mdx#tsh-login) command. - -For example, consider the following scenario: - -- There are two Teleport/Kubernetes clusters named `east` and `west`. - Each cluster has its own configuration file with its name specified in the - `cluster_name` field. -- The clusters `east` and `west` are leaf clusters that trust a Teleport Team - or Enterprise Cloud account, for example, `mytenant.teleport.sh`. -- Users always authenticate against `mytenant.teleport.sh` but use their certificates to access - SSH nodes and the Kubernetes API in all three clusters. - -In this scenario, users usually log in using the following command: - -```code -# Using login without arguments -$ tsh --proxy=mytenant.teleport.sh login - -# User's `kubeconfig` now contains one entry for the main Kubernetes -# endpoint, i.e. `mytenant.teleport.sh`. - -# Receive a certificate for "east": -$ tsh --proxy=mytenant.teleport.sh login east - -# User's `kubeconfig` now contains the entry for the "east" Kubernetes -# endpoint, i.e. `east.mytenant.teleport.sh`. -``` - - - diff --git a/docs/pages/kubernetes-access/manage-access/rbac.mdx b/docs/pages/kubernetes-access/manage-access/rbac.mdx deleted file mode 100644 index 3e127e2390593..0000000000000 --- a/docs/pages/kubernetes-access/manage-access/rbac.mdx +++ /dev/null @@ -1,455 +0,0 @@ ---- -title: Setting Up Teleport Access Controls for Kubernetes -description: How to configure Teleport roles to access clusters, groups, users, and resources in Kubernetes. ---- - -The Teleport Kubernetes Service is a proxy that sits between Kubernetes users -and one or more Kubernetes clusters. - -When a user authenticates to Teleport, they receive a kubeconfig that lets them -send requests to their authorized Kubernetes clusters via the Teleport -Kubernetes Service. The Kubernetes Service can then inspect, modify, or disallow -these requests depending on the privileges you have assigned to the Teleport -user via their roles. - -In this guide, we will use a local Kubernetes cluster to show you how to -configure Teleport's role-based access control (RBAC) system to manage access to -Kubernetes clusers, groups, users, and resources. - -## Prerequisites - -(!docs/pages/includes/edition-prereqs-tabs.mdx!) - -- (!docs/pages/includes/tctl.mdx!) - -To run the local demo environment, ensure that you have the following tools -installed on your workstation: - -| Tool | Purpose | Installation link | -|---------------------------------------------------------------------|----------------------------------|---------------------------------------------------------------| -| minikube | Local Kubernetes deployment tool | [Install minikube](https://minikube.sigs.k8s.io/docs/start/) | -| Helm | Kubernetes package manager | [Install Helm](https://helm.sh/docs/intro/install/) | -| kubectl | Kubernetes admin CLI | [Install kubectl](https://kubernetes.io/docs/tasks/tools/) | -| Docker | Required minikube driver | [Get Started With Docker](https://www.docker.com/get-started) | - -## Step 1/3. Prepare Kubernetes resources - -### Start minikube - -Start minikube with the Docker driver: - -```code -$ minikube start --driver=docker -``` - -This command should start a local Kubernetes cluster and set your context to -`minikube`. To verify this, run the following command: - -```code -$ kubectl config current-context -minikube -``` - -### Deploy demo pods - -On your workstation, create a manifest file called `pods.yaml` with the -following content: - -```yaml -apiVersion: v1 -kind: Namespace -metadata: - name: development - labels: - name: development ---- -apiVersion: v1 -kind: Namespace -metadata: - name: production - labels: - name: production ---- -apiVersion: apps/v1 -kind: Deployment -metadata: - name: webapp - namespace: development -spec: - selector: - matchLabels: - app: nginx-webapp - template: - metadata: - labels: - app: nginx-webapp - spec: - containers: - - name: nginx - image: nginx:1.23 ---- -apiVersion: apps/v1 -kind: Deployment -metadata: - name: webapp - namespace: production -spec: - selector: - matchLabels: - app: nginx-webapp - template: - metadata: - labels: - app: nginx-webapp - spec: - containers: - - name: nginx - image: nginx:1.23 ---- -apiVersion: apps/v1 -kind: Deployment -metadata: - name: loadbalancer - namespace: development -spec: - selector: - matchLabels: - app: nginx-loadbalancer - template: - metadata: - labels: - app: nginx-loadbalancer - spec: - containers: - - name: nginx - image: nginx:1.23 ---- -apiVersion: apps/v1 -kind: Deployment -metadata: - name: loadbalancer - namespace: production -spec: - selector: - matchLabels: - app: nginx-loadbalancer - template: - metadata: - labels: - app: nginx-loadbalancer - spec: - containers: - - name: nginx - image: nginx:1.23 -``` - -This manifest creates two namespaces, `development` and `production`, and -deploys two `nginx` pods into each one: `webapp` and `loadbalancer`. Apply the -new resources: - -```code -$ kubectl apply -f pods.yaml -``` - -Ensure that the resources are deployed: - -```code -$ kubectl -n development get pods -$ kubectl -n production get pods -``` - -You should see both the `loadbalancer` and `webapp` pods in each namespace. - -### Install Kubernetes RBAC resources - -Now that we have deployed our `webapp` and `loadbalancer` pods in our -`development` and `production` namespaces, we will create a Kubernetes role that -can view all pods in all namespaces. Later in this guide, we will define a -Teleport role that further restricts the access Teleport users can have to -resources in your cluster. - -Create a manifest file called `k8s-rbac.yaml` with the following content: - -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRole -metadata: - name: pod-viewer -rules: -- apiGroups: [""] - resources: ["pods"] - verbs: ["get", "watch", "list"] ---- -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRoleBinding -metadata: - name: pod-viewer -subjects: -- kind: Group - name: developers - apiGroup: rbac.authorization.k8s.io -roleRef: - kind: ClusterRole - name: pod-viewer - apiGroup: rbac.authorization.k8s.io -``` - -Apply your changes: - -```code -$ kubectl apply -f k8s-rbac.yaml -``` - -### Install the Teleport Kubernetes Service - -Now that you have some workloads running on Kubernetes and RBAC resources to -manage access to them, install the Teleport Kubernetes Service in your demo -cluster so you can get more control into the resources that Kubernetes users can -access. - -(!docs/pages/kubernetes-access/helm/includes/helm-repo-add.mdx!) - -Request a token that the Kubernetes Service will use to join your Teleport -cluster: - -```code -$ tctl tokens add --type=kube,app,discovery --ttl=1h --format=text -``` - -Copy this token so you can use it when running the Teleport Kubernetes Service. - -Install the Teleport Kubernetes Service in your cluster, assigning to the host **and port** of your Teleport Proxy Service -(e.g., `mytenant.teleport.sh:443`) and to the token you -requested earlier: - -```code -$ helm install teleport-agent teleport/teleport-kube-agent \ - --set kubeClusterName=minikube \ - --set roles="kube\,app\,discovery" \ - --set proxyAddr= \ - --set authToken= \ - --set labels.region=local --set labels.platform=minikube \ - --create-namespace \ - --namespace=teleport-agent \ - --version (=teleport.version=) -``` - -This `helm install` command supplies the soon-to-be-added Kubernetes Service -instance with two labels: `region:local` and `platform:minikube`. We will use -these to configure access controls for the cluster later in this guide. - -Verify that the `teleport` pod is running in your cluster: - -```code -$ kubectl -n teleport-agent get pods -``` - -You can check that the Teleport Kubernetes Service registered itself with your -Teleport cluster by executing the following command: - -```code -$ tctl get kube_servers -``` - -The output should resemble the following: - -```text -kind: kube_server -metadata: - expires: "2023-01-24T16:20:00.571214635Z" - id: 0000000000000000000 - name: minikube -spec: - cluster: - kind: kube_cluster - metadata: - labels: - platform: minikube - region: local - name: minikube - spec: - aws: {} - azure: {} - gcp: {} - version: v3 - host_id: 00000000-0000-0000-0000-000000000000 - hostname: remote.kube.proxy.teleport.cluster.local - rotation: - current_id: "" - last_rotated: "0001-01-01T00:00:00Z" - schedule: - standby: "0001-01-01T00:00:00Z" - update_clients: "0001-01-01T00:00:00Z" - update_servers: "0001-01-01T00:00:00Z" - started: "0001-01-01T00:00:00Z" - version: (=teleport.version=) -version: v3 -``` - -## Step 2/3. Define a Teleport role - -The Teleport Kubernetes Service determines how to proxy a Teleport user's -requests to a Kubernetes API server by looking up the user's roles. Based on -this information, the Kubernetes Service accepts or denies the request. - -For valid requests, the Kubernetes Service rewrites the request headers to -impersonate the Teleport user's desired Kubernetes user and groups, and forwards -the request to the API server. - -In this section, we will define a Teleport role that: - -- Authenticates the user to a Kubernetes cluster as a member of the `developers` - group. In the previous section, we authorized members of this group to view - pods in all namespaces. -- Enables the user to access `webapp` pods in the `production` namespace and all - pods in the `development` namespace. -- Denies the user access to all other pods. - -### Define a role - -Create a file called `kube-access.yaml` with the following content: - -```yaml -kind: role -metadata: - name: kube-access -version: v7 -spec: - allow: - kubernetes_labels: - 'region': '*' - 'platform': 'minikube' - kubernetes_resources: - - kind: pod - namespace: "production" - name: "^webapp-[a-z0-9-]+$" - - kind: pod - namespace: "development" - name: "*" - kubernetes_groups: - - developers - kubernetes_users: - - minikube - deny: {} -``` - -In this role, we have defined the following `allow` rules: - -- `kubernetes_labels`: Allows access to Kubernetes clusters in all regions, but - only with the `platform:minikube` label. -- `kubernetes_resources`: Allows access to pods in the `webapp` deployment in - the `production` namespace and all pods in the `development` namespace. Note - the use of a regular expression (beginning `^` and ending in `$`) to match pod - names that Kubernetes generates automatically. -- `kubernetes_groups`: Authenticates the user to your Kubernetes cluster as a - member of the Kubernetes group `developers`, which we associated with the - `pod-viewer` Kubernetes `Role` earlier in this guide. -- `kubernetes_users`: Authenticates the user to your Kubernetes cluster as the - default `minikube` user. - -### Create the role - -Once you have finished configuring the `kube-access` role, create it using the -following command: - -```code -$ tctl create kube-access.yaml -``` - -(!docs/pages/includes/add-role-to-user.mdx role="kube-access"!) - -## Step 3/3. Access resources - -At this point, you have configured the Teleport Kubernetes Service to give your -Teleport user access to the `webapp` pod in the `production` namespace. In this -step, we will authenticate to your Kubernetes cluster via Teleport and test our -new access controls. - -List the Kubernetes clusters you can access via Teleport: - -```code -$ tsh kube ls -``` - -You should see the `minikube` cluster you registered earlier: - -```text -Kube Cluster Name Labels Selected ------------------ ------------------------------ -------- -minikube platform=minikube region=local -``` - -To access your Kubernetes cluster via Teleport, authenticate to it and update -your kubeconfig: - -```code -$ tsh kube login minikube -``` - -When listing pods in all namespaces, the Teleport Kubernetes Service will filter -the pods it retrieves to show only those that your Teleport user can access. Run -the following command: - -```code -$ kubectl get pods --all-namespaces -``` - -The output will show the `webapp` pod in the `production` namespace and both the -`webapp` and `loadbalancer` pods in the `development` namespace: - -```text -NAMESPACE NAME READY STATUS RESTARTS AGE -development loadbalancer-000000000-00000 1/1 Running 0 36m -development webapp-0000000000-00000 1/1 Running 0 36m -production webapp-0000000000-00000 1/1 Running 0 36m -``` - -You can access information about the `webapp` pod in the `production` namespace: - -```code -$ kubectl -n production get pods/webapp-0000000000-00000 -o json -``` - -Also note that the `kube-access` role we created earlier mapped your Teleport -user to the `developers` Kubernetes group, which has permissions only to view -pods: - -```code -$ kubectl auth can-i create pods -no -``` - -By configuring Teleport roles and Kubernetes RBAC resources, you can fine-tune -the access that users in your organization have to your Kubernetes-based -infrastructure. - -When you authenticated to your `minikube` cluster via `tsh kube login`, Teleport -generated a kubeconfig that connects to your cluster via Teleport: - -```code -$ kubectl config current-context -teleport.example.com-minikube -``` - -If you want to regain full control of your `minikube` cluster, you can use the -default `minikube` context instead: - -```code -$ kubectl config use-context minikube -``` - -## Next steps - -For more detailed information on how Teleport RBAC for Kubernetes works, consult -the Kubernetes [Access Controls Guide](../controls.mdx). You can leave your -`minikube` cluster running so you can try out different Teleport and Kubernetes -RBAC configurations. - -Now that you know how to configure Teleport's RBAC system to control access to -Kubernetes clusters, learn how to set up [Resource Access -Requests](../../access-controls/access-requests/resource-requests.mdx) -for just-in-time access and [Access Request -plugins](../../access-controls/access-request-plugins/index.mdx) so you can manage -access with your communication workflow of choice. - diff --git a/docs/pages/management/admin/trustedclusters.mdx b/docs/pages/management/admin/trustedclusters.mdx index 86a4d3d8d2a60..1a9e7de0f474b 100644 --- a/docs/pages/management/admin/trustedclusters.mdx +++ b/docs/pages/management/admin/trustedclusters.mdx @@ -767,6 +767,45 @@ your Teleport username: You can repeat these steps to change `spec.enabled` to `true` if you want to reestablish the trust relationship between the leaf cluster and the root cluster. +## Federating access to Kubernetes clusters + +There are cases when you have Kubernetes clusters that have to operate +independently, for example, they are part of a different organization or have +intermittent connectivity. + +You can take advantage of trusted clusters to federate trust across Kubernetes +clusters. + +When multiple trusted clusters are present behind the Teleport Proxy Service, +the `kubeconfig` generated by `tsh login` contains the Kubernetes API endpoint +determined by the `` argument to the `tsh login` command. + +For example, consider the following scenario: + +- There are two Teleport/Kubernetes clusters named `east` and `west`. Each + cluster has its own configuration file with its name specified in the + `cluster_name` field. +- The clusters `east` and `west` are leaf clusters that trust a Teleport Team or + Enterprise Cloud account, for example, `example.teleport.sh`. +- Users always authenticate against `example.teleport.sh` but use their + certificates to access SSH nodes and the Kubernetes API in all three clusters. + +In this scenario, users usually log in using the following command: + +```code +# Using login without arguments +$ tsh --proxy=mytenant.teleport.sh login + +# User's `kubeconfig` now contains one entry for the main Kubernetes +# endpoint, i.e. `mytenant.teleport.sh`. + +# Receive a certificate for "east": +$ tsh --proxy=mytenant.teleport.sh login east + +# User's `kubeconfig` now contains the entry for the "east" Kubernetes +# endpoint, i.e. `east.mytenant.teleport.sh`. +``` + ## Remove a trusted leaf cluster If you want to completely remove a leaf cluster without the possibility of restoring From 5161fb8307f2c48dda093eee69ad580bc92757e9 Mon Sep 17 00:00:00 2001 From: Paul Gottschling Date: Mon, 26 Feb 2024 09:41:51 -0500 Subject: [PATCH 2/3] Respond to tigrato feedback - Add `tsh kube login` instructions to the trusted cluster guide changes. --- .../management/admin/trustedclusters.mdx | 23 ++++++++++--------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/docs/pages/management/admin/trustedclusters.mdx b/docs/pages/management/admin/trustedclusters.mdx index 1a9e7de0f474b..b80f3c7989f2e 100644 --- a/docs/pages/management/admin/trustedclusters.mdx +++ b/docs/pages/management/admin/trustedclusters.mdx @@ -782,28 +782,29 @@ determined by the `` argument to the `tsh login` command. For example, consider the following scenario: -- There are two Teleport/Kubernetes clusters named `east` and `west`. Each - cluster has its own configuration file with its name specified in the - `cluster_name` field. +- There are two Teleport clusters named `east` and `west`, and two Kubernetes + clusters with the same names. Each Teleport cluster has its own configuration + file with its name specified in the `cluster_name` field. - The clusters `east` and `west` are leaf clusters that trust a Teleport Team or Enterprise Cloud account, for example, `example.teleport.sh`. - Users always authenticate against `example.teleport.sh` but use their certificates to access SSH nodes and the Kubernetes API in all three clusters. -In this scenario, users usually log in using the following command: +In this scenario, users usually log in using the following commands: ```code -# Using login without arguments +# Log in to the root cluster $ tsh --proxy=mytenant.teleport.sh login -# User's `kubeconfig` now contains one entry for the main Kubernetes -# endpoint, i.e. `mytenant.teleport.sh`. - -# Receive a certificate for "east": +# Receive a certificate for "east" $ tsh --proxy=mytenant.teleport.sh login east -# User's `kubeconfig` now contains the entry for the "east" Kubernetes -# endpoint, i.e. `east.mytenant.teleport.sh`. +# Log in to the Kubernetes cluster called "east" in the Teleport cluster with +# the same name +$ tsh kube login --proxy=mytenant.teleport.sh --cluster=east east + +# The user's kubeconfig now contains the entry for the "east" Kubernetes +# endpoint, i.e. east.mytenant.teleport.sh ``` ## Remove a trusted leaf cluster From 2322d7ad7d2391e225b90f6473459d3e842a3380 Mon Sep 17 00:00:00 2001 From: Paul Gottschling Date: Fri, 1 Mar 2024 11:56:38 -0500 Subject: [PATCH 3/3] Fix linter issues --- CHANGELOG.md | 2 +- docs/pages/access-controls/reference.mdx | 2 +- docs/pages/api/rbac.mdx | 2 +- docs/pages/database-access/getting-started.mdx | 2 +- docs/pages/database-access/rbac.mdx | 6 +++--- .../deploy-a-cluster/helm-deployments/digitalocean.mdx | 1 - docs/pages/kubernetes-access/controls.mdx | 3 +-- docs/pages/kubernetes-access/manage-access.mdx | 6 +++--- docs/pages/machine-id/access-guides/databases.mdx | 4 ++-- 9 files changed, 13 insertions(+), 15 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index bd469189830f1..c591bd79aa6a9 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -3433,7 +3433,7 @@ can limit access by changing the options on the new `event` resource. The minimum set of Kubernetes permissions that need to be granted to Teleport proxies has been updated. If you use the Kubernetes integration, please make sure that the ClusterRole used by the proxy has [sufficient -permissions](./docs/pages/kubernetes-access/manage-access/rbac.mdx). +permissions](./docs/pages/kubernetes-access/controls.mdx). ##### Path prefix for etcd diff --git a/docs/pages/access-controls/reference.mdx b/docs/pages/access-controls/reference.mdx index dc2cb131a5ae5..3f48c3bf916fc 100644 --- a/docs/pages/access-controls/reference.mdx +++ b/docs/pages/access-controls/reference.mdx @@ -99,7 +99,7 @@ Label | `v3` Default | `v4`, `v5` and `v6` Default `db_labels` | `[{"*": "*"}]` | `[]` Role `v6` introduced a new field `kubernetes_resources` that allows -fine-grained control over Kubernetes resources. See [Kubernetes RBAC](../kubernetes-access/manage-access/rbac.mdx) for more details. +fine-grained control over Kubernetes resources. See [Kubernetes RBAC](../kubernetes-access/controls.mdx) for more details. Version | `kubernetes_resources` ------------------ | -------------- diff --git a/docs/pages/api/rbac.mdx b/docs/pages/api/rbac.mdx index d7d2cda79e124..46dad1fdf95d5 100644 --- a/docs/pages/api/rbac.mdx +++ b/docs/pages/api/rbac.mdx @@ -939,7 +939,7 @@ resources: - [Servers](../server-access/rbac.mdx) - [Databases](../database-access/rbac.mdx) -- [Kubernetes clusters](../kubernetes-access/manage-access/rbac.mdx) +- [Kubernetes clusters](../kubernetes-access/controls.mdx) - [Windows Desktops](../desktop-access/rbac.mdx) - [Applications](../application-access/controls.mdx) diff --git a/docs/pages/database-access/getting-started.mdx b/docs/pages/database-access/getting-started.mdx index 66ca7062d2396..15edf4bdb474c 100644 --- a/docs/pages/database-access/getting-started.mdx +++ b/docs/pages/database-access/getting-started.mdx @@ -83,7 +83,7 @@ GRANT rds_iam TO alice; For more information about connecting to the PostgreSQL instance directly, see the AWS [documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html). -See the [Automatic User Provisioning](./rbac/configuring-access.mdx) guide for how to configure Teleport to create accounts for your PostgreSQL users on demand. +See the [Automatic User Provisioning](./rbac.mdx) guide for how to configure Teleport to create accounts for your PostgreSQL users on demand. ## Step 2/5. Configure the Teleport Database Service diff --git a/docs/pages/database-access/rbac.mdx b/docs/pages/database-access/rbac.mdx index 88c96f642d22e..b4dfbb86bc1b6 100644 --- a/docs/pages/database-access/rbac.mdx +++ b/docs/pages/database-access/rbac.mdx @@ -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 @@ -99,13 +99,13 @@ is not currently enforced on MySQL connection attempts. Similar to other role fields, `db_*` fields support templating variables. The `external.xyz` traits are replaced with values from external [single -sign-on](../../access-controls/sso.mdx) providers. For OIDC, they will be +sign-on](../access-controls/sso.mdx) providers. For OIDC, they will be replaced with the value of an "xyz" claim. For SAML, they are replaced with an "xyz" assertion value. For full details on how traits work in Teleport roles, see the [Teleport Access Controls -Reference](../../access-controls/reference.mdx). +Reference](../access-controls/reference.mdx). 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: diff --git a/docs/pages/deploy-a-cluster/helm-deployments/digitalocean.mdx b/docs/pages/deploy-a-cluster/helm-deployments/digitalocean.mdx index 49549a7f1c035..5a977eac61cd1 100644 --- a/docs/pages/deploy-a-cluster/helm-deployments/digitalocean.mdx +++ b/docs/pages/deploy-a-cluster/helm-deployments/digitalocean.mdx @@ -278,6 +278,5 @@ Teleport: - Connect another Kubernetes cluster to Teleport by [deploying the Teleport Kubernetes Service](../../kubernetes-access/getting-started.mdx) - [Set up Machine ID with Kubernetes](../../machine-id/access-guides/kubernetes.mdx) -- [Federated Access using Trusted Clusters](../../kubernetes-access/manage-access/federation.mdx) - [Single-Sign On and Kubernetes Access Control](../../kubernetes-access/controls.mdx) diff --git a/docs/pages/kubernetes-access/controls.mdx b/docs/pages/kubernetes-access/controls.mdx index 8ea0f7a16eb77..92fccb3b6b821 100644 --- a/docs/pages/kubernetes-access/controls.mdx +++ b/docs/pages/kubernetes-access/controls.mdx @@ -13,8 +13,7 @@ Teleport role to manage access to Kubernetes clusters you have connected to Teleport. For an example of how to use Teleport roles to manage access to Kubernetes with -a local `minikube` cluster, see our [RBAC how-to -guide](./manage-access/rbac.mdx). +a local `minikube` cluster, see our [RBAC how-to guide](./manage-access.mdx). ## Role fields for managing Kubernetes access diff --git a/docs/pages/kubernetes-access/manage-access.mdx b/docs/pages/kubernetes-access/manage-access.mdx index 3e127e2390593..3dff0457c6a86 100644 --- a/docs/pages/kubernetes-access/manage-access.mdx +++ b/docs/pages/kubernetes-access/manage-access.mdx @@ -442,14 +442,14 @@ $ kubectl config use-context minikube ## Next steps For more detailed information on how Teleport RBAC for Kubernetes works, consult -the Kubernetes [Access Controls Guide](../controls.mdx). You can leave your +the Kubernetes [Access Controls Guide](controls.mdx). You can leave your `minikube` cluster running so you can try out different Teleport and Kubernetes RBAC configurations. Now that you know how to configure Teleport's RBAC system to control access to Kubernetes clusters, learn how to set up [Resource Access -Requests](../../access-controls/access-requests/resource-requests.mdx) +Requests](../access-controls/access-requests/resource-requests.mdx) for just-in-time access and [Access Request -plugins](../../access-controls/access-request-plugins/index.mdx) so you can manage +plugins](../access-controls/access-request-plugins/index.mdx) so you can manage access with your communication workflow of choice. diff --git a/docs/pages/machine-id/access-guides/databases.mdx b/docs/pages/machine-id/access-guides/databases.mdx index 5f9ac09c59715..7c961089e4469 100644 --- a/docs/pages/machine-id/access-guides/databases.mdx +++ b/docs/pages/machine-id/access-guides/databases.mdx @@ -72,7 +72,7 @@ This rule will allow the bot to do two things: The `'*': '*'` label selector grants access to any database server configured in Teleport. In production, consider restricting the bot's access using a more specific label selector; see the -[Database Access RBAC guide](../../database-access/rbac/configuring-access.mdx) +[Database Access RBAC guide](../../database-access/rbac.mdx) for a full reference of database-related role options. ## Step 2/4. Configure a database `tbot` output @@ -248,4 +248,4 @@ access controls. ## Next steps - Read the [configuration reference](../reference/configuration.mdx) to explore - all the available configuration options. \ No newline at end of file + all the available configuration options.