AWS Security Maturity Roadmap [pdf]
summitroute.com
summitroute.com
I am slightly shocked by the number of seemingly incompatible ways to secure our new cloud environments and want to look around before i throw out authid
Just as part of what I am trying to read around on::
The "dynamic secrets" feature of Vault is ideal for scripts: an AWS access key can be generated for the duration of a script, then revoked. The keypair will not exist before or after the script runs, and the creation of the keys are completely logged.
This is an improvement over using something like Amazon IAM but still effectively hardcoding limited-access access tokens in various places. https://www.vaultproject.io/docs/use-cases
Now I like that idea ... but where does it sit on the spectrum of good and bad?
I'm not totally sure what your goals are, or the overall context, but a few issues with this approach:
You can only create these access keys for IAM users, and each user can only have two keys at a time. So if you're using this as a "service account", you pretty much have to have an IAM user for each task. If you need to scale to 100 concurrent tasks, that's either going to take up 50-100 IAM users (from your limited quota) or you're going to have to figure out some other scheme for managing lifecycle of access keys.
Instead, just use IAM roles and sts:AssumeRole into the role. You can sts:AssumeRole as many times as you want, there is no limit to how many 'tasks' you can have assuming the same role at a time. Credentials from sts:AssumeRole are inherently time-limited (and you can set a tighter expiration than the default) and you can additionally constrain what the resulting credentials can do with the `policies` or `policyarns` parameter. The role assumption is logged and you can impute the expiration of the assumption from the sts:AssumeRole event (because it either includes the DurationSeconds parameter value or you can assume the default).