AWS

Trustle connects to your AWS environment using a secure, credential-free integration. Instead of sharing static access keys, you create an IAM role in your AWS account that grants Trustle temporary, short-lived access. Trustle assumes this role using cross-account role assumption, a standard AWS security pattern, so no long-lived credentials are ever exchanged or stored.

Prerequisites

• Administrative access to your AWS account, with IAM permissions to create and modify roles, users, and policies.
• Your AWS account ID, a 12-digit number.
• Your account’s primary AWS region.
• The Trustle Bridge Role ARN and External ID, which Trustle provides. The trust relationship uses these values.

Configure AWS

Step 1: Gather Your AWS Organization Information

Trustle needs to understand your AWS account structure to provide comprehensive analysis.

1. Sign in to the AWS Management Console with your administrative account.

2. Note your AWS account ID. Click your account name in the upper right corner to find it, or run:

   aws sts get-caller-identity --query Account --output text

3. Open AWS Organizations in the console.

   • If you see “This account is not currently a member of an organization,” you have a single-account setup.
   • If you see an organizational structure, note your Organization ID. It starts with o-, for example o-abc1234567.
   • Perform all setup steps from the management account if you use AWS Organizations.

4. Open AWS IAM Identity Center (formerly AWS SSO) to check your Identity Center configuration, if you use one.

   • If enabled, note the Identity Center instance ARN shown in the upper left corner. It looks like ssoins-1234….
   • Note the region where Identity Center is deployed.
   • Note whether you use an external identity provider, such as Active Directory.

Note

Trustle uses this information to understand your AWS environment structure and to ensure it covers all accounts and access methods in your organization.

Step 2: Create and Attach the Required IAM Policy

This step creates the specific permissions Trustle needs to analyze your AWS environment and automate IAM. All permissions are scoped to the minimum required for each capability.

1. In the IAM console, click Policies in the left sidebar, then click Create policy.
2. Click the JSON tab and replace the default policy with the following:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TrustleReadAccess",
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:ListAgentRuntimes",
        "bedrock-agentcore:ListWorkloadIdentities",
        "cloudtrail:LookupEvents",
        "iam:GetAccessKeyLastUsed",
        "iam:GetGroup",
        "iam:GetLoginProfile",
        "iam:GetPolicy",
        "iam:GetPolicyVersion",
        "iam:GetUser",
        "iam:GetUserPolicy",
        "iam:ListAccessKeys",
        "iam:ListAccountAliases",
        "iam:ListAttachedGroupPolicies",
        "iam:ListAttachedUserPolicies",
        "iam:ListGroupPolicies",
        "iam:ListGroups",
        "iam:ListGroupsForUser",
        "iam:ListMFADevices",
        "iam:ListPolicies",
        "iam:ListPolicyVersions",
        "iam:ListRoles",
        "iam:ListSSHPublicKeys",
        "iam:ListServiceSpecificCredentials",
        "iam:ListSigningCertificates",
        "iam:ListUserPolicies",
        "iam:ListUsers",
        "identitystore:DescribeGroup",
        "identitystore:DescribeGroupMembership",
        "identitystore:DescribeUser",
        "identitystore:GetGroupId",
        "identitystore:GetGroupMembershipId",
        "identitystore:GetUserId",
        "identitystore:IsMemberInGroups",
        "identitystore:ListGroupMemberships",
        "identitystore:ListGroupMembershipsForMember",
        "identitystore:ListGroups",
        "identitystore:ListUsers",
        "organizations:DescribeAccount",
        "organizations:DescribeOrganization",
        "organizations:ListAccounts",
        "organizations:ListAccountsForParent",
        "organizations:ListOrganizationalUnitsForParent",
        "organizations:ListRoots",
        "sso:DescribeAccountAssignmentCreationStatus",
        "sso:DescribeAccountAssignmentDeletionStatus",
        "sso:DescribePermissionSet",
        "sso:GetInlinePolicyForPermissionSet",
        "sso:ListAccountAssignments",
        "sso:ListAccountsForProvisionedPermissionSet",
        "sso:ListInstances",
        "sso:ListManagedPoliciesInPermissionSet",
        "sso:ListPermissionSets",
        "sso:ListPermissionSetsProvisionedToAccount",
        "sso:ListAccountAssignmentsForPrincipal"
      ],
      "Resource": "*"
    },
    {
      "Sid": "TrustleProvisionAccess",
      "Effect": "Allow",
      "Action": [
        "iam:AttachUserPolicy",
        "iam:AddUserToGroup",
        "iam:CreateUser",
        "iam:DeactivateMFADevice",
        "iam:DeleteAccessKey",
        "iam:DeleteLoginProfile",
        "iam:DeleteSSHPublicKey",
        "iam:DeleteServiceSpecificCredential",
        "iam:DeleteSigningCertificate",
        "iam:DeleteUser",
        "iam:DeleteUserPolicy",
        "iam:DetachUserPolicy",
        "iam:RemoveUserFromGroup",
        "iam:TagUser",
        "identitystore:CreateGroup",
        "identitystore:CreateGroupMembership",
        "identitystore:DeleteGroup",
        "identitystore:DeleteGroupMembership",
        "identitystore:DeleteUser",
        "sso:CreateAccountAssignment",
        "sso:DeleteAccountAssignment"
      ],
      "Resource": "*"
    },
    {
      "Sid": "TrustleManagementAccountSSOProvisioning",
      "Effect": "Allow",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:DeleteRolePolicy",
        "iam:DetachRolePolicy",
        "iam:PutRolePolicy",
        "iam:UpdateAssumeRolePolicy",
        "iam:UpdateRole",
        "iam:UpdateRoleDescription"
      ],
      "Resource": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*"
    },
    {
      "Sid": "TrustleAccessToSSOProvisionedRoles",
      "Effect": "Allow",
      "Action": [
        "iam:GetRole",
        "iam:ListAttachedRolePolicies",
        "iam:ListRolePolicies"
      ],
      "Resource": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*"
    },
    {
      "Sid": "TrustleSAMLProviderAccess",
      "Effect": "Allow",
      "Action": [
        "iam:GetSAMLProvider"
      ],
      "Resource": "arn:aws:iam::*:saml-provider/*"
    },
    {
      "Sid": "TrustleAssumeRoleInMemberAccounts",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::*:role/OrganizationAccountAccessRole"
    }
  ]
}

