Integrate with AWS
Before starting
Before starting, you should decide which parts of your AWS ecosystem you want to monitor. You may choose to monitor the entire AWS organization or single accounts. If you want SlashID to protect all the data in your AWS Organization, you must use an organization management account for setup. Otherwise, SlashID will monitor only the data in the specified AWS account.
The policy below is organized into four permission tiers so you can grant only what you need:
- Tier 1 (required) — the minimum permissions for identity sync to work. Without these, the connection cannot operate.
- Tier 2 (required only if you use AWS Identity Center) — permissions for mapping
permission sets and group memberships. SlashID detects Identity Center automatically
via
sso:ListInstances; once detected, these become required. - Tier 3 (optional) — per-resource-type read permissions (EC2, S3, RDS, EKS, Lambda, Secrets Manager, KMS, DynamoDB, Bedrock). Grant only the resource types you want visible in SlashID. Withholding a type causes SlashID to skip it; everything else continues.
- Tier 4 (optional) — permissions for CloudTrail-based activity monitoring and SlashID's automatic CloudFormation setup (management stack, member StackSet, event streaming infrastructure). Withholding these gives you a read-only integration: identity and resource data sync as normal, but SlashID will not automatically deploy infrastructure into your account.
Org customers — least-privilege option: Instead of granting Tier 4 permissions,
you can deploy the member-account template (slashid-member-account-setup.yaml)
yourself as a StackSet across your organization's member accounts. This establishes
the cross-account trust SlashID needs for org-wide identity sync without requiring
provisioning permissions in the management account.
Set up the connection
- In your AWS Management Console > IAM > Policies, create a new policy:
- Policy editor: JSON
- Paste the following policy in the Policy editor. This policy contains all the permissions needed to automatically set up the connection between SlashID and AWS.
SlashID's AWS permissions are split into tiers. Tier 1 is required. Add the others only for the capabilities you want — withholding a permission simply means SlashID skips that capability (the connection still works).
Tier 1 — Minimum (required: identity)
Identity mapping is the core of SlashID. Without these, the connection cannot sync.
Tier 2 — Identity Center (required only if you use AWS Identity Center)
If your organization uses AWS Identity Center, add these permissions. SlashID detects
Identity Center via sso:ListInstances; once detected, these are required to map
permission sets and group assignments.
Tier 3 — Additional (optional: resource coverage)
Grant per resource type you want mapped. If a permission is absent, SlashID skips that resource type and continues syncing identity data.
Tier 4 — Activity monitoring & auto-setup (optional)
Enables CloudTrail-based activity monitoring and SlashID's automatic CloudFormation
setup (management stack, member StackSet, event streaming). Withhold these for a
read-only integration — SlashID will sync identity and resource data but will not
automatically deploy infrastructure. Org customers who prefer least-privilege can
deploy slashid-member-account-setup.yaml themselves as a StackSet across member
accounts rather than granting these provisioning permissions.
At this point you choose the authentication method that SlashID will use to access your AWS ecosystem:
- Assume role: create a role with the above policy and a trust statement that allows the SlashID AWS account to assume the role
- (Legacy) Access key: create an AWS access key ID/secret pair belonging to an IAM user that has been assigned the policy above
Assume role
- In your AWS Management Console > IAm > Roles, create a new role and follow the steps in the setup wizard for creating a role that can be accessed by AWS accounts belonging to a third party
- The account ID that should be allowed access is 469725248735
- You should set the external ID field to be your SlashID organization ID, which can be found in the SlashID console
Copy the ARN of the newly created role, which you will need in the next step
In the SlashID console, paste the relevant attributes
| SlashID Console field | Description |
|---|---|
| Name of the connection | Arbitrary name you give to this connection |
| Authoritative status | Decide whether AWS identities are the primary (or secondary) source of truth when reconciling identities across providers |
| Account ID [or Organization ID] | Your AWS account ID or AWS organization ID |
| Region | The region that the API calls target; for best performance, this should be the same region as the S3 bucket where historical log data is stored |
| Authentication method | Assume role |
| Assumable role ARN | The ARN opf the role you created in step 3 |
| CloudTrail S3 bucket (optional) | To pull historical log data, specify the name of the S3 bucket where CloudTrail logs are stored |
| Days of CloudTrail logs to retrieve (optional) | Specify how many days of historical data should be retrieved (defaults to 90 days, max 3650). This operation will take time. |
| CloudTrail digest path prefix (optional) | Prefix for the Cloudtrail logs digest objects within the CloudTrail S3 bucket where historical logs can be found (default is AWSLogs) |
(Legacy) Access key
This approach is not recommended as it generates static, long-lived credentials.
- In your AWS Management Console > IAM > Users, create a new user:
- Set permissions: Attach policies directly and select the policy created in step 1.
- Open the new user page. In the Security credentials tab, scroll down to Access keys and click on Create access key:
- Access key best practices & alternatives: Third-partyAuthentication method Access key service
- Retrieve access keys: copy and store the Access key and Secret access key which you will need in the next step.
- In the SlashID console, paste the relevant attributes
| SlashID Console field | Description |
|---|---|
| Name of the connection | Arbitrary name you give to this connection |
| Authoritative status | Decide whether AWS identities are the primary (or secondary) source of truth when reconciling identities across providers |
| Account ID [or Organization ID] | Your AWS account ID or AWS organization ID |
| Region | The region that the API calls target; for best performance, this should be the same region as the S3 bucket where historical log data is stored |
| Authentication method | Access key |
| Access key ID | The ID of the access key you created in step 3 |
| Access key secret | The secret of the access key you created in step 3 |
| CloudTrail S3 bucket (optional) | To pull historical log data, specify the name of the S3 bucket where CloudTrail logs are stored |
| Days of CloudTrail logs to retrieve (optional) | Specify how many days of historical data should be retrieved (defaults to 90 days, max 3650). This operation will take time. |
| CloudTrail digest path prefix (optional) | Prefix for the Cloudtrail logs digest objects within the CloudTrail S3 bucket where historical logs can be found (default is AWSLogs) |
Optional permissions: Bedrock
Granting the following optional read-only permissions lets SlashID inventory
Amazon Bedrock models, inference profiles, guardrails, agents, knowledge bases,
agent aliases, knowledge base data sources, and managed prompts. SlashID stores resource
metadata only; it does not read prompt/completion payloads or the documents inside
knowledge base data sources.
The GetAgent, GetAgentAlias, and GetKnowledgeBase permissions are used to
resolve canonical resource ARNs and service-role metadata from Bedrock summaries.
[
"bedrock:ListFoundationModels",
"bedrock:ListCustomModels",
"bedrock:ListImportedModels",
"bedrock:ListProvisionedModelThroughputs",
"bedrock:ListInferenceProfiles",
"bedrock:ListGuardrails",
"bedrock:ListAgents",
"bedrock:GetAgent",
"bedrock:ListAgentAliases",
"bedrock:GetAgentAlias",
"bedrock:ListKnowledgeBases",
"bedrock:GetKnowledgeBase",
"bedrock:ListDataSources",
"bedrock:ListPrompts"
]
If these permissions are not granted, Bedrock resources are simply skipped — the rest of the scan is unaffected.
Optional permissions: DynamoDB
Granting the following optional read-only permissions lets SlashID inventory your DynamoDB tables and their streams and represent their access capabilities (resource-based policies). SlashID never reads the data stored in your tables.
[
"dynamodb:ListTables",
"dynamodb:DescribeTable",
"dynamodb:DescribeContinuousBackups",
"dynamodb:ListTagsOfResource",
"dynamodb:GetResourcePolicy",
"dynamodb:DescribeStream"
]
If these permissions are not granted, DynamoDB resources are simply skipped — the rest of the scan is unaffected.