secretref://prod-aws/runlayer/jira#api_key; the secret value is fetched when a connection is made, held in memory only, and never persisted or logged.
What This Changes
- At-rest exposure stays low. A compromise of Runlayer’s database yields references, not credentials.
- Rotation without Runlayer. Rotate the secret in AWS; new connections pick up the new value within the cache window (about 2 minutes). Existing connections keep the value resolved when they connected.
- Runtime access still exists. The Runlayer data plane still reads the secret at resolve time. Secret stores remove at-rest exposure, not runtime exposure.
Set up an AWS Secrets Manager store
Runlayer generates an External ID for each store when you create it — you don’t invent one. The setup order is therefore: create the role, register the store, then paste the generated External ID into the role’s trust policy.1
Create the IAM role
In the AWS account holding your secrets, create a role Runlayer can assume.
Give it read access to the secrets you intend to reference:Start with a trust policy that allows Runlayer’s account to assume it. For
self-hosted deployments, use your backend’s IAM role ARN as the principal
instead. You will tighten the policy with the External ID after registering
the store:
A separate, scoped IAM role is required for every store, including
self-hosted deployments. Runlayer always assumes that role with the
store’s External ID. It never reads referenced secrets directly with the
backend’s IAM role. Multiple stores can share a role if its trust policy
allows each store’s External ID.
2
Register the store
Open Settings → Secret Stores. Click Add secret store in the empty
state, or Add in the header. Enter a name, the AWS region for the secrets,
and the role ARN from the previous step.The saved store card shows a generated External ID such as
rl:3f2a....
Copy this value.3
Add the External ID to the trust policy
Add the
sts:ExternalId condition to the role’s trust policy using the value
from the store card. This is the
confused-deputy
protection: Runlayer sends this store’s External ID on every assume-role,
and the condition ensures only Runlayer acting for your store can assume the
role.4
Test role assumption
After updating the trust policy, return to Runlayer and click Test role
assumption on the store card. This verifies that Runlayer can assume the
role using the store’s External ID; it does not verify
secretsmanager:GetSecretValue for a particular secret. Use the
connector’s connection test to verify access to each referenced secret.Reference Secrets from Connectors
Anywhere a connector’s transport configuration takes a header value or stdio environment value, you can use a reference instead:<store-name>— the store name from Settings → Secret Stores.<secret-name-or-arn>— the Secrets Manager secret name or full ARN.#<json-field>— optional; when the secret value is a JSON object, selects one key. Omit it to use the whole secret string.- The full value must be the
secretref://...reference. Embedded references inside a larger string are not resolved.
authorization field:
Behavior Details
Permissions
- Viewing stores: organization settings admins, connector admins, and Deploy users can view the page when secret stores are enabled.
- Managing stores: only organization settings admins can create, update, delete, and test stores.
- Referencing stores: connector admins can reference stores in connector config. The store list is visible to them for that purpose.