|
|
|
|
|
|
by curun1r
3940 days ago
|
|
|
> So, how do you propose to handle version control of your exact production configuration? Version control is perfectly acceptable for that, but the key point is that access keys aren’t part of your production configuration. I personally don’t allow my team to have long-lived AWS access keys that have access to production. Production is only changed via an assumed role requiring MFA or an IAM instance role. If this kind of setup is too complex to create on your own, solutions like Vault (https://vaultproject.io) can make it much easier to get right. |
|
|
Why not? If your production configuration is stored as static-file in version control, then either those credentials have to live in that version control, or they have to live outside it, as a separately-backed up file of configuration variables, which are then fed to a static-file-generating tool, which means a) that one has to select a templating system and maintain those separate templates and b) that there's another step involved in developing the prototypes for those templates. This isn't a bad course of action, of course, but it does have its costs (just like storing production configuration—including credentials—in version control has its costs as well as its benefits).
> I personally don’t allow my team to have long-lived AWS access keys that have access to production.
Of course! Developers shouldn't have access to production systems, period. But operators can, and must, and I've no problem with them having access to their own version-controlled repository of information that no other team can access.
> Production is only changed via an assumed role requiring MFA or an IAM instance role.
Of course! I'm certainly not arguing for personal credentials to be stored in an operations repo.