David Moreau Simard <d...@redhat.com> writes: > I don't have a horse in this race or a strong opinion on the topic, in > fact I'm admittedly not very knowledgeable when it comes to low-level > encryption things. > > However, I did have a question, even if just to generate discussion. > Did we ever consider simply leaving secrets out of Zuul and offloading > that "burden" to something else ? > > For example, end-users could use something like git-crypt [1] to crypt > files in their git repos and Zuul could have a mean to decrypt them at > runtime. > There is also ansible-vault [2] that could perhaps be leveraged. > > Just trying to make sure we're not re-inventing any wheels, > implementing crypto is usually not straightfoward.
We did talk about some other options, though unfortunately it doesn't look like a lot of that made it into the spec reviews. Among them, it's probably worth noting that there's nothing preventing a Zuul deployment from relying on some third-party secret system -- if you can use it with Ansible, you should be able to use it with Zuul. But we also want Zuul to have these features out of the box, and, wearing our sysadmin hits, we're really keen on having source control and code review for the system secrets for the OpenStack project. Vault alone doesn't meet our requirements here because it relies on symmetric encryption, which means we need users to share a key with Zuul, implying an extra service with out-of-band authn/authz. However, we *could* use our PKCS#1 style system to share a vault key with Zuul. I don't think that has come up as a suggestion yet, but seems like it would work. Git-crypt in GPG mode, at first glance, looks like it could work fairly well for this. It encrypts entire files, so we would have to rework how secrets are stored (we encrypt blobs within plaintext files) and add another file to the list of zuul config files (e.g., .zuul.yaml.gpg). But aside from that, I think it could work and may be worth further exploration. -Jim __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
