AWS Secrets Manager (Static Credentials)

Overview

This guide walks you through configuring AWS Secrets Manager as a secret provider for your CrewAI Platform organization, using static credentials (access keys, optionally with AssumeRole). By the end, CrewAI Platform will be able to read secrets stored in your AWS account and inject them as environment variable values at runtime.

This guide covers the static credentials path — secrets are resolved at deploy time and baked into the deployment image. Rotated values require a re-deploy. If you want rotation-aware secrets that update on every automation kickoff (no re-deploy), see AWS Workload Identity (OIDC Federation).

This guide covers the AWS-side configuration and the credential setup in CrewAI Platform. To then reference a secret from an environment variable, see Using the Secrets Manager.

Prerequisites

Before starting, make sure you have:

An AWS account with permission to create IAM users, customer-managed policies, and (optionally) IAM roles.
The AWS region where your secrets live (or will live), for example us-east-1.
A CrewAI Platform organization where your user has the secret_providers: manage permission. See Permissions (RBAC).

Choose an Authentication Method

CrewAI Platform supports two ways for the platform to authenticate with AWS Secrets Manager. Pick one before you begin — the steps below differ depending on which you choose.

Method	When to use	Trade-offs
Static access keys	Getting started, single-account deployments	Simplest setup; access keys must be rotated manually
AssumeRole	Cross-account, production hardening	Short-lived credentials; supports External ID; requires extra IAM role

The rest of this guide uses tabs in Steps 3–5 so you can follow the path that matches your choice.

Step 1 — Create an IAM User

Open the IAM console, navigate to Users, then click Create user.

Suggested name: crewai-secrets-reader.
Leave Provide user access to the AWS Management Console unchecked — this principal is used programmatically by CrewAI Platform, not by humans.
Click Next.

On the Set permissions page, leave the default selection. You will attach the policy in Step 3. Click Next, review, and click Create user. For full details, see the AWS documentation: Create an IAM user in your AWS account.

Step 2 — Create the IAM Policy

CrewAI Platform needs read-only access to AWS Secrets Manager and permission to decrypt secrets via KMS. Create a customer-managed policy with the following JSON. In the IAM console, navigate to Policies, then click Create policy. Choose the JSON tab and replace the contents with:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SecretsManagerRead",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:ListSecrets",
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": "*"
    },
    {
      "Sid": "KMSDecrypt",
      "Effect": "Allow",
      "Action": [
        "kms:DescribeKey",
        "kms:Decrypt"
      ],
      "Resource": "*"
    }
  ]
}

Click Next, then on the Review and create page:

Policy name: CrewAISecretsManagerRead
Description (optional): Read-only access to AWS Secrets Manager for CrewAI Platform

Click Create policy.

The policy above grants * on Resource for simplicity. In production, scope the Resource down to the ARNs of the specific secrets CrewAI Platform should access, and scope kms:Decrypt to the specific KMS key ARNs that encrypt those secrets. See the AWS guidance on least privilege.

Step 3 — Attach the Policy

Static access keys
AssumeRole

In the IAM console, navigate to Users and click the user you created in Step 1.
On the Permissions tab, click Add permissions → Attach policies directly.
Search for CrewAISecretsManagerRead, select it, and click Next.
Click Add permissions.

With AssumeRole, the policy is attached to a separate IAM role (not directly to the user). The user from Step 1 only needs permission to call sts:AssumeRole on that role.Create the role:

In the IAM console, navigate to Roles and click Create role.
Trusted entity type: AWS account. Choose This account (or Another AWS account for cross-account setups, then enter the AWS account ID hosting the IAM user from Step 1).
(Recommended) Check Require external ID and enter a value you generate yourself — this is a shared secret you will paste into CrewAI Platform in Step 5.
Click Next.
Attach the CrewAISecretsManagerRead policy.
Click Next, name the role CrewAISecretsManagerRole, and click Create role.

Allow the IAM user to assume the role:

Open the role you just created and copy its ARN.
In the IAM console, navigate to Users, click the user from Step 1, and on the Permissions tab click Add permissions → Create inline policy.
On the JSON tab, paste the following (replace ROLE_ARN_FROM_ABOVE):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "ROLE_ARN_FROM_ABOVE"
    }
  ]
}

Name the policy CrewAIAssumeSecretsRole and click Create policy.

Step 4 — Get Credentials

Static access keys
AssumeRole

In the IAM console, open the user from Step 1.
Click the Security credentials tab.
Under Access keys, click Create access key.
Select Application running outside AWS (or Other) as the use case. Click Next.
(Optional) Add a description tag. Click Create access key.
Click Show to reveal the secret access key, then copy both the Access key ID and the Secret access key, or click Download .csv file.

The secret access key is shown only once. If you close this page without copying it, you will need to delete the key and create a new one.

For full details, see the AWS documentation: Manage access keys for IAM users.

Even with AssumeRole, CrewAI Platform still needs an access key for the IAM user — it uses those keys as the calling identity to perform the sts:AssumeRole call.

Create an access key for the user exactly as described in the Static access keys tab above.
Open the role you created in Step 3 and copy:
- The Role ARN (from the role summary).
- The External ID you configured (if any) — you set this yourself in Step 3, so make sure you have it on hand.

Step 5 — Add the Credential in CrewAI Platform