1. Click Next.
2. Set the policy name to TrustleIntegrationPermissions.
3. Set the description to Permissions for Trustle integration access.
4. Add tags if your organization requires them.
5. Click Create policy.

The table below explains why Trustle needs each permission statement.

Policy Statement	Purpose	Why It’s Needed
TrustleReadAccess	Read-only discovery and audit	Trustle reads your IAM users, groups, roles, and policies to build a complete picture of who has access to what. It reads Identity Center (SSO) resources to cover modern SSO-based access, and Organizations data to understand your multi-account structure. It uses CloudTrail to analyze which permissions are actually used — this is how Trustle identifies over-privileged users and unused permissions. Credential metadata (MFA, access keys, SSH keys) helps identify security risks like dormant accounts or missing MFA.
TrustleProvisionAccess	User lifecycle management	When you use Trustle to grant or revoke access, these permissions let Trustle create and remove users, manage group memberships, and assign or unassign SSO account permissions. The deprovisioning permissions (delete access keys, MFA devices, SSH keys, signing certs, inline policies) ensure that when a user is offboarded, Trustle revokes all of the user’s credentials and access, not only the user account.
TrustleAccessToSSOProvisionedRoles	Inspect SSO-managed roles	Trustle needs to read the roles that AWS Identity Center automatically provisions in your accounts, to understand the full permission chain from SSO assignments through to IAM. These are scoped strictly to aws-reserved/sso.amazonaws.com/* roles managed by AWS — Trustle cannot read your custom roles through this statement.
TrustleSAMLProviderAccess	Read SSO SAML configuration	Trustle reads the SAML provider configuration created by AWS Identity Center to understand how SSO authentication is set up. This is read-only and scoped to SAML provider resources.
TrustleAssumeRoleInMemberAccounts	Cross-account visibility	If you have an AWS Organization, Trustle needs to assume a role in each member account to discover IAM resources across your entire organization. AWS automatically creates OrganizationAccountAccessRole in every member account when it joins the Organization. If your organization uses a different cross-account role name, update the resource ARN accordingly.

Note

If you do not use AWS Organizations (single-account setup), you can remove the TrustleAssumeRoleInMemberAccounts statement. If you do not use AWS Identity Center, you can remove the identitystore:*, sso:*, TrustleAccessToSSOProvisionedRoles, and TrustleSAMLProviderAccess statements. If you keep them, they have no effect. Trustle does not use them.

Step 3: Create the IAM Role with Trust Relationship

This step creates the IAM role that Trustle assumes to access your environment. The trust relationship ensures that only Trustle’s infrastructure can assume this role, and the External ID prevents unauthorized access.

Trustle provides you with:

• Trustle Bridge Role ARN — the specific role in Trustle’s infrastructure that assumes your role.
• External ID — a unique identifier for your organization that adds an extra layer of security.

1. In the IAM console, click Roles in the left sidebar, then click Create role.
2. For Trusted entity type, select Custom trust policy.
3. In the trust policy editor, paste the following JSON:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "<TRUSTLE_BRIDGE_ROLE_ARN>"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "<EXTERNAL_ID>"
        }
      }
    }
  ]
}

1. Replace <TRUSTLE_BRIDGE_ROLE_ARN> with the Bridge Role ARN Trustle provided.
2. Replace <EXTERNAL_ID> with the External ID Trustle provided.
3. Click Next.
4. In the search box, type TrustleIntegrationPermissions.
5. Check the box next to the policy you created in the previous step, then click Next.
6. Set the role name to TrustleIntegration.
7. Set the description to Trustle integration access via cross-account role assumption.
8. For Maximum session duration, select 1 hour.
9. Review the configuration and click Create role.
10. After creation, click the role name to view its details.
11. Copy the ARN at the top of the page. It has the format arn:aws:iam::<your-account-id>:role/TrustleIntegration. You provide this to Trustle.

The trust relationship you created lets Trustle’s infrastructure temporarily assume the TrustleIntegration role in your account. This is secure because:

• No static credentials: Trustle never receives or stores long-lived access keys. All access uses temporary credentials that expire after 1 hour.
• External ID protection: The External ID condition prevents the “confused deputy” problem — only requests that include your specific External ID can assume the role.
• Scoped principal: Only Trustle’s specific bridge role can assume your role. No other AWS account or entity can use it.
• Full auditability: Every API call Trustle makes is logged in your AWS CloudTrail, giving you complete visibility into what Trustle accesses.

Connect in Trustle

Once setup is complete, provide the following to Trustle:

• AWS Account ID — your 12-digit account number.
• Role ARN — the ARN of the TrustleIntegration role, for example arn:aws:iam::123456789012:role/TrustleIntegration.
• Region — the AWS region where Identity Center is deployed, for example us-west-2.

After you provide this information, Trustle:

1. Validates that it can assume the role and access your environment.
2. Imports group memberships, role assignments, and permission data for all accounts.
3. Analyzes recent activity via CloudTrail and identifies unused permissions, over-privileged users, and dormant accounts.
4. Populates the IAM dashboard with findings and recommendations.
5. Runs periodic imports and analysis to surface changes in access patterns.

Verify

Before sharing the role details with Trustle, verify that everything is configured correctly.

1. In IAM > Roles, search for TrustleIntegration and confirm the role is listed.
2. Click the role, then the Trust relationships tab. Verify that the Principal matches the Trustle Bridge Role ARN and that the External ID condition is present.
3. Click the Permissions tab. Verify that TrustleIntegrationPermissions is attached. Click the policy to confirm it contains the expected permissions.
4. In the role summary, verify that Maximum session duration is set to 1 hour.

You can also verify the role with the AWS CLI:

# Verify the role exists and check trust policy
aws iam get-role --role-name "TrustleIntegration"

# Verify permissions are attached
aws iam list-role-policies --role-name "TrustleIntegration"

Security notes

Note

Aspect	Detail
Credential type	Temporary (short-lived STS credentials, 1-hour maximum)
Static keys stored	None — no access keys or secrets are ever exchanged
Access scope	Limited to the permissions in TrustleIntegrationPermissions
Cross-account protection	External ID prevents confused deputy attacks
Audit trail	All Trustle API calls appear in your CloudTrail logs
Revocation	Delete the TrustleIntegration role to immediately revoke all access
:::

Troubleshooting

• “Access Denied” during Trustle validation: Verify the trust relationship includes the correct Trustle Bridge Role ARN and External ID. Check that TrustleIntegrationPermissions is attached to the role.
• Organizations data not visible: Ensure you created the role in the management account, not a member account.
• Identity Center data not visible: Confirm Identity Center is enabled and that the role has the sso:* and identitystore:* permissions.
• Member accounts not discovered: Verify the TrustleAssumeRoleInMemberAccounts statement is present and that OrganizationAccountAccessRole exists in your member accounts. AWS creates this automatically when accounts join an Organization.

Contact the Trustle technical support team with specific error messages. Provide your AWS Account ID and Role ARN for faster troubleshooting.