> ## Documentation Index
> Fetch the complete documentation index at: https://docs.superblocks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# AWS Secrets Manager

export const Alert = ({type, title, children}) => {
  const variant = ["info", "success", "warning", "danger", "note"].includes(type) ? type : "note";
  return <div className={`alert alert--${variant}`}>
      <div className="alert-icon" />
      <div className="alert-content">
        {title && <div className="alert-title">{title}</div>}
        <div className="alert-body">{children}</div>
      </div>
    </div>;
};

<Alert type="note">
  <p>
    <strong>Who can use this feature?</strong><br />
    Organization <strong>Owners</strong>, <strong>Admins</strong>, and other users with the <a href="/admin/org-administration/org-roles/permissions"><code>secrets:manage</code></a> permission
  </p>
</Alert>

Connect to your AWS Secrets Manager to securely access application secrets, API keys, and sensitive data from your Superblocks integrations. This guide covers:

* How to [**set up a new secret store**](#set-up) connected to AWS Secrets Manager
* Configuring and managing [**caching**](#caching) for your secret store to improve API performance
* [**Using secrets**](#using-secrets) throughout the Superblocks platform

### Prerequisites

To set up AWS Secrets Manager as a secret store for Superblocks you'll need:

* An AWS account with [**AWS Secrets Manager**](https://aws.amazon.com/secrets-manager/) configured
* Permission to create new IAM policies for your AWS account

## Set up

### Create IAM policy

[**Create an IAM policy**](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html) to grant Superblocks access to your secrets This policy should be associated with either an IAM user (for Access Key auth) or an IAM role (for Assume Role auth when self-hosting the data plane). Below is an example policy:

```json theme={null}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": ["arn:aws:secretsmanager:${REGION}:${ACCOUNT_ID}:secret:*"]
    },
    {
      "Effect": "Allow",
      "Action": ["secretsmanager:ListSecrets"],
      "Resource": "*"
    }
  ]
}
```

We recommend only granting Superblocks access to the minimum set of secret ARN's your team will use in Superblocks. For added security, create secrets that are prefixed with `superblocks/${env}/` to easily identify the secrets used in Superblocks.

### Configure secret store

Configure a new secret store in Superblocks:

1. Go to the [**Secrets Management**](https://app.superblocks.com/secrets-management) page in Superblocks

2. Click the **AWS Secrets Manager** tile

3. Name your secret store integration

4. If your secrets follow [hierarchical naming conventions](https://docs.aws.amazon.com/prescriptive-guidance/latest/secure-sensitive-data-secrets-manager-terraform/naming-convention.html), specify a **Prefix** to filter secrets in this store. For example, if Superblocks secrets are all named like `superblocks/${env}/secret1`, `superblocks/${env}/secret2`, etc, then `superblocks/${env}/` will be the corresponding prefix value.

5. Specify your AWS **Region**

6. Select **Auth type**

   <Tabs>
     <Tab title="Access Key">
       Paste the **Access key ID** and **Secret access key** for the IAM user Superblocks will act on behalf of.
     </Tab>

     <Tab title="Assume Role">
       <Alert type="info">
         Assume role auth is supported only when using Hybrid or Cloud-Prem achitectures where the data plane is self-hosted
       </Alert>

       Specify the **IAM Role ARN** that the data plane will assume via an AWS account trusted entity.
     </Tab>
   </Tabs>

7. Configure caching rules for this store

8. Optionally, add more configurations for [different environments](/development-lifecycle/build/data-tags)

9. Click **Create**

<Alert type="success">
  Your secret store is now configured. Developers can now <a href="/development-lifecycle/build/using-secrets">reference secrets</a> in their integration forms.
</Alert>

## Caching

If enabled, Superblocks can cache your secrets, reducing calls to your secrets manager and improving API performance when using secrets. Caching can be configured for each of your secret store's configurations, letting you set different policies based on the environment.

To configure caches, go to [**Secrets Management**](https://app.superblocks.com/secrets-management) and click into your secrets store. From here you can:

* Update the **Cache TTL (seconds)** to your desired caching interval
* **Clear the cache** if you've rotated a secrets and need Superblocks to refetch secret values

![Manage secret caching](https://superblocks-demo.s3.us-west-2.amazonaws.com/secrets-caching.png "Manage secret caching")

<Alert type="info">
  If you're self-hosting with Hybrid or Cloud-Prem architectures, secrets are cached in-memory by the data plane. For scaled deployments, you'll need to clear each instance's cache individually when rotating secrets. To rotate secrets more easily, disable caching first. Then, after updating the secret, re-enable caching.
</Alert>

## Using secrets

For details on how to reference secrets in integration forms, see [Using secrets](/development-lifecycle/build/using-secrets).