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