address feedback

gravitational · Feb 2, 2024 · 0b2dc27 · 0b2dc27
1 parent 66e296b
commit 0b2dc27
Show file tree

Hide file tree

Showing 6 changed files with 33 additions and 46 deletions.
diff --git a/docs/pages/management/dynamic-resources.mdx b/docs/pages/management/dynamic-resources.mdx
@@ -60,8 +60,9 @@ of Teleport's configuration interface makes it well suited for
 infrastructure-as-code and GitOps approaches.
 
 You can get started with `tctl`, the Terraform Provider, and the Kubernetes
-Operator by following
-the ["Managing Users and Roles with IaC" guide](./dynamic-resources/user-and-role.mdx)
+Operator by following: 
+- the ["Managing Users and Roles with IaC" guide](./dynamic-resources/user-and-role.mdx)
+- the ["Creating Access Lists with IaC" guide](./dynamic-resources/access-list.mdx)
 
 For more information on Teleport roles, including the `internal.logins`
 trait we use in these example roles, see the [Teleport Access

diff --git a/docs/pages/management/dynamic-resources/access-list.mdx b/docs/pages/management/dynamic-resources/access-list.mdx
@@ -7,9 +7,10 @@ Access Lists allow Teleport users to be granted long-term access to resources
 managed within Teleport. With Access Lists, administrators can regularly audit and control membership to specific roles and
 traits, which then tie easily back into Teleport's existing RBAC system.
 
-In this guide, we'll follow up on [the IaC users and roles guide]()
-by allowing users with the `manager` role to grant the `support-engineer` role
-to users meeting specific criteria.
+In this guide, we'll follow up
+on [the IaC users and roles guide](./user-and-role.mdx) by allowing users with
+the `manager` role to grant the `support-engineer` role to users meeting
+specific criteria.
 
 Please note that Access Lists can be managed via IaC but Access List memberships
 cannot. The goal of Access Lists is to decentralize granting and reviewing
@@ -20,14 +21,15 @@ This reduces the load on the centralized IaC/security team, ensures the access
 reviewer is aware of the context, reduces the request resolution time, and
 ensures access grants are periodically reviewed.
 
-### Prerequisites
+## Prerequisites
 
-To follow this guide, you must follow first [the basic users and roles IaC guide]().
-We will reuse its users and roles for our Access List.
+To follow this guide, you must follow
+first [the basic users and roles IaC guide](./user-and-role.mdx). We will reuse
+its users and roles for our Access List.
 
-## Step 1/3. Write manifests
+## Step 1/3 - Write manifests
 
-#### Write the privileged role manifest
+### Write the privileged role manifest
 
 We will create a new role `support-engineer` that grants access to production
 servers. The `engineer` role from the previous guide was only granting access to
@@ -57,8 +59,8 @@ spec:
 Create the following `privileged-role.yaml` file:
 
 ```yaml
-apiVersion: resources.teleport.dev/v5
-kind: TeleportRole
+apiVersion: resources.teleport.dev/v1
+kind: TeleportRoleV7
 metadata:
   name: support-engineer
 spec:
@@ -68,11 +70,6 @@ spec:
       'env': [ 'production' ]
 ```
 
-<Admonition type="note">
-The role version is v5 because the Teleport Kubernetes Operator doesn't support
-yet roles v6 and v7.
-</Admonition>
-
 </TabItem>
 <TabItem label="Terraform">
 
@@ -99,7 +96,7 @@ resource "teleport_role" "support-engineer" {
 </TabItem>
 </Tabs>
 
-#### Write the Access List manifest
+### Write the Access List manifest
 
 In this step we'll create an Access List that allows users with the `manager`
 role such as  `alice` to grant access to production to users with the `engineer`
@@ -209,7 +206,7 @@ resource "teleport_access_list" "support-engineers" {
 </TabItem>
 </Tabs>
 
-## Step 2/3. Apply the manifests
+## Step 2/3 - Apply the manifests
 
 <Tabs>
 <TabItem label="tctl">
@@ -258,7 +255,7 @@ teleport_access_list.support-engineers: Creation complete after 0s [id=support-e
 </TabItem>
 </Tabs>
 
-## Step 3/3. Log in as `alice` and grant access to `bob`
+## Step 3/3 - Log in as `alice` and grant access to `bob`
 
 Now, you created an Access List allowing `alice` to grant the `support-engineer`
 role to its engineers.
@@ -297,7 +294,7 @@ Members of support-engineers:
 </TabItem>
 </Tabs>
 
-### Next steps
+## Next steps
 
 You can see all supported Access List fields
 [in the Access List reference](../../access-controls/access-lists/reference.mdx).
diff --git a/docs/pages/management/dynamic-resources/teleport-operator-helm.mdx b/docs/pages/management/dynamic-resources/teleport-operator-helm.mdx
@@ -35,7 +35,7 @@ $ kubectl cluster-info
   ```
 </Admonition>
 
-## Step 1/2. Install teleport-cluster Helm chart with the operator
+## Step 1/2 - Install teleport-cluster Helm chart with the operator
 
 (!docs/pages/kubernetes-access/helm/includes/helm-repo-add.mdx!)
 

diff --git a/docs/pages/management/dynamic-resources/teleport-operator-standalone.mdx b/docs/pages/management/dynamic-resources/teleport-operator-standalone.mdx
@@ -138,6 +138,4 @@ Helm Chart parameters are documented in the [`teleport-operator` Helm chart refe
 
 ## Troubleshooting
 
-TODO: add troubleshooting steps for operator pod
-
 (!docs/pages/includes/diagnostics/kubernetes-operator-troubleshooting.mdx!)
diff --git a/docs/pages/management/dynamic-resources/user-and-role.mdx b/docs/pages/management/dynamic-resources/user-and-role.mdx
@@ -1,5 +1,5 @@
 ---
-title: Managing users and roles with IaC
+title: Managing Users And Roles With IaC
 description: Use Infrastructure-as-Code tooling to create Teleport users and roles.
 ---
 
@@ -14,7 +14,7 @@ create resources from code:
 - The `tctl` CLI that allows you to manage Teleport resources from your local
   computer or your CI environment
 
-### Prerequisites
+## Prerequisites
 
 To follow this guide, you must have:
 
@@ -49,7 +49,7 @@ A functional Teleport Terraform provider by following [the Terraform provider gu
 </TabItem>
 </Tabs>
 
-### Step 1/4 - Write manifests
+## Step 1/4 - Write manifests
 
 In this step, we'll write text files describing the resources we want in
 Teleport. Those files are called manifests and their syntax will vary based on
@@ -60,7 +60,7 @@ This allows you to keep track of all changes, follow standard code review
 procedures before changing resources in Teleport, and quickly redeploy your
 Teleport instance if needed.
 
-#### Write role manifests
+### Write role manifests
 
 We will create 2 roles:
 
@@ -103,8 +103,8 @@ spec:
 Create the following `roles.yaml` file:
 
 ```yaml
-apiVersion: resources.teleport.dev/v5
-kind: TeleportRole
+apiVersion: resources.teleport.dev/v1
+kind: TeleportRoleV7
 metadata:
   name: manager
 spec:
@@ -115,8 +115,8 @@ spec:
       - resources: ['session', 'event']
         verbs: ['list', 'read']
 ---
-apiVersion: resources.teleport.dev/v5
-kind: TeleportRole
+apiVersion: resources.teleport.dev/v1
+kind: TeleportRoleV7
 metadata:
   name: engineer
 spec:
@@ -126,11 +126,6 @@ spec:
       'env': ['test', 'staging']
 ```
 
-<Admonition type="note">
-The role version is v5 because the Teleport Kubernetes Operator doesn't support
-yet roles v6 and v7.
-</Admonition>
-
 <Admonition type="note">
   Kubernetes validates all custom resource names to follow RFC 1123, which
   includes specifications for hostnames. This requires the `metadata.name` field
@@ -187,7 +182,7 @@ resource "teleport_role" "engineer" {
 </TabItem>
 </Tabs>
 
-#### Write user manifests
+### Write user manifests
 
 We will create 2 users:
 - Bob, an engineer with the `engineer` role.
@@ -290,7 +285,7 @@ resource "teleport_user" "bob" {
 </TabItem>
 </Tabs>
 
-### Step 2/4 - Apply all manifests
+## Step 2/4 - Apply all manifests
 
 <Tabs>
 <TabItem label="tctl">
@@ -361,7 +356,7 @@ Apply complete! Resources: 4 added, 0 changed, 0 destroyed.
 </TabItem>
 </Tabs>
 
-### Step 3/4 - Validate users were created
+## Step 3/4 - Validate users were created
 
 Now that the IaC tooling has run, we'll validate that the users were properly
 created and granted the correct roles.
@@ -416,7 +411,7 @@ version: v2
 </TabItem>
 </Tabs>
 
-### Step 4/4 - Create a password reset link
+## Step 4/4 - Create a password reset link
 
 At this point, the local users have been created in Teleport. However, we never
 specified any password or additional authentications factors. You must issue a
@@ -484,7 +479,7 @@ resource "teleport_user" "bob" {
 </TabItem>
 </Tabs>
 
-### Next Steps
+## Next Steps
 
 - Allow users with the `manager` role to grant access to production servers to
   some `engineers` via Access Lists. Manager will need to justify and review

diff --git a/docs/pages/reference/user-types.mdx b/docs/pages/reference/user-types.mdx
@@ -85,7 +85,3 @@ in Okta.
 
 Those users can be identified by the label `teleport.dev/origin: okta` and
 cannot be edited via `tctl`, only deleted.
-
-<Admonition type="note" title="See also">
-Okta synchronization documentation
-</Admonition>