Capabilities
The AWS connector supports automatic account provisioning and deprovisioning of IAM accounts.
*The connector can provision to accounts via permissions sets only if Identity Center is enabled.
**Sparse ACL resources are opt-in — see Sparse ACLs: Organizations and permission sets as scoped bindings below.
This connector can sync secrets and display them on the Inventory page.
This connector syncs non-human identities and displays them on the Identities overview dashboard.
AWS STS web identity action
The connector exposes the globalassume_role_with_web_identity action for
approved, short-lived AWS credential vending. C1 supplies a request-scoped OIDC
token and age encryption recipient. The connector exchanges the token with AWS
STS, encrypts the returned credential envelope before it crosses the connector
boundary, and returns ciphertext plus expiration and assumed-role audit
metadata.
The action accepts:
role_arn: the target customer IAM role;web_identity_token: a short-lived C1-issued OIDC token;age_recipient: the request-scoped public encryption recipient;session_name: the AWS audit/session name;duration_seconds: 900 through 43,200, also limited by the IAM role; andpolicy_json: an optional restrictive inline session policy.
sts:AssumeRoleWithWebIdentity. Restrict the trust
policy to the documented C1 issuer, intended audience, and tenant/requestor
subject profile. Do not use a wildcard issuer, audience, or subject. The role’s
permissions policy defines the maximum AWS access; the optional session policy
can only narrow it further.
Synced IAM role profiles include aws_max_session_duration_seconds, the
provider-observed MaxSessionDuration ceiling returned by IAM. C1 must combine
that ceiling with its own access policy when choosing duration_seconds. AWS
does not expose an authoritative role property that says whether a future
session will be issued directly or through role chaining; C1 must derive that
topology from its configured issuance mode and apply the corresponding AWS
limit.
Sparse ACLs: Organizations and permission sets as scoped bindings
When both Enable support for AWS Organizations and Enable support for AWS IAM Identity Center are turned on, the connector also models Identity Center permission set assignments as Sparse ACL bindings, alongside the existing flat per-account entitlement model. This introduces four resource types:- Organization Root and Organizational Unit — the AWS Organizations hierarchy (Root → OU → Account), synced as read-only navigation/review context. Neither carries bindings of its own.
- Permission Set — a role catalog entry for each Identity Center permission set.
- Permission Set Assignment — one binding per (permission set, account) pair that’s actually assigned, listing the users and groups granted that permission set on that account. Group grants expand to their members.
organizations:ListRoots and organizations:ListOrganizationalUnitsForParent permissions (see the IAM policy in the Identity Center setup tab below). If these permissions are missing, the connector logs a warning and skips the OU hierarchy rather than failing the sync — accounts continue to sync without OU grouping.
IAM policies as resources
The connector syncs AWS IAM policies as resources in their own right, alongside the identities they’re attached to:- IAM managed policies — both customer-managed and AWS-managed policies. AWS-managed policies (
arn:aws:iam::aws:policy/...) are global objects shared by every account, so they’re synced once rather than per account. - Inline policies — policies embedded directly in an IAM user, role, or group, and the inline policy attached to an Identity Center permission set.
iam:GetPolicy, iam:GetPolicyVersion, and the iam:Get*Policy / iam:List*Policies actions). If these permissions are missing, the connector logs a warning and syncs the policy resources without their document contents rather than failing the sync — so a policy that appears with no document is usually a missing-permission symptom rather than an empty policy.
IAM user last login and access key activity
For an IAM user, Last Login is the most recent of password-based AWS sign-in (PasswordLastUsed) and access-key use. Password sign-in includes the AWS Management Console and can also include other AWS websites, such as AWS Marketplace. The two signals stay separate on the profile so reviewers can tell a console sign-in apart from programmatic key activity.
password_last_used— the password-based AWS sign-in timestamp.access_key_last_used— the most recent use across all of the user’s access keys.
access_key_last_used requires iam:ListAccessKeys and iam:GetAccessKeyLastUsed; it does not require Sync secrets.
When AWS returns neither PasswordLastUsed nor any access-key last-used date, C1 leaves Last Login unset. A missing password date does not mean the user has no console password; use console_access_enabled for that distinction.
Per-key detail lives on the access key itself, on the Inventory page:
- Last used, together with
last_used_serviceandlast_used_region— what the key was calling and from where. For a key with no tracked use, AWS returns a null date and"N/A"placeholders; the connector omits those values. - Status — Active or Inactive. Inactive keys were already synced; they now carry a disabled status so reviewers can tell them apart from active keys. Inactive keys can be reactivated; reviewers decide whether to delete them.
- Sync secrets — without it no access keys are synced, so none of the per-key detail above appears.
- Sync IAM User Console Access (
BATON_SYNC_IAM_USER_CONSOLE_ACCESS) — without itconsole_access_enabled,password_reset_required, andlogin_profile_created_atare not populated. It is off by default because it costs oneiam:GetLoginProfilecall per IAM user and requiresiam:GetLoginProfileon the connector role. This setting detects an IAM console password; it does not detect access through Identity Center or an assumed role.
BATON_SYNC_SSO_USER_LAST_LOGIN), and grant cloudtrail:LookupEvents to report Identity Center sign-ins. This setting is also off by default and does not affect IAM user Last Login or access key activity.
Gather AWS credentials
Configuring the connector requires you to pass in credentials generated in AWS. Gather these credentials before you move on. Follow the relevant set of instructions below to set up the AWS connector for IAM or SSO, as your configuration dictates.- IAM setup
- Identity Center setup
IAM setup: Gather credentials that support syncing child account data
To sync IAM data (like users, roles, and groups) from multiple AWS child accounts, C1 uses a secure, read-only mechanism called cross-account access. This setup works by allowing a central role in your root account to temporarily assume a specific role in each child account. This method ensures that the connector can gather the necessary data without storing credentials or requiring permanent access.If you’re using this setup, make sure to click Enable support for AWS Organizations when setting up the connector in the C1 web UI. You may also enable Enable support for AWS IAM Identity Center at the same time. By default, enabling Identity Center alongside Organizations syncs only Identity Center data (users, groups, permission sets, account assignments) and skips cross-account IAM. To also sync IAM users, roles, and groups from every child account in this combined mode, additionally enable Also sync cross-account IAM when Identity Center is enabled. This flag is off by default so existing Identity Center deployments don’t suddenly require child-accountsts:AssumeRole access.In order to use the connector to gather IAM AWS data, you’ll need to configure each sub-account to have a role with a trust policy. There are two options here:- Use
OrganizationAccountAccessRole, and add the following to the management role:{ "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::*:role/OrganizationAccountAccessRole" } - Create a new custom role by following the steps below
Get a C1-provided External ID
AWS requires the use of External IDs when granting third-party access to your AWS account. This security measure prevents the “confused deputy” problem and ensures that only authorized parties can assume the role.1
In C1, navigate to Apps > Connectors and click Add connector.
2
Search for AWS v2 and click Add.
3
Choose where to add the connector: Create a new app, or Add to an existing app (then select the app).If you’re creating a new app, choose whether to link it to an application discovered from your identity provider: select Yes and pick the IdP application, or No to continue with just the connector.
4
Set the connector’s Name and, optionally, a Description.
5
Click the pencil icon next to Owners to choose who can configure and manage this connector.
6
Click Add. The connector is created and its configuration page opens.
7
Find the Settings area of the page and click Edit.
8
Copy and save the External ID populated in the External ID field.
Create a custom IAM role
This custom role acts as a bridge, allowing C1 to securely access your child account. The trust policy you’re about to create is the key to this connection.1
Navigate to the IAM Dashboard and select Roles > Create Role.
2
Select Custom Trust Policy and paste the following into the Trust Policy JSON editor, replacing Notes on the Trust Policy:
“Action”: “sts:AssumeRole”: This is the core permission. It’s the only action allowed by this policy, and it specifically allows the C1 role in your root account to temporarily assume this role in the child account. Think of it like a temporary key that only the main account can use.
“Principal”: “arn:aws:iam::
{ROOT_ID} with the root ID from the main account and EXTERNAL_ID_FROM_C1_INTEGRATIONS_PAGE with the External ID you copied from C1.{ROOT\_ID}:role/ConductorOneService”: This is the trusted entity. It specifies that only the C1 role in your main root account is allowed to assume this role. This ensures that no other account can use this trust policy.
“Condition”: “sts:ExternalId”: The External ID acts as a shared identifier between you and C1, confirming which trust relationship is being used. This helps prevent the “confused deputy” problem by ensuring the request is coming from the expected context. Learn more about granting access using External IDs.3
Click Next.
4
Skip Add permissions and click Next.
5
Give the role a name, such as C1Integration.
6
Add any tags relevant to your organization and click Create Role.
7
Find the newly created role, and click on it to view the role details page.
Grant permission for data sync
Next, you will create an inline policy to define the specific data this role can gather from the child account. These are read-only permissions that enable C1 to securely sync your IAM data.1
Under Permissions Policies, click Add Permissions and select Create Inline Policy.
2
Switch to the JSON Editor tab and paste the following policy into the editor:Explanation of permissionsCore IAM Permissions These permissions allow C1 to sync your basic identity structure.
- iam:ListUsers: Allows C1 to retrieve a list of all IAM user accounts.
- iam:ListGroups: Allows C1 to retrieve a list of all IAM groups.
- iam:ListRoles: Allows C1 to retrieve a list of all IAM roles.
- iam:GetGroup: Required to see which users belong to which groups. ListGroups only provides the group names, while GetGroup identifies the specific members.
- iam:GetRole: Allows C1 to retrieve detailed information about specific roles, including their trust relationships.
access_key_last_used on each IAM user. Enable Sync secrets to also sync each key as its own secret resource with status and per-key activity.- iam:ListAccessKeys and iam:GetAccessKeyLastUsed: These allow C1 to gather access key metadata, including when each key was last used. This is useful for identifying unused or stale credentials. Note that C1 only retrieves metadata for auditing; it does not store or access the secret access keys themselves.
BATON_SYNC_IAM_USER_CONSOLE_ACCESS) is enabled. The flag is off by default because it makes one iam:GetLoginProfile call per IAM user.- iam:GetLoginProfile: Allows C1 to see whether each IAM user has a console login profile, and whether a password reset is required.
- organizations:ListAccounts: Allows the connector to discover all accounts within your AWS Organization.
- organizations:DescribeOrganization: Provides high-level details about your organization to ensure proper mapping.
- iam:ListAccountAliases: Include this if you prefer to use human-readable account aliases (for example, “Production-Environment”) in the C1 UI instead of 12-digit numeric AWS account IDs.
- iam:ListPolicies, iam:GetPolicy, and iam:GetPolicyVersion: Allow C1 to discover managed policies and read the JSON document of each policy’s default version.
- iam:ListUserPolicies, iam:ListRolePolicies, and iam:ListGroupPolicies: Allow C1 to discover the inline policies embedded in each IAM user, role, and group.
- iam:GetUserPolicy, iam:GetRolePolicy, and iam:GetGroupPolicy: Allow C1 to read the JSON document of each inline policy.
- iam:ListAttachedUserPolicies, iam:ListAttachedRolePolicies, and iam:ListAttachedGroupPolicies: Allow C1 to see which managed policies are attached to which users, roles, and groups. If these permissions are omitted, the connector still syncs successfully — policy resources are either skipped or synced without their document contents.
3
Click Review Policy.
4
Give the policy a name, such as C1Permissions and click Create Policy.
5
Copy the Role ARN for the Role we created, it should look like:
arn:aws:iam::NNNNNNNNNN:role/ConductorOneIntegration.Configure the AWS connector
- Cloud-hosted
- Self-hosted
- Terraform
Follow these instructions to use a built-in, no-code connector hosted by C1.Done. Your AWS connector is now pulling access data into C1.
1
Return to the AWS v2 connector setup page in C1.
2
Find the Settings area of the page and click Edit.
3
Paste the AWS Role ARN into the Role ARN field.
4
Optional. Click to Enable support for AWS Organizations.
If support for AWS Organizations is enabled, the IAM Role (as described in Step 2) must be created in the management (formerly called master) account of the AWS Organization. If the IAM Role is created on a member account and support for AWS Organizations is enabled, the integration will return a 400 error.
5
Optional. Click to Enable support for AWS IAM Identity Center and select the region for AWS IAM Identity Center from the dropdown.
6
Optional. Enable Sync secrets to display them on the Inventory page.
7
Optional. Enable Sync IAM User Console Access to report whether each IAM user has a console password. The connector role must include
iam:GetLoginProfile.8
Optional. If both Organizations support and Identity Center support are enabled, enable Sync SSO User Last Login to report Identity Center sign-ins. The connector role must include
cloudtrail:LookupEvents.9
Click Save.
10
The connector’s label changes to Syncing, followed by Connected. You can view the logs to ensure that information is syncing.