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?
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
