> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/integrations/integrations-overview/aws-secrets-management.md).

# AWS Secrets Management

Release's integration with AWS for secrets management let's you use and manage secrets using either [AWS Secrets Manager ](https://aws.amazon.com/secrets-manager/)or [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html). This integration allows you to bulk load a group of secrets into your services and/or jobs based on a pattern.

## Prerequisites

Before you begin, ensure you have:

1. Access to a Release environment with Kubernetes clusters configured.
2. You have stored your secrets in the same region as the cluster/s Release is managing
3. Decide on the pattern you would like Release to use and create secrets following this pattern.

## Setting up your App and/or Environment configuration

<pre class="language-yaml"><code class="lang-yaml"><strong>secrets:
</strong><strong>- name: default-secrets
</strong>  type: aws
  pattern: /Release/Secrets/Defaults/* #default secrets that many services need
- name: backend-secrets
  type: aws
  pattern: /Release/Secrets/Backend/* #only backend specific secrets
</code></pre>

Name and type are pretty self explanitory, but the pattern is what makes the integration work. The pattern tells Release which secrets to pull into your services and/or jobs. In order for Release to utilize your secrets the pattern needs to match your naming scheme of your secrets.

{% hint style="info" %}
The pathing you use in the name of the secret is up to you, but it must follow the form of: **/Something/More/MoreStuff/\*** or **/Something/\***, etc. The only requirments are\
\* Use "/"s to delineate; you can use any number of "/"s, but at least 1 is required\
\* Include an asterisk (\*) at the end.
{% endhint %}

For the example up above secrets named like:

* /Release/Secrets/Defaults/TEST\_SECRET0 #would be included in the default list
* /Release/Secrets/Backend/BACKEND\_TEST\_SECRET0 #would be included in the backend list
* SOME\_SECRET #would not be automatically included in any list

{% hint style="info" %}
The name of the secrets in your containers will only be the characters after the last '/'. A secret with a key or name like: **/Release/Secrets/Defaults/TEST\_SECRET0** will be **TEST\_SECRET0** in your containers. The preceding path (/Release/...) will be ommitted.
{% endhint %}

## Using the secrets in your services and job definitions

```yaml
services:
- name: rails
  image: github-org/rails
  secrets_from:
  - default-secrets #include default secrets
  - backend-secrets #include backend secrets

- name: ai-chatbot
  image: github-org/ai-chatbot
  secrets_from:
  - default-secrets #include only default secrets

jobs:
- name: chatbot-setup
  image: github-org/rails
  secrets_from:
  - default-secrets
  - backend-secerts
```

## Conclusion

This integration allows you to create an arbitrary amount of secrets you want bulk loaded into your containers. You need only come up with path and naming scheme you like and tell Release about it and we can autoload them into your containers.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.release.com/integrations/integrations-overview/aws-secrets-management.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.