Skip to main content
This is an updated and improved version of the AWS connector!If you’re setting up AWS with C1 for the first time, you’re in the right place.

​
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 global assume_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; and
  • policy_json: an optional restrictive inline session policy.
Before enabling the action, create an IAM OIDC provider for the C1 issuer and a role trust policy allowing 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.
Instead of one row per (account, permission set, user) combination, reviewers see “Permission Set X on Account Y” as a single item, with the account’s place in the AWS Organizations hierarchy shown for context. These four resource types are opt-in on the C1 platform: even with both checkboxes enabled above, you must separately opt in to each resource type before C1 begins syncing it. Until you opt in, the connector keeps syncing the existing flat account/permission-set entitlement model unchanged. Syncing the Organization Root / Organizational Unit hierarchy also requires the 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.
Each policy resource carries its policy document (the JSON that defines which actions the policy allows or denies) as a resource attribute, so reviewers can see what a policy actually grants instead of only its name. Syncing policy documents requires the policy read permissions listed in the IAM policies below (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.
Populating 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_service and last_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.
Two optional settings gate parts of this, and both are off by default:
  • 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 it console_access_enabled, password_reset_required, and login_profile_created_at are not populated. It is off by default because it costs one iam:GetLoginProfile call per IAM user and requires iam:GetLoginProfile on the connector role. This setting detects an IAM console password; it does not detect access through Identity Center or an assumed role.
IAM user Last Login itself does not depend on either setting. Identity Center user Last Login uses a separate CloudTrail event feed. Enable Organizations support, Identity Center support, and Sync SSO User Last Login (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.
ImportantA user with the Connector Administrator or Super Administrator role in C1 and the ability to create an IAM Role in AWS must perform this task.C1 uses an IAM Trust relationship between your AWS Account and C1’s Service AWS Account. This is the AWS recommended method of sharing access to AWS Accounts. C1 has a specially created and isolated AWS Account dedicated to the AWS integration. For advanced configurations, the only trusted entity should be the following ARN: arn:aws:iam::765656841499:role/ConductorOneService
Follow the relevant set of instructions below to set up the AWS connector for IAM or SSO, as your configuration dictates.

​
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-account sts: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 {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.
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}: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 activity These permissions populate 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.
Optional: IAM User Console Access The JSON above includes this permission. It is used only when Sync IAM User Console Access (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.
Optional: AWS Organizations Support Include these permissions if you enable the “Enable support for AWS Organizations” checkbox in the C1 UI.
  • 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.
Optional: Descriptive Account Aliases
  • 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.
Optional: IAM Policies as Resources Include these permissions if you want C1 to sync IAM managed policies and inline policies as resources, along with their policy documents. See IAM policies as resources above.
  • 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.
Done. Next, move on to the connector configuration instructions.

​
Configure the AWS connector

To complete this task, you’ll need:
  • The Connector Administrator or Super Administrator role in C1
  • Access to the set of AWS credentials generated by following the instructions above
Follow these instructions to use a built-in, no-code connector hosted by 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.
Done. Your AWS connector is now pulling access data into C1.
If your users work from the command line, see Use Cone with AWS IAM Identity Center to request and retrieve AWS credentials directly from the AWS CLI.