In CrewAI Platform, navigate to Settings → Secret Provider Credentials and click Add Credential.

Static access keys
AssumeRole

Fill the form:

Name: A descriptive name, e.g. aws-prod.
Provider: AWS Secrets Manager.
Region: The AWS region where your secrets live, e.g. us-east-1. This must match the region of the secrets you want to read.
Access Key ID: The value from Step 4.
Secret Access Key: The value from Step 4.
(Optional) Check Set as default credential for this provider. The default credential is used by environment variables that reference AWS secrets without specifying a credential explicitly.

Leave Role ARN and External ID blank.Click Create.

Fill the form:

Name: A descriptive name, e.g. aws-prod-assumerole.
Provider: AWS Secrets Manager.
Region: The AWS region where your secrets live.
Access Key ID: The IAM user’s access key from Step 4 (used to call STS).
Secret Access Key: The IAM user’s secret access key from Step 4.
Role ARN: The Role ARN you copied in Step 4.
External ID: The External ID you set on the role’s trust policy (omit if none).
(Optional) Check Set as default credential for this provider.

Click Create.

How the two modes behave at runtime:

With static access keys only, CrewAI Platform calls AWS Secrets Manager directly using the keys you supplied.
When a Role ARN is set, CrewAI Platform first calls sts:AssumeRole with the supplied access keys (and External ID if configured), then uses the short-lived credentials returned by STS to read your secrets.

Step 6 — Create at Least One Secret in AWS

If you do not already have secrets in AWS Secrets Manager, create one now so you can verify the connection in Step 7. In the AWS Secrets Manager console, click Store a new secret.

Secret type: Choose Other type of secret.
Key/value pairs — either:
- Enter one or more key/value pairs (recommended for structured secrets), or
- Use the Plaintext tab for a single string value.
Encryption key: Use aws/secretsmanager (the AWS-managed key) unless you have a specific KMS key requirement.

Click Next, then enter:

Secret name: A unique name, e.g. crewai/openai-api-key.
Description (optional): A short note about what the secret is for.

Click Next through the rotation and review steps, then click Store.

JSON-key reference syntax. If you store a secret with multiple key/value pairs (a JSON object), CrewAI Platform can extract a specific field using the secret-name#json_key syntax in environment variable references. For example, a secret named database-credentials with {"username": "...", "password": "..."} can be referenced as database-credentials#password. See Using the Secrets Manager for details.

For full details, see the AWS documentation: Create an AWS Secrets Manager secret.

Step 7 — Test the Connection

Back in CrewAI Platform, on the Secret Provider Credentials page, find the credential you just created and click Test Connection. A success toast confirms that CrewAI Platform can authenticate to AWS and read secrets from your account. If the test fails, check the most common causes:

Symptom	Likely cause
`AccessDenied` on `secretsmanager:ListSecrets`	Policy not attached, or wrong user. Re-check Step 3.
`AccessDenied` on `kms:Decrypt`	Missing the `KMSDecrypt` statement, or your secrets use a customer-managed KMS key not covered by `Resource: "*"`.
`InvalidClientTokenId` / `SignatureDoesNotMatch`	Wrong access key ID or secret access key. Re-check Step 4 and Step 5.
`RegionDisabledException` / no secrets found	The credential’s Region does not match where your secrets actually live.
`AccessDenied` on `sts:AssumeRole` (AssumeRole only)	Inline `sts:AssumeRole` policy missing on the IAM user, or the role’s trust policy does not allow this principal, or the External ID does not match.
Test passes immediately after creating the IAM user, but fails next time	IAM credentials sometimes take a minute or two to propagate globally. Retry.

Next Steps

Now that AWS is connected, head to Using the Secrets Manager to:

Grant org members the right permissions to use (or manage) Secrets Manager.
Reference your AWS secrets from CrewAI Platform environment variables.

If you want rotation-aware secrets that propagate without re-deploying, switch to AWS Workload Identity (OIDC Federation) — same secret store, no static credentials, secrets are fetched per kickoff.

Getting Started

Build

Operate

Manage

Integration Docs

Triggers

How-To Guides

Resources

AWS Secrets Manager (Static Credentials)

Overview

Prerequisites

Choose an Authentication Method

Step 1 — Create an IAM User

Step 2 — Create the IAM Policy

Step 3 — Attach the Policy

Step 4 — Get Credentials

Step 5 — Add the Credential in CrewAI Platform

Step 6 — Create at Least One Secret in AWS

Step 7 — Test the Connection

Next Steps

Getting Started

Build

Operate

Manage

Integration Docs

Triggers

How-To Guides

Resources

Documentation Index

​Overview

​Prerequisites

​Choose an Authentication Method

​Step 1 — Create an IAM User

​Step 2 — Create the IAM Policy

​Step 3 — Attach the Policy

​Step 4 — Get Credentials

​Step 5 — Add the Credential in CrewAI Platform

​Step 6 — Create at Least One Secret in AWS

​Step 7 — Test the Connection

​Next Steps

Overview

Prerequisites

Choose an Authentication Method

Step 1 — Create an IAM User

Step 2 — Create the IAM Policy

Step 3 — Attach the Policy

Step 4 — Get Credentials

Step 5 — Add the Credential in CrewAI Platform

Step 6 — Create at Least One Secret in AWS

Step 7 — Test the Connection

Next Steps