Connect & Integrate AWS

Last updated: May 20, 2026

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 disable IAM users (deactivate access keys, attach a deny policy) for offboarding workflows.

Steps

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).
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.
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.

Attach permissions to the role The required permissions depend on the source you chose.

For IAM Identity Center, attach a policy with these actions:

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

For IAM, attach the AWS managed policy IAMReadOnlyAccess (or grant the equivalent iam:List*, iam:Get*, and sts:GetCallerIdentity permissions).

For deactivation (offboarding) actions, additionally grant:

iam:UpdateAccessKey
iam:DeleteLoginProfile
iam:AttachUserPolicy

(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).
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.
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.

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?

If the trusted role's policy doesn't grant iam:ListRoles and iam:GetRole, YeshID skips roles. Re-attach the IAMReadOnlyAccess managed policy (or the equivalent custom permissions) and re-run the sync.

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.