this post was submitted on 26 Jul 2023
1 points (100.0% liked)

DevOps

830 readers
2 users here now

Development & operations

founded 5 years ago
MODERATORS
 

Hi. We successfully store secrets in ansible variables files with either ansible-vault or sops. It is a good approach when Ansible itself configures something that requires a secret, such as configuring a database admin password.

But I'd like to ask you about how you store secrets meant to be used by applications. Example: we have a an application in PHP with a config.php file with all credentials needed by the application. Developers have a config.php setup to work with the test environment, while we maintain a different config.php for production in production machines. Nowadays this config.php file is stored in ansible repository, encrypted by ansible-vault or sops. We thought about moving the config.php production file to the application repository, so we could get advantage of the CI/CD pipeline.

It doesn't smell right, because it would require to encrypt it somehow, and store keys to decrypt it in CI/CD, but I decided to ask you anyway what do you think of that and how you solved it yourselves.

Thanks!

you are viewing a single comment's thread
view the rest of the comments
[–] thejml@lemm.ee 2 points 1 year ago

One of our apps have vault write it to a file, but rotate it regularly (like every hour or so) and have their app watch the file for updates.

Other apps query vault directly and thus it never gets written to disk. As our apps are all containerized, the password for each instance is unique and only that ephemeral container can use that password.

In fact, when the vault agent requests a password for something like a database, the agent doesn’t just share what’s in vault, but uses what’s in vault to generate a password and username that is unique to only that container and expires previous ones on a rotation.

In truth, if you had low level access to a compromised box, you could probably still sniff it out of ram or off disk, but the rotation means it’s only good for a small amount of time, and the fact that only that machine and username can use it, combined with the Least Privilege, means it’s fairly secure.