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

DevOps

830 readers
1 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
[–] [email protected] 1 points 1 year ago (1 children)

You can probably write a utility in your PHP that just pulls the value from Ansible Vault and decrypts at runtime. Still not 100% secure but better than having the value in plaintext in your config.php.

[–] [email protected] 2 points 1 year ago (1 children)

Thanks. I would still have to store ansible-vault password locally or something like that, no?

[–] [email protected] 3 points 1 year ago

Yeah, or just continue to have two separate config files.

My team is in a bit of a different situation as we are cloud hosted but I suspect it's a similar approach. We have secrets hosted in AWS and our config file just references the secret name. We then have a SecretReader utility in our code which we reference to pull the secret from AWS at runtime, that way it doesn't show up as plaintext in our code. Our CI/CD doesn't touch the secret at all in that use case -- we only use secrets in our CI/CD if there is a step such as connecting to a DB that is part of our pipeline.