3 ms·
Have the temp token generated as part of the deployment process. This temp token can be shown in plaintext to the developer/CD machine/Chef/logs because it is
by doublerebel 10y ago
Have the temp token generated as part of the deployment process. This temp token can be shown in plaintext to the developer/CD machine/Chef/logs because it is use- and time- limited. If anything besides the new app uses the temp token, the deployment will fail and the token usage can be easily traced to the offender.
Regarding machine- or user- oriented, it just depends on whether you trust the deployer (user) or the deployment machine to authorize a new temp token.
- bogomipz 10y agoI see, that makes sense. Thanks for the good explanation.
- OhSoHumble 10y agoI'll look into this more. I'm a simple guy so hopefully my initial forays produce fruit easily. Maybe I'll luck out and there will be a blog post from someone on how to implement this specifically with AWS and Chef.
- empath75 10y agoThere's an AWS based auth method based on iam roles and ami ids. Takes a few minutes to set up. https://www.vaultproject.io/docs/auth/aws-ec2.html https://www.vaultproject.io/docs/auth/aws-ec2.html
- tonyarkles 10y agoA client of mine has a number of windows machines, and a well-organized Active Directory setup. The small group of users who need to be able to create deployment tokens are all in an AD group, and it was pretty straightforward to use the LDAP auth backend with vault to allow them to create those one-time use tokens using their normal network logins. Everyone's super impressed so far.