> For the complete documentation index, see [llms.txt](https://docs.enclaive.cloud/vault/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.enclaive.cloud/vault/tutorials/use-cases/dynamic-credentials-for-cloud-providers/aws.md).

# AWS

Unlike the `kv` secrets where you had to put data into the store yourself, dynamic secrets are generated when they are accessed. Dynamic secrets do not exist until they are read, so there is no risk of someone stealing them or another client using the same secrets. Because Vault has built-in revocation mechanisms, dynamic secrets can be revoked immediately after use, minimizing the amount of time the secret existed.

{% hint style="info" %}
Before starting this page, please register for an [AWS account](https://aws.amazon.com/). You won't be using any features that cost money, so you shouldn't be charged for anything. However, we are not responsible for any charges you may incur.
{% endhint %}

### Enable the AWS secrets engine <a href="#enable-the-aws-secrets-engine" id="enable-the-aws-secrets-engine"></a>

Unlike the `kv` secrets engine which is enabled by default, the AWS secrets engine must be enabled before use. This step is usually done via a configuration management system.

{% tabs %}
{% tab title="CLI" %}

```shell-session
$ vault secrets enable -path=aws aws

Success! Enabled the aws secrets engine at: aws/
```

{% endtab %}

{% tab title="UI" %}

<figure><img src="/files/tYQcdwF8i9rxqWGpPXiV" alt=""><figcaption></figcaption></figure>
{% endtab %}
{% endtabs %}

The AWS secrets engine is now enabled at `aws/`. Different secrets engines allow for different behavior. In this case, the AWS secrets engine generates dynamic, on-demand AWS access credentials.

### Configure the AWS secrets engine <a href="#configure-the-aws-secrets-engine" id="configure-the-aws-secrets-engine"></a>

After enabling the AWS secrets engine, you must configure it to authenticate and communicate with AWS. This requires privileged [AWS account credentials](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html).

If authenticating with an IAM user, set your AWS Access Key as an environment variable in the terminal that is running your Vault server:

```shell-session
$ export AWS_ACCESS_KEY_ID=<aws_access_key_id>
```

Next, set your secret key.

```shell-session
$ export AWS_SECRET_ACCESS_KEY=<aws_secret_key>
```

Your keys must have the IAM permissions listed in the Vault documentation to perform the actions on the rest of this page.

{% hint style="warning" %}
Your root account keys will have all of the required permissions, but you **should not** use your root account keys in production. This is a getting started tutorial and is not a best practices tutorial for production installations.
{% endhint %}

Configure the AWS secrets engine.

```shell-session
$ vault write aws/config/root \
    access_key=$AWS_ACCESS_KEY_ID \
    secret_key=$AWS_SECRET_ACCESS_KEY \
    region=us-east-1
```

**Output:**

```plaintext
Success! Data written to: aws/config/root
```

These credentials are now stored in this AWS secrets engine. The engine will use these credentials when communicating with AWS in future requests.

### Create a role <a href="#create-a-role" id="create-a-role"></a>

The next step is to configure a *role*. Vault knows how to create an IAM user via the AWS API, but it does not know what permissions, groups, and policies you want to attach to that user. This is where roles come in - a role in Vault is a human-friendly identifier to an action.

For example, here is an [IAM policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) that enables all actions on EC2, but not IAM or other AWS services.

```json
{
  "Version": "2023-11-12",
  "Statement": [
    {
      "Sid": "Stmt1426528957000",
      "Effect": "Allow",
      "Action": ["ec2:*"],
      "Resource": ["*"]
    }
  ]
}
```

If you are not familiar with AWS' IAM policies, that is okay - just use this one for now.

You need to map this policy document to a named role. To do that, write to `aws/roles/:name` where `:name` is your unique name that describes the role (such as `aws/roles/my-role`):

```shell-session
$ vault write aws/roles/my-role \
        credential_type=iam_user \
        policy_document=-<<EOF
{
  "Version": "2023-11-12",
  "Statement": [
    {
      "Sid": "Stmt1426528957000",
      "Effect": "Allow",
      "Action": [
        "ec2:*"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}
EOF
```

You just told Vault:

> When I ask for a credential for "my-role", create it and attach the IAM policy `{ "Version": "2012..." }`.

### Generate the secret <a href="#generate-the-secret" id="generate-the-secret"></a>

Now that the AWS secrets engine is enabled and configured with a role, you can ask Vault to generate an access key pair for that role by reading from `aws/creds/:name`, where `:name` corresponds to the name of an existing role:

```shell-session
$ vault read aws/creds/my-role
Key                Value
---                -----
lease_id           aws/creds/my-role/0bce0782-32aa-25ec-f61d-c026ff22106e
lease_duration     768h
lease_renewable    true
access_key         AKIAJELUDIANQGRXCTZQ
secret_key         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
security_token     <nil>
```

Success! The access and secret key can now be used to perform any EC2 operations within AWS. Notice that these keys are new, they are not the keys you entered earlier. If you were to run the command a second time, you would get a new access key pair. Each time you read from `aws/creds/:name`, Vault will connect to AWS and generate a new IAM user and key pair.

Copy the full path of this `lease_id` value found in the output. This value is used for renewal, revocation, and inspection.

### Revoke the secret <a href="#revoke-the-secret" id="revoke-the-secret"></a>

Vault will automatically revoke this credential after 768 hours (see `lease_duration` in the output), but perhaps you want to revoke it early. Once the secret is revoked, the access keys are no longer valid.

To revoke the secret, use `vault lease revoke` with the lease ID that was outputted from `vault read` when you ran it.

**Example:**

```shell-session
$ vault lease revoke aws/creds/my-role/0bce0782-32aa-25ec-f61d-c026ff22106
Success! Revoked lease: aws/creds/my-role/0bce0782-32aa-25ec-f61d-c026ff22106e
```

Done! If you login to your AWS account, you will see that no IAM users exist. If you try to use the access keys that were generated, you will find that they no longer work.

In this tutorial, you experienced your first dynamic secret and you also saw the revocation system in action. Dynamic secrets are incredibly powerful.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.enclaive.cloud/vault/tutorials/use-cases/dynamic-credentials-for-cloud-providers/aws.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.