AWS Identity Center (formerly known as AWS SSO): A Guide to Privilege Escalation and Identity and Access Management

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123412341234:saml-provider/AWSSSO_1111111111111111_DO_NOT_DELETE"
      },
      "Action": ["sts:AssumeRoleWithSAML", "sts:TagSession"],
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }
  ]
}

Action: `sso:ProvisionPermissionSet`

In Identity Center, [a Permission Set](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) is used to assign access to an Identity Center user or Identity Center group in one or more AWS Accounts.  These are not the same users and groups in AWS IAM (IAM Users and Groups).  When a permission set is assigned, Identity Center creates Identity Center IAM Roles in each account where the permission set corresponds to the role permissions in the corresponding AWS account.

Permission Sets are not provisioned by default when they are created (`sso:CreatePermissionSet`).  For the permissions to go into effect, `sso:ProvisionPermissionSet` must be called.  The same is required with adding permissions which is covered in the section below.

However, `sso:CreateAccountAssignment` as part of the Scope Change via Account Assignment section covered below will automatically provision permission sets as part of creating an account assignment.

There are multiple different ways of adding permissions.  Similar to attaching policies to IAM Roles and Users, the following are different methods of adding and removing policies to a permission set.

- Attaching an AWS Managed Policy

    Action: `sso:AttachManagedPolicyToPermissionSet`

    This action attaches an AWS managed policy to the Permission Set such as `AdministratorAccess`.  An AWS managed policy is a standalone IAM policy that is created and managed by AWS.  It is possible to grant more privileges via an attached managed policy.

- Attaching a Customer Managed Policy

    Action: `sso:AttachCustomerManagedPolicyReferenceToPermissionSet`

    This action attaches a customer managed policy to the Permission Set.  A customer managed policy is an IAM policy created and managed by the customer (you).  It is possible to grant more privileges via an attached managed policy.

- Adding an Inline Policy

    Action: `sso:PutInlinePolicyToPermissionSet`

    This action ties an inline policy to the permission set.  Inline policies are not standalone policies but rather are policies created for a single identity.  In this case, they’re created for Permission Sets.  It is possible to grant more privileges via an inline policy.

- Detaching an AWS Managed Policy

    Action: `sso:DetachManagedPolicyFromPermissionSet`

    This action removes the association between an AWS managed policy from the specified permission set.  It is possible to grant more privileges via detaching a managed policy (deny policy).

- Detaching a Customer Managed Policy

    Permission: `sso:DetachCustomerManagedPolicyReferenceFromPermissionSet`

    This action removes the association between a Customer managed policy from the specified permission set.  It is possible to grant more privileges via detaching a managed policy (deny policy).

- Deleting an Inline Policy

    Permission: `sso:DeleteInlinePolicyFromPermissionSet`

    This action removes the permissions from an inline policy from the permission set.  It is possible to grant more privileges via detaching an inline policy (deny policy).

- Deleting a Permission Boundary

    Permission: `sso:DeletePermissionBoundaryFromPermissionSet`

    This action removes the Permission Boundary from the permission set.  It is possible to grant more privileges by removing the restrictions on the Permission Set given from the Permission Boundary.

Action: `sso:CreateAccountAssignment`

This call assigns access to a principal for a specified AWS account using a specified permission set.  Thus, extra access scope may be granted to a principal.  For example, a user may be granted access to highly sensitive Production AWS Accounts.

Additionally, as part of the `sso:CreateAccountAssignment` call, the permission set will be automatically provisioned as part of creating an account assignment.

([https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_CreateAccountAssignment.html](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_CreateAccountAssignment.html))

Action: `identitystore:CreateGroupMembership`

Action: `sso-directory:AddMemberToGroup`

Both these actions are listed here since they both achieve the same goal.  `sso-directory:AddMemberToGroup` is a console only API call and `identitystore:CreateGroupMembership` is an API/CLI only call.

These actions creates a relationship between a member and a group since those are different IAM entities that can be assigned as part of an account assignment.  If a group has account assignments, adding a user to the group will grant that user access to the assignments given to the group (inheritance).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": ["sso-directory:AddMemberToGroup", "identitystore:CreateGroupMembership"],
      "Resource": "*"
    }
  ]
}

kind: source
spec:
  name: "aws"
  path: "cloudquery/aws"
  registry: "cloudquery"
  version: "VERSION_SOURCE_AWS"
  destinations: ["postgresql"]
  tables: ["aws_cloudtrail_events"]
  spec:
    accounts:
      - id: '123412341234'
        local_profile: 'cloudquery-view'

SELECT * from aws_cloudtrail_events
WHERE 	(event_name = 'CreateAccountAssignment'
	OR event_name = 'ProvisionPermissionSet')
	AND cloud_trail_event -> 'errorCode' IS NULL
ORDER by event_time;

SELECT * from aws_cloudtrail_events
WHERE event_name = 'AddMemberToGroup' AND
			cloud_trail_event -> 'errorCode' IS NULL
ORDER by event_time;