Connect & Integrate AWS

Introduction

This guide covers using YeshID's AWS integration to connect your AWS organization or account.

YeshID supports two source modes. Pick the one that matches how your organization manages identities:

• IAM Identity Center (recommended): modern AWS Single Sign-On. YeshID imports Identity Center users and groups plus IAM data from any account where you grant access.

• IAM: classic per-account IAM. YeshID imports IAM users, groups, and roles for the connected account.

Once connected, YeshID imports:

• AWS accounts

• IAM users, groups, and roles

• IAM Identity Center users and groups (when using the Identity Center source)

• Access keys and last-used metadata

• Managed and inline policies, and the IAM principals they grant access to

YeshID can also offboard IAM users with two actions, Deactivate User and Delete User. The permissions in the setup steps cover imports only. To offboard users, add the permissions in Deactivating and deleting IAM users.

Steps

1. Sign in to AWS. Sign in to the AWS account where you want to create the YeshID role.

   For Identity Center, sign in to the AWS account that hosts your IAM Identity Center instance (typically your organization's management or delegated administrator account).

2. Pick an External ID. Choose any unique string to use as the External ID for this integration, for example a UUID, or your company name plus a random suffix. You'll put the same value in your AWS trust policy and in the YeshID setup form. Matching the two is what proves to AWS that the assume-role call is authorized.

   Keep this value handy. You'll paste it into both AWS and YeshID in the next steps.

3. Create an IAM role in AWS. In the AWS IAM console, create a new role:

   • Trusted entity type: Custom trust policy

   • Trust policy: paste the template below, replacing <YOUR_EXTERNAL_ID> with the value you chose in step 2

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": { "AWS": "arn:aws:iam::721354940762:user/yeshid-provisioner" },
         "Action": "sts:AssumeRole",
         "Condition": {
           "StringEquals": { "sts:ExternalId": "<YOUR_EXTERNAL_ID>" }
         }
       }
     ]
   }

   The Principal ARN above is YeshID's production assume-role principal. Use it verbatim. It's the same for every customer.

   Name the role yeshid-provisioner (or anything you like) and continue to the permissions step.

4. Attach permissions to the role. For imports, create a custom permissions policy using the JSON below and attach it to the role. This policy includes IAM Identity Center and IAM read permissions.

   In the AWS IAM policy editor, select JSON and paste the following policy. This is the role's permissions policy, not the trust policy from step 3.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "VisualEditor0",
               "Effect": "Allow",
               "Action": [
                   "sso:ListInstances",
                   "sso:DescribeInstance",
                   "sso:ListPermissionSets",
                   "sso:DescribePermissionSet",
                   "sso:ListAccountAssignments",
                   "sso:ListAccountsForProvisionedPermissionSet",
                   "identitystore:DescribeUser",
                   "identitystore:DescribeGroup",
                   "identitystore:ListUsers",
                   "identitystore:ListGroups",
                   "identitystore:ListGroupMemberships",
                   "organizations:ListAccounts",
                   "organizations:DescribeAccount",
                   "sts:GetCallerIdentity",
                   "iam:ListUsers",
                   "iam:ListGroups",
                   "iam:ListRoles",
                   "iam:ListAccessKeys",
                   "iam:GetAccessKeyLastUsed",
                   "iam:GetGroup",
                   "iam:ListAttachedUserPolicies",
                   "iam:ListUserPolicies",
                   "iam:ListAttachedGroupPolicies",
                   "iam:ListGroupPolicies",
                   "iam:ListAttachedRolePolicies",
                   "iam:ListRolePolicies"
               ],
               "Resource": "*"
           }
       ]
   }

   To let YeshID deactivate or delete IAM users, add the offboarding permissions in Required permissions as well.

5. (Identity Center only) Note your Identity Store ID. In the AWS console, go to IAM Identity Center → Settings. Copy the Identity Store ID (format d-xxxxxxxxxx).

6. Connect the integration in YeshID. In YeshID, open the AWS integration and enter:

   • Source: Identity Center or IAM

   • AWS Region: the region where your trusted role / Identity Center instance lives (defaults to us-east-1)

   • Role ARN: the ARN of the role you created in step 3

   • External ID: the same string you put in the trust policy in step 3

   • Identity Store ID (Identity Center only): from step 5

   Save the integration.

7. Run a sync. Start an Import Users and Import Resources sync. YeshID assumes the trusted role via STS and pulls users, groups, roles, access keys, and policies under the connected account or Identity Center instance.

Deactivating and deleting IAM users

The AWS integration offers two offboarding actions for IAM users. Both follow AWS's guide, Remove or deactivate an IAM user. Turn them on under Actions in the AWS integration settings. When a workflow removes someone from AWS (for example the Remove user from application task during offboarding), YeshID runs whichever action is enabled.

If both actions are enabled, Delete User is used. To deactivate instead, turn off Delete User.

Deactivate User

Deactivate User is reversible and is the recommended offboarding step.

Following AWS's documented method, YeshID attaches an inline policy named YeshIDDeactivatedAccess to the user. It denies every action, so the user is blocked immediately, including any console session or temporary credentials they already hold. As a second layer, YeshID also sets the user's access keys, SSH public keys, service-specific credentials (such as CodeCommit Git credentials), and signing certificates to Inactive.

The user's password, MFA devices, policies, and group memberships are left in place, so you can review access and restore it before deciding to delete. YeshID shows the user as inactive while the policy is attached, including after later imports.

