Connecting AWS

Create the Trustle service account that automates JIT for entitlements through the AWS APIs

Overview

AWS suggests using a dedicated service account for Trustle to securely access your AWS environment. The service account operates entirely within your AWS infrastructure and provides Trustle with the permissions needed to analyze entitlements, identify over-privileged users, and streamline access management across your organization.

What you'll need:
  • Administrative access to your AWS account (IAM permissions to modify users and policies)
  • To create a Trustle service account and copy its Service Account Access Key ID and Secret Access Key
  • Your Account’s primary AWS region

Step 1: Gather Your AWS Organization Information

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

Instructions:

  1. Sign in to AWS Management Console
  2. Check for AWS Organizations (Multi-Account Setup)
    • Navigate to the AWS Organizations service 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 organizational structure:
      • Note your Organization ID (starts with "o-", e.g., o-abc1234567)
  3. Identify Your Identity Center Configuration (if applicable)
    • Navigate to AWS IAM Identity Center (formerly AWS SSO)
    • If enabled, note:
      • Your Identity Center instance ARN in the upper left corner (it looks like “ssoins-1234…”)
      • Whether you're using an external identity provider (Active Directory, etc.)

Why Trustle needs this: This information helps Trustle understand your AWS environment structure and ensures Trustle covers all accounts and access methods in your organization.

Step 2: Create the Dedicated Service Account

You'll create a service account specifically for Trustle that operates with the minimum necessary permissions.

Instructions:

  1. Navigate to IAM in AWS Console
    • Go to the IAM service in your AWS Management Console
    • Click on "Users" in the left sidebar
  2. Create New User
    • Click "Create user"
    • User name: [YourCompany]-Trustle-Service (or similar descriptive name)
    • Select "Programmatic access" (Trustle needs API credentials, not console access). You may see this option after you create the user.
    • Do NOT select "AWS Management Console access"
  3. Skip Group Assignment
    • Click "Next" without adding the user to any existing groups
    • You'll attach a custom policy in the next step
  4. Create and Download Access Keys
    • After user creation, go to the user's "Security credentials" tab
    • Click "Create access key"
    • Select "Application running outside AWS"
    • Add description tag: "Trustle Integration"
    • Important: Download the CSV file containing the Access Key ID and Secret Access Key
    • Store these credentials securely - you'll enter them into the Trustle UI

Security Note: These credentials provide access to your AWS environment. Never share them through unsecured channels.

Step 3: Create and Attach the Required IAM Policy

This step creates the specific permissions Trustle needs to analyze your AWS environment and automate IAM.

Instructions:

  1. Navigate to IAM Policies
    • In the IAM console, click "Policies" in the left sidebar
    • Click "Create policy"
  2. Use JSON Policy Editor
    • Click the "JSON" tab
    • Replace the default policy with the following:

{

  "Version": "2012-10-17",

  "Statement": [

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Sid": "TrustleReadAccess",

      "Effect": "Allow",

      "Action": [

        "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. Name and Create the Policy
    • Click "Next"
    • Policy name: Trustle-IAM
    • Description: IAM permissions for Trustle integration
    • Add tags if required by your organization
    • Click "Create policy"

Why Trustle Needs Each Permission

Policy StatementPurposeWhy It's Needed
TrustleReadAccessRead-only discovery and auditTrustle 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. It reads Organizations data to understand your multi-account structure. It uses CloudTrail to analyze which permissions are actually being 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.
TrustleProvisionAccessUser lifecycle managementWhen you use Trustle to grant or revoke access, these permissions allow Trustle to create/remove users, manage group memberships, and assign/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, all their credentials and access are fully revoked -- not just the user account.
TrustleAccessToSSOProvisionedRolesInspect SSO-managed rolesTrustle 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.
TrustleSAMLProviderAccessRead SSO SAML configurationTrustle 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.
TrustleAssumeRoleInMemberAccountsCross-account visibilityIf you have an AWS Organization, Trustle needs to assume a role in each member account to discover IAM resources across your entire organization. The OrganizationAccountAccessRole is automatically created by AWS 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. However, keeping them has no impact -- they simply won't be used.

Step 3: Create the IAM Role with Trust Relationship

This step creates the IAM role that Trustle will assume 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 will provide you with:

  • Trustle Bridge Role ARN -- the specific role in Trustle's infrastructure that will assume your role
  • External ID -- a unique identifier for your organization that adds an extra layer of security


Instructions:

  1. Navigate to IAM Roles

  • In the IAM console, click "Roles" in the left sidebar
  • Click "Create role"

  1. Configure Trust Policy

  • For "Trusted entity type", select Custom trust policy
  • 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>"

        }

      }

    }

  ]

}

  • Replace <TRUSTLE_BRIDGE_ROLE_ARN> with the Bridge Role ARN provided by Trustle
  • Replace <EXTERNAL_ID> with the External ID provided by Trustle
  • Click "Next"

  1. Attach Permissions Policy
  • In the search box, type TrustleIntegrationPermissions
  • Check the box next to the policy you created in Step 2
  • Click "Next"

  1. Name and Create the Role
  • Role name: TrustleIntegration
  • Description: Trustle integration access via cross-account role assumption
  • Maximum session duration: select 1 hour
  • Review the configuration and click "Create role"

  1. Copy the Role ARN
  • After creation, click on the role name to view details
  • Copy the ARN at the top of the page (format: arn:aws:iam::<your-account-id>:role/TrustleIntegration)
  • You will provide this to Trustle

How This Works

The trust relationship you created allows Trustle's infrastructure to temporarily assume the TrustleIntegration role in your account. Here's what makes this secure:

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

Step 4: Verify the Configuration (Optional)

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

Instructions:

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

Step 5: Provide Information to 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 (e.g., arn:aws:iam::123456789012:role/TrustleIntegration)

What Happens Next:

  1. Validation: Trustle verifies it can assume the role and access your environment
  2. Initial Discovery: Trustle imports group memberships, role assignments, and permission data for all accounts
  3. Activity Analysis: Analyzes recent activity via CloudTrail and identifies unused permissions, over-privileged users, and dormant accounts
  4. Dashboard Population: The IAM dashboard populates with findings and recommendations
  5. Ongoing Monitoring: Periodic imports and analysis surface any changes in access patterns

Security Summary

AspectDetail
Credential typeTemporary (short-lived STS credentials, 1-hour maximum)
Static keys storedNone -- no access keys or secrets are ever exchanged
Access scopeLimited to the permissions in TrustleIntegrationPermissions
Cross-account protectionExternal ID prevents confused deputy attacks
Audit trailAll Trustle API calls appear in your CloudTrail logs
RevocationDelete the TrustleIntegration role to immediately revoke all access

Troubleshooting

Common Issues:

  • "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 (this is created automatically by AWS when accounts join an Organization).

Getting Help:

  • Contact the Trustle technical support team with specific error messages
  • Provide your AWS Account ID and Role ARN for faster troubleshooting
  1. Trustle Bridge Role ARN -- the specific role in Trustle's infrastructure that will assume your role
  2. External ID -- a unique identifier for your organization that adds an extra layer of security

Matthew Hathaway