The working security model for on-premise servers to access AWS resources is an IAM User which should only assume an IAM Role. This makes the behavior similar to the Role-based permissions used by EC2 or Lambda. This IAM User cannot log in onto the AWS Console, but uses an Access Key as long term credentials. The call to
sts:AssumeRole returns temporary security credentials that are valid for an hour. (see Controlling Permissions for Temporary Security Credentials - AWS Identity and Access Management).
Reading about Vault by HashiCorp highlighted two relevant features:
- The AWS Secret Backend has built-in support for STS AssumeRole, which allows a
POST /aws/sts/:namecall to retrieve temporary credentials (see AWS Secret Backend - HTTP API for full reference). For internal teams that use Vault, this could allow the long term credentials (from the IAM User Access Key) to be securely stored once, and server instances request temporary security credentials as needed.
- The TOTP Secret Backend allows Vault users to store their multi-factor authentication keys in Vault and use the API to retrieve time-based one-time use passwords on demand. The Using MFA with AssumeRole section of AssumeRole - AWS Security Token Service explains how can optionally include multi-factor authentication (MFA) information when you call AssumeRole. However, storage of the TOTP secret and generation of the TOTP code don’t have an implemented solution. If the secret is stored alongside the long term credentials, then it is as easy to steal two secrets, as it is one.