Juju Secrets
James Beedy
jamesbeedy at gmail.com
Sun Jul 24 18:32:58 UTC 2016
I’ve been thinking a bit on methods of secrets management, and the
how/what/when/where/why of integrating them into my Juju deployed
applications.
Problem: Need to integrate the distribution of secrets into Juju deployed
applications. Current solution: Masterful Puppet using hiera-eyam
Hiera-eyaml allows you to encrypt a string, or file using a public key on
any machine with hiera-eyaml installed, you can then keep the
hashed/encrypted version of whatever you encrypted in your hiera.yaml on
your puppetmaster and/or in your private code repo. When the puppet agent
on a client runs, the puppetmaster then uses the private side of the key to
decrypt the value, allowing for transposition into the desired config on
the machine where the puppet agent is running.
For example, with the public key in place on your local machine, you could:
$ eyaml encrypt -l secret_password -p
[hiera-eyaml-core] Loaded config from /Users/myuser/.eyaml/config.yaml
Enter password: ******
secret_password:
ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAf/COsMMifgMoFTxvquKSGel7bC6CLLL7ysLg6qgTm1fmdOZuuqRQ9DnXk8CLEsUktxCsuiZY7vFP4fewRiVsrZAdZYw+wXgldwvEgxLZWn4GviRVsj9faH09bRVHdNMw+1RSH8KnOWczKpCO3QFqNBr7VJlQr0LuzvHbbJj5PjcduMoOx6GoiaSXAHrP8dyI7paSsOg2e/rjo3buUhg1kOiwIfoAWS3eOaQScXrfn7PtbBV+EmD5zQO0xsY8RuhssqW8gA1pioSIDlq16n+IW/TVaoIoL+nZF4+pp5ebRGSy1MvTxtT1nbgP8Qmo0GLJnshBJBYKqweyv2pJzhzd4DA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBXX5Y7m9UiY6THhS63lcoSgBAs4n18riBaaPcqcK2Pd5WH]
With hiera-eyaml installed, and the private key existing on the
puppetmaster(s), you can then keep the secret in your .yaml like so
# hiera.yaml
secret_password: >
ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAf/COsMMifgMoFTxvquKSGel7bC6CLLL7ysLg6qgTm1fmdOZuuqRQ9DnXk8CLEsUktxCsuiZY7vFP4fewRiVsrZAdZYw+wXgldwvEgxLZWn4GviRVsj9faH09bRVHdNMw+1RSH8KnOWczKpCO3QFqNBr7VJlQr0LuzvHbbJj5PjcduMoOx6GoiaSXAHrP8dyI7paSsOg2e/rjo3buUhg1kOiwIfoAWS3eOaQScXrfn7PtbBV+EmD5zQO0xsY8RuhssqW8gA1pioSIDlq16n+IW/TVaoIoL+nZF4+pp5ebRGSy1MvTxtT1nbgP8Qmo0GLJnshBJBYKqweyv2pJzhzd4DA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBXX5Y7m9UiY6THhS63lcoSgBAs4n18riBaaPcqcK2Pd5WH]
Pros
- Enhanced privacy
- Integrates seamlessly with puppet infra
Cons
- Need masterful puppetstack + gitlab
- Difficult to integrate with Juju
Considered solution: Opsworks - Custom Databags
Opsworks/chef12 has a feature called databags. Databags allow you to
specify some custom json with your secrets (or whatever) at a global level
under advanced stack configurations using the aws opsworks console gui
<http://imghub.org/image/JAmKP> (possibly this can be done through the api
… haven’t checked yet). This json is then available from your
recipes/cookbooks. Example -> elasticsearch
<https://blogs.aws.amazon.com/application-management/post/Tx3MEVKS0A4G7R5/Deploying-Elasticsearch-with-OpsWorks>
This really doesn’t seems like a great solution to me, but it gets the job
done (at the most basic level), and negates the need for a full blown
masterful puppetstack.
Pros
- Simple way to get “secrets onto machines
- Not repo based
Cons
- Dependency on Opsworks/Chef
- Doesn’t integrate well with Juju
Proposed Solution: Juju Secrets
To give Juju a combative edge on the privacy pinwheel of secrets
distribution in the realm of bleeding edge devops tooling, behold my
hypothetical proposed solution: juju secrets.
Juju secrets could be used like so:
juju add-secret mycloud:mymodel -f secrets.yaml
I know you guys are pressing hard to get 2.0 out the door, so please don’t
mind my nonsense here. I just wanted to throw the idea out there and
possibly get some feedback, and have others weigh in on this topic.
Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160724/4ee1425f/attachment.html>
More information about the Juju-dev
mailing list