Облачные секреты: AWS engine

Тот же принцип динамики, но для облака: Vault выдаёт временные ключи доступа AWS.

AWS secrets engine — движок, динамически выдающий временные креды AWS (Access Key/Secret Key или STS-токены) по запросу и отзывающий их по истечении аренды.

Долгоживущие ключи AWS — классический источник катастроф: один закоммиченный AKIA... может стоить компании огромного счёта за майнинг. AWS-движок Vault убирает статические ключи, выдавая временные по запросу.

Настройка движка

vault secrets enable aws

# креды, под которыми Vault управляет IAM
vault write aws/config/root \
  access_key=AKIA_ADMIN_KEY \
  secret_key=admin-secret \
  region=eu-central-1

Роль: что выдавать

Роль описывает, какие права получат временные креды. Здесь — политика доступа только на чтение S3-бакета:

vault write aws/roles/s3-readonly \
  credential_type=iam_user \
  policy_document=-<<EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"]
  }]
}
EOF

Запрос временных кредов

vault read aws/creds/s3-readonly

{
  "lease_id": "aws/creds/s3-readonly/k2Lm9",
  "lease_duration": 3600,
  "data": {
    "access_key": "AKIA_TEMP_XXXX",
    "secret_key": "temp-secret-key",
    "security_token": null
  }
}

Два типа кредов

credential_type	Что выдаёт	Особенности
iam_user	создаёт реального временного IAM-пользователя	есть задержка распространения IAM, лимит на число юзеров
assumed_role	STS-токен через AssumeRole	быстрее, короче живёт, предпочтительно

Как работает под капотом

Для iam_user Vault под админскими ключами вызывает IAM API: создаёт пользователя, прикрепляет инлайн-политику, генерирует ключ доступа и отдаёт его. По истечении аренды — удаляет пользователя и ключ. Для assumed_role Vault обращается к STS и возвращает короткоживущий набор (access key + secret + security token), который AWS сам инвалидирует по сроку. Важная тонкость iam_user: только что созданные ключи IAM распространяются по AWS не мгновенно, поэтому первые секунды запрос может получать AccessDenied — приложение должно делать ретраи.

Частые ошибки

Использовать iam_user там, где подошёл бы assumed_role — упираетесь в лимит IAM-пользователей и задержку распространения.
Не делать ретраи на свежих iam_user-кредах — словите случайные AccessDenied.
Широкая policy_document — временные креды с лишними правами всё равно опасны.
Долгий max_ttl — нивелирует выгоду временных кредов.

Итог

AWS engine выдаёт временные IAM-креды по запросу и отзывает по истечении аренды.
assumed_role (STS) обычно предпочтительнее iam_user: быстрее и без лимитов на юзеров.
Свежие iam_user-ключи распространяются не мгновенно — нужны ретраи.