AWS Secrets Manager

The aws-secrets-manager provider resolves secrets from AWS Secrets Manager using SigV4-signed HTTPS requests. It supports three authentication modes: static IAM credentials, role-assumption (cross-account or scoped-permission), and IRSA (EKS pod identity).

IRSA (IAM Roles for Service Accounts) is the recommended mode for platform deployments on Amazon EKS. It requires no credentials in the database - the pod assumes a role automatically via the EKS pod identity webhook.

Prerequisites

An AWS account with Secrets Manager enabled in the target region.
An IAM identity (user or role) with secretsmanager:GetSecretValue on the required secret ARNs.
For role-assumption mode: an IAM role the platform can assume via sts:AssumeRole.
For IRSA: an EKS cluster with the pod identity webhook, and an IAM role annotated to your platform's Kubernetes ServiceAccount.

Configuration

Field	Type	Required	Description
`region`	string	Yes	AWS region (e.g. `us-east-1`)
`authMode`	string	Yes	`static`, `role-assumption`, or `irsa`
`accessKeyId`	string	If `static`	IAM access key ID (not secret - safe in config)
`secretAccessKeyCredentialId`	string	If `static` or `role-assumption`	Credential ID of the secret-access-key or role credentials (stored via `rensei-encrypted`)
`roleArn`	string	If `role-assumption` or `irsa`	ARN of the IAM role to assume
`sessionName`	string	No	STS session name for role-assumption (default: `rensei-platform`)
`externalId`	string	No	External ID for cross-account role-assumption
`secretNameTemplate`	string	No	Template for building the secret name: `{orgId}/{kind}` is the default

Secret naming convention

By default, secrets are looked up as {orgId}/{kind} in the configured region. Override the secretNameTemplate to match your naming scheme. Supported placeholders: {orgId}, {kind}.

# Default layout
aws secretsmanager create-secret \
  --name "org_abc123/anthropic-api-key" \
  --secret-string '{"value": "sk-ant-..."}'

# Or as a plain string
aws secretsmanager create-secret \
  --name "org_abc123/anthropic-api-key" \
  --secret-string "sk-ant-..."

JSON secrets are auto-detected: a parseable JSON object populates multiField with all keys, and the primary scalar is extracted using the field priority: apiToken → accessToken → apiKey → token → value.

Authentication modes

Static IAM credentials

For non-AWS or non-EKS deployments. The accessKeyId is stored plaintext in the config (it appears in CloudTrail logs anyway). The secretAccessKeyCredentialId must point to a separate credentials row in rensei-encrypted.

{
  "region": "us-east-1",
  "authMode": "static",
  "accessKeyId": "AKIAIOSFODNN7EXAMPLE",
  "secretAccessKeyCredentialId": "cred_..."
}

Never store the secret access key directly in the AWS config row. Use secretAccessKeyCredentialId to chain through rensei-encrypted.

Role-assumption

For cross-account access or scoped-permission delegation. The platform calls STS AssumeRole, caches the temporary credentials, and renews them before expiry (at 80% of Expiration).

{
  "region": "us-east-1",
  "authMode": "role-assumption",
  "roleArn": "arn:aws:iam::123456789012:role/RenseiSecretsReader",
  "sessionName": "rensei-platform",
  "externalId": "unique-external-id",
  "secretAccessKeyCredentialId": "cred_..."
}

IRSA (recommended for EKS)

No credentials in the database. The EKS pod identity webhook annotates the ServiceAccount and the AWS SDK default credential chain picks up the role automatically.

{
  "region": "us-east-1",
  "authMode": "irsa",
  "roleArn": "arn:aws:iam::123456789012:role/RenseiPlatformSecretsRole"
}

Annotate the Kubernetes ServiceAccount:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: rensei-platform
  namespace: rensei
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/RenseiPlatformSecretsRole

Setup

Create the AWS secrets at the expected path (e.g. org_abc123/anthropic-api-key).

Attach an IAM policy to your role/user granting secretsmanager:GetSecretValue on the secret ARNs.

Store any required sub-credentials (secret-access-key for static/role modes) in Rensei first.

Configure the AWS provider:

curl -X POST https://rensei.ai/api/org/credential-backend \
  -H "Authorization: Bearer rsk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "providerType": "aws-secrets",
    "config": {
      "region": "us-east-1",
      "authMode": "irsa",
      "roleArn": "arn:aws:iam::123456789012:role/RenseiPlatformSecretsRole"
    }
  }'

Test via Settings → Security → Credential Backend → Test Connection.

SigV4 implementation

The provider signs all requests with AWS SigV4 using Node.js's built-in crypto module. No AWS SDK dependency is added - GetSecretValue and AssumeRole are the only two API calls, implemented as ~200 lines of stable signing code. If a future wave requires a third AWS service, the signing module is designed to be extracted into a shared helper.

Refresh policy

GetSecretValue returns no TTL. refreshAt defaults to resolvedAt + 1h. Role-assumption STS credentials honor the Expiration field and pre-renew at 80% of the assumed-credential lifetime.

Security notes

All non-2xx error paths redact the SigV4 Authorization header and any credential material before throwing. Error messages carry only the HTTP status and AWS error code.
The provider does not auto-register in bootstrap.ts. AWS Secrets Manager is opt-in per-org.

On this page