AWS Secrets Manager provider (packs:secrets-aws)

packs:secrets-aws

AWS Secrets Manager is a SecretsProvider kind: aws-secrets-manager. It is additive on the open kind set — the same connection object, CRUD verbs, test verb, health recording, audit events and admin RBAC gate as the vault kinds, with AWS-shaped configuration. Everything on this page requires the packs:secrets-aws licence entitlement (see entitlements): creating an aws-secrets-manager provider, or enabling a disabled one, refuses with the typed entitlement error naming the pack. Already-enabled providers keep resolving on licence lapse — only the create/enable writes gate (the polite-lapse posture), and disabling stays open for lapse cleanup.

Configuration

Field	Meaning for this kind
kind	aws-secrets-manager
region	Required. The AWS region the Secrets Manager endpoint lives in (e.g. ap-southeast-2).
address	Optional endpoint-URL override (a VPC endpoint, or a local emulator in testing). Empty derives https://secretsmanager.<region>.amazonaws.com.
auth_method	access-key (the kind's only method, and its default).
username	The IAM access key id — the non-secret identity half, exactly as userpass auth carries its username.
credential	The IAM secret access key — encrypted at rest, write-only (reads serve credential_set), rotated by the update verb with an audit event that never carries the value.
mount_path	Optional secret-name prefix: every OpsChain path is stored under <mount_path>/, scoping the provider to one corner of the account's namespace.
ssl_verify / ssl_ca_cert	The same TLS options the vault kinds carry — for proxied or emulated endpoints.
cipher_stacking / password_length	As for every provider: whether /api/secrets/store cipher-stacks written values, and the generated-secret length.

kv_version and role_id belong to the vault kinds and are refused on this one.

Requests are signed with AWS Signature Version 4 directly — the server carries no AWS SDK, exactly as the vault kinds speak their HTTP API with no vendor client. The signing identity is always an access key pair; ambient-identity mechanisms (instance profiles, IRSA) are not consulted, so the provider behaves identically wherever the server runs.

How secrets map

One AWS secret holds one OpsChain secret node: the secret's SecretString is a JSON object of key/value pairs, and a secret-vault://<path>/<key> reference reads key <key> from the secret named <mount_path>/<path>. A secret whose SecretString is not a JSON object reads as the single key value, so a console-created plain secret is reachable as secret-vault://<path>/value. Listings (the vault browser, the audit/migrate walkers) compute the directory view from the slash-separated secret names under the prefix — Secrets Manager's namespace is flat, so a name like app/db renders as directory app/ holding node db.

The test verb

TestSecretsProvider (CLI: opschain admin secrets providers test <code>) authenticates with the stored access key pair and performs a single-page ListSecrets capability probe. The typed outcome is recorded as the connection's health (last_test_*), and the failure reason never carries credential material. The IAM policy behind the pair needs secretsmanager:GetSecretValue and secretsmanager:ListSecrets for reads and the browser, plus secretsmanager:CreateSecret and secretsmanager:PutSecretValue where /api/secrets/store writes.

Resolution lanes

• Server-side resolution — secret-vault:// references in properties, the /api/secrets read/write seam and the vault browser all resolve through the provider object, routed by the declared scope bindings exactly as the vault kinds are. Resolved values join the log mask set.
• Interactive reads use the USER's own credential (the posture): each user stores their own IAM access key pair in preferences (username the access key id, the credential the secret access key; auth method access-key), and AWS's own IAM policy for that pair governs what the reveal/browser shows them. No stored personal pair → the typed configure-your-credential refusal, never a silent fall-back to the platform pair.
• No runner environment, no step lease. The OPSCHAIN_VAULT_* projection and the response-wrapped step lease speak the vault wire protocol, which opschain-core inside the runner expects — an AWS-backed provider projects neither. Step properties still resolve (server-side, before dispatch, masked in logs); what an AWS-backed estate does not get is in-runner secret-vault:// resolution by MintPress action code reading OPSCHAIN_VAULT_* directly (only applicable to existing MintPress customers and those using the MintPress SDK or the packs:mintpress feature). That lane needs a coordinated opschain-core release and is recorded as the kind's follow-on gap.

Pack gating end to end

• CreateSecretsProvider with kind: aws-secrets-manager → permission_denied, ERROR_REASON_FEATURE_ENTITLEMENT_REQUIRED, metadata feature: packs:secrets-aws — unless the licence grants the pack.
• UpdateSecretsProvider enabling a disabled AWS provider → the same typed refusal.
• The secrets:multi-vault gate composes independently: a second enabled provider still needs it, whatever the kinds.