To restore access manually, remove the YeshIDDeactivatedAccess inline policy from the user in AWS and set any credentials you want back to Active.

Delete User

Delete User permanently deletes the IAM user.

AWS refuses to delete a user that still has anything attached. So YeshID first removes, in the order AWS documents:

1. The console password (login profile)

2. Access keys

3. Signing certificates

4. SSH public keys

5. Service-specific credentials

6. MFA devices

7. Inline policies (deleted)

8. Managed policy attachments (detached)

9. Group memberships

Then it deletes the user. Groups and managed policies themselves are never deleted, only detached from this user. Every removed item is recorded on the workflow run.

If a user is already partly cleaned up, or already deleted, the action still completes successfully. That makes it safe to rerun.

Identity Center users

Identity Center users support Delete User only. To deactivate an Identity Center user, disable them in the connected identity source (for example your IdP).

Required permissions

Add the following actions to the permissions policy on the role that trusts YeshID. The import permissions from step 4 are still required.

{
  "Effect": "Allow",
  "Action": [
    "iam:ListUserPolicies",
    "iam:PutUserPolicy",
    "iam:DeleteUserPolicy",
    "iam:ListAccessKeys",
    "iam:UpdateAccessKey",
    "iam:DeleteAccessKey",
    "iam:ListSSHPublicKeys",
    "iam:UpdateSSHPublicKey",
    "iam:DeleteSSHPublicKey",
    "iam:ListServiceSpecificCredentials",
    "iam:UpdateServiceSpecificCredential",
    "iam:DeleteServiceSpecificCredential",
    "iam:ListSigningCertificates",
    "iam:UpdateSigningCertificate",
    "iam:DeleteSigningCertificate",
    "iam:DeleteLoginProfile",
    "iam:ListMFADevices",
    "iam:DeactivateMFADevice",
    "iam:DeleteVirtualMFADevice",
    "iam:ListAttachedUserPolicies",
    "iam:DetachUserPolicy",
    "iam:ListGroupsForUser",
    "iam:RemoveUserFromGroup",
    "iam:DeleteUser"
  ],
  "Resource": "*"
}

Which permissions each action needs:

If a permission is missing, the workflow step fails with a message naming the exact action to add, for example the YeshID role is missing iam:PutUserPolicy. Add it to the role and rerun the step.

FAQ

Should I use Identity Center or IAM?

Use Identity Center if your organization signs into AWS through AWS SSO. That's where the canonical user identities and group memberships live. Use IAM only if you don't have Identity Center set up or you specifically need to manage per-account IAM users.

You can connect both as separate integrations if you have a hybrid setup.

How do I cover multiple AWS accounts?

For Identity Center, the management account's role can see Identity Center assignments across all accounts. One role is enough.

For IAM, you need a trusted role in each account you want YeshID to inspect. Use the same trust policy template (same source ARN, same External ID) in each account. YeshID assumes each role separately and aggregates the results.

Why is the External ID required?

The External ID is AWS's recommended defense against the "confused deputy" problem when granting cross-account access to a third party. You pick any string and use the same value in both your AWS trust policy and the YeshID setup form. AWS only allows the assume-role call to succeed when the two match, which prevents another YeshID customer from accidentally (or maliciously) assuming your role.

Treat the External ID like a shared secret: pick something unguessable (a UUID is a good default) and don't reuse it across integrations.

Can I use an IAM user instead of a role?

No. Cross-account access from YeshID's side is implemented via sts:AssumeRole, so your AWS side must be a role with a trust policy, not a user with an access key.

What region should I pick?

us-east-1 works for almost everyone. Pick a different region only if your Identity Center instance lives elsewhere or if your trust policy enforces a regional STS endpoint. The region affects STS and Identity Center API calls; IAM is global and works regardless.

Why are some IAM roles missing after a sync?

The connector retrieves IAM roles with iam:ListRoles and reads their policy grants with iam:ListAttachedRolePolicies and iam:ListRolePolicies. It does not call iam:GetRole.

Confirm that the trusted role can perform the actions in the permissions policy in step 4, then re-run the sync. During resource imports, accounts with permission-denied errors may be skipped; if access is denied for every discovered account, the import returns an error.

What happens if my sync hits a rate limit?

YeshID backs off and retries on AWS throttling responses, honoring the SDK's standard retry behavior with jittered backoff. Large IAM imports may take a little longer when AWS throttles, but they will complete.

Does the role need to be in a specific account?

For Identity Center: the role should live in the AWS account that owns your Identity Center instance (typically the management or delegated administrator account).

For IAM: the role can live in any account, but YeshID will only see IAM data for the account that role belongs to. Connect multiple accounts as separate integrations or grant the role permissions in each account you want imported.

Delete User used to fail with "must remove users from group first" or "must delete login profile first". Is that fixed?

Yes. Delete User now removes everything AWS requires before deleting the user, so it no longer stops on each blocker one at a time. Make sure the role has the permissions in Required permissions, then rerun the failed step.

A Delete User run failed partway through. Is the user in a broken state?

No. If the role is missing some permissions, YeshID removes what it can and stops at the first denied call, naming the missing permission. Add that permission and rerun the step. YeshID picks up where it left off.

Should I enable Deactivate User, Delete User, or both?

Start with Deactivate User. It cuts off access immediately but keeps the user and their configuration, so nothing is lost if someone was offboarded by mistake or you need to review their access first. Enable Delete User when you want offboarding to remove the IAM user permanently. If both are enabled, Delete User runs.