From f44f25e907c85f08f0b9809cbc6ef95182ab4a98 Mon Sep 17 00:00:00 2001 From: Roman Tkachenko Date: Thu, 14 Nov 2024 14:46:33 -0800 Subject: [PATCH] Add more words --- .../guides/aws-iam-identity-center.mdx | 114 ++++++++++++++---- docs/pages/includes/role-spec.mdx | 9 ++ 2 files changed, 102 insertions(+), 21 deletions(-) diff --git a/docs/pages/admin-guides/management/guides/aws-iam-identity-center.mdx b/docs/pages/admin-guides/management/guides/aws-iam-identity-center.mdx index 612644da400a9..09f7c98c63405 100644 --- a/docs/pages/admin-guides/management/guides/aws-iam-identity-center.mdx +++ b/docs/pages/admin-guides/management/guides/aws-iam-identity-center.mdx @@ -8,23 +8,23 @@ allows you to organize and manage your users' short- and long-term access to AWS accounts and their permissions. With the Identity Center integration you can grant or revoke persistent access -to AWS accounts and resources using Teleport access lists, or use Teleport -access requests for scenarios requiring temporary elevated AWS privileges. +to AWS accounts and resources using Teleport Access Lists, or use Teleport +Access Requests for scenarios requiring temporary elevated AWS privileges. ## How it works Identity Center integration builds on top of Teleport's [role-based access controls](../../access-controls/guides/guides), -[just-in-time access requests](../../access-controls/access-requests/access-requests/) -and [access lists](../../access-controls/access-lists/access-lists/). +[just-in-time Access Requests](../../access-controls/access-requests/access-requests/) +and [Access Lists](../../access-controls/access-lists/access-lists/). When enabled, Teleport takes ownership over Identity Center users, groups, and permission set assignments: - All Identity Center groups, along with their members and account/permission - assignments, are imported into Teleport as access lists. + assignments, are imported into Teleport as Access Lists. - Identity Center account/permission assignments are expressed as Teleport role policies. -- Changes made to Teleport users or access lists with Identity Center assigned +- Changes made to Teleport users or Access Lists with Identity Center assigned permissions are reflected in the Identity Center. @@ -40,20 +40,20 @@ in Teleport or, if you're using Okta, turn on For managing long-term access, Teleport cluster administrators can designate -Identity Center-synced access lists owners who will be responsible for adding +Identity Center-synced Access Lists owners who will be responsible for adding or removing users and performing periodic access reviews. Users added to or removed from such access lists will be added to or removed from corresponding Identity Center groups. -For short-term access, users can go through Teleport's standard access request +For short-term access, users can go through Teleport's standard Access Request flow in which case Teleport will assign requested privileges to a particular -user and automatically unassign once the access request expires. +user and automatically unassign once the Access Request expires. The preview release of Teleport's Identity Center integration in Teleport 17.0 -supports role access requests only. +supports role Access Requests only. -Resource access requests (ability to request access to a particular permission +Resource Access Requests (ability to request access to a particular permission set in a particular account or a particular resource) will be added in follow up releases. @@ -117,7 +117,7 @@ permission sets that Teleport was able to find in your Identity Center. //screenshot -Pick the default owners that should be assigned to the access lists in Teleport. +Pick the default owners that should be assigned to the Access Lists in Teleport. These resources will be imported into Teleport once you click Next. ## Step 3/5. Configure identity source @@ -145,7 +145,7 @@ allow Teleport to push user and group changes. ## Step 5/5. Verify the integration -Once the integration has been setup, navigate to the access lists view page +Once the integration has been setup, navigate to the Access Lists view page in your cluster and make sure that all your Identity Center groups have been imported: @@ -155,29 +155,101 @@ been imported: It may take a few minutes for the initial sync to complete. -Imported access lists should show the same members as their corresponding +Imported Access Lists should show the same members as their corresponding Identity Center groups. ## Usage scenarios -### Managing long-term access with access lists +### Managing access with Access Lists -XXX +Teleport creates an Access List for each group found in the Identity Center, +with group members becoming Access List members. Default Access List owners are +configured during the initial integration enrollment flow and can be adjusted +as necessary after the initial sync completes. -### Using role access requests +Each imported Access List is automatically assigned a role (or a set of roles) +that grant all members of that list access to a particular permission set on a +particular AWS account based on the permissions the corresponding Identity Center +group was assigned during the integration setup. Those roles are considered +system roles generated by Teleport and are named using `-on-` +convention (e.g. `AdministratorAccess-on-my-account`). -XXX +To give a user permission granted by an already-existing Identity Center synced +Access List, an owner can add that user as a member which makes Teleport to add +the user to its corresponding Identity Center group. + + +While the integration is running, all existing Teleport users are synced to +Identity Center. + + +Removing a member from an Identity Center synced Access List removes them +from the corresponding Identity Center group effectively revoking privileges. + +In addition to membership changes, Teleport propagates changes in Access List +grants to Identity Center as well. In a scenario where, say, for an Access List +with roles `AdministratorAccess-on-my-account` and `ReadOnlyAccess-on-my-account` +one of the granted roles were to be removed, the corresponding Identity Center +group would see its assignments updated accordingly. + +### Using role Access Requests + +For short-term privilege elevation, Identity Center integration works with +Teleport Access Requests. + +When an Access Request for a role granting Identity Center privileges is +approved, Teleport creates an individual assignment for that user in the +Identity Center. The assignment is deleted when the Access Request expires. + + +In a future version, Teleport will support requesting access to individual +permission sets using resource-based Access Request flow similar to other +Teleport resources. + ### Creating custom Identity Center roles -XXX +You can craft your own roles that bind Identity Center accounts to permission +sets, for example: + +```yaml +kind: role +version: v7 +metadata: + name: aws-dev-access +spec: + allow: + account_assignments: + - account: "" # AWS identity center account ID + name: AdministratorAccess # name of the permission set in AWS + permission_set: arn:aws:sso:::permissionSet/ssoins-1234/ps-5678 # permission set ARN + - account: "" + name: ReadOnlyAccess + permission_set: arn:aws:sso:::permissionSet/ssoins-1234/ps-8765 +``` + +These roles can be assigned to users and Access Lists or requested by users +using Access Requests flow described above. + +## Reference & FAQ + +### Which Access Lists are synced to Identity Center? + +Teleport syncs all Access Lists that have AWS account and permission set rules +among their role grants to Identity Center. + +### How does it work with nested Access Lists? + +Identity Center does not support nested groups. As such, Teleport flattens out +the member list when syncing an Access List that has +[nested Access Lists](../../access-controls/access-lists/nested-access-lists/). ## Next steps - Take a deeper dive into fundamental Teleport concepts used in Identity Center integration such as [RBAC](../../access-controls/guides/guides), - [JIT access requests](../../access-controls/access-requests/access-requests/) - and [access lists](../../access-controls/access-lists/access-lists/). + [JIT Access Requests](../../access-controls/access-requests/access-requests/) + and [Access Lists](../../access-controls/access-lists/access-lists/). - Learn how to enable [Okta integration](../../../enroll-resources/application-access/okta/hosted-guide/) to sync apps, users and groups from Okta in conjunction with Identity Center integration. diff --git a/docs/pages/includes/role-spec.mdx b/docs/pages/includes/role-spec.mdx index caa60ae7e2503..25c566f3fae0e 100644 --- a/docs/pages/includes/role-spec.mdx +++ b/docs/pages/includes/role-spec.mdx @@ -319,6 +319,15 @@ spec: - 'arn:aws:iam::1234567890:role/ec2-full-access' - 'arn:aws:iam::0987654321:role/example-role' + # AWS account and permission set bindings for the Identity Center integration + account_assignments: + - # AWS identity center account ID + account: "" + # name of the permission set in AWS + name: AdministratorAccess + # permission set ARN + permission_set: arn:aws:sso:::permissionSet/ssoins-1234/ps-5678 # permission set ARN + # impersonate allows a user with this role to issue certificates on behalf # of other users and roles matching expressions below impersonate: