Docs · Your AWS

What CloudGrant can do in your AWS

The roles the connect stack creates, what each one is allowed to do, and what none of them can do.

Connecting CloudGrant to your AWS means deploying one CloudFormation stack in your management account. The stack creates roles that CloudGrant assumes from its own AWS account, each locked to your workspace with an external ID. Nothing else is installed: no agent, no Lambda, no network path into your accounts.

Every permission below is copied from the template as deployed. If the two ever differ, the template is right and this page is wrong - tell us.

The three roles in the connect stack #

The stack is called cloudgrant-access. It creates three roles, all of which trust only CloudGrant's account and only with your external ID.

CloudGrantReader #

Read-only. This is how CloudGrant lists your accounts, permission sets, Identity Center people and groups, and reads sign-in and usage history for the access review.

  • organizations:List*, organizations:Describe*
  • sso:List*, sso:Describe*, sso:Get*
  • identitystore:List*, identitystore:Describe*
  • cloudtrail:LookupEvents
  • iam:ListRoles, iam:GetRole, iam:ListRolePolicies, iam:ListAttachedRolePolicies, iam:GetRolePolicy
  • iam:ListUsers, iam:GetUser, iam:ListUserPolicies, iam:ListAttachedUserPolicies, iam:GetUserPolicy
  • iam:ListAccessKeys, iam:GetAccessKeyLastUsed
  • iam:GenerateServiceLastAccessedDetails, iam:GetServiceLastAccessedDetails
  • iam:GetPolicy, iam:GetPolicyVersion, iam:ListPolicies

CloudGrantProvisioner #

The one role that changes anything, and it can change exactly one thing: which person holds which permission set in which account.

  • sso:CreateAccountAssignment, sso:DeleteAccountAssignment
  • sso:DescribeAccountAssignmentCreationStatus, sso:DescribeAccountAssignmentDeletionStatus
  • sso:ListPermissionSets, sso:DescribePermissionSet
  • identitystore:ListUsers

Every time CloudGrant assumes this role, the session is named after the person the access is for and tagged with the request id and reason, so your own CloudTrail shows who each change was for, not just that CloudGrant did it.

CloudGrantDirectoryAdmin (optional) #

Only used if you edit permission sets, Identity Center users or groups from the CloudGrant console. If you never do, the role sits idle.

  • Permission sets: create, update, delete, attach and detach managed policies, put and delete inline policies, put and delete a permissions boundary, provision, and read provisioning status.
  • Identity Center users and groups: create, update, delete, and add or remove group memberships.
  • IAM, only on the roles Identity Center itself manages (arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*): the actions AWS needs when a permission set is pushed into the management account.

The member reader (StackSet, optional) #

Access review across member accounts needs the same read-only role in each account. That is a second template, cloudgrant-member-reader, deployed as a StackSet. It creates one CloudGrantReader role per account with the same read-only permissions as above and nothing else. No Provisioner, no DirectoryAdmin.

The direct-access role (optional, per account) #

For accounts without Identity Center, a rule can point at an IAM role instead. That is a third template, cloudgrant-broker-role, deployed per account. It creates two roles:

  • The access role, named by you and starting with CloudGrant, which is what people receive temporary keys for. Its permissions are yours to set; the template ships a read-only starting point (ec2:Describe*, s3:List*, s3:GetObject).
  • CloudGrantSessionManager, which can only put and delete an inline policy on that one access role. This is how "lock them out now" works: a deny policy on the role ends every session on it.

What none of the roles can do #

  • Create, change or delete IAM users, roles or policies outside the two exceptions above.
  • Read or write your data in any service. The reader looks at configuration and CloudTrail events, never S3 objects, databases or secrets.
  • Change the stack, the StackSet, or anything in CloudFormation. Offboarding is yours to run, by design - see Leaving CloudGrant.
  • Act without the external ID. The trust policy on every role requires it.

Updating the stack #

When a template version adds a permission, the Connect AWS page says so and shows the update command. Older stacks keep working with what they have; CloudGrant logs what it falls back to.