[openstack-dev] [OpenStack-Infra] [infra][security] Encryption in Zuul v3

Monty Taylor mordred at inaugust.com
Wed Mar 22 11:23:49 UTC 2017

On 03/22/2017 06:10 AM, Ian Cordasco wrote:
> On Tue, Mar 21, 2017 at 6:10 PM, James E. Blair <corvus at inaugust.com> wrote:
>> David Moreau Simard <dms at 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.
> I suppose Barbican doesn't meet those requirements either, then, yes?

It doesn't - because we explicitly want the secrets to be in git so that
they can be submitted as part of a proposed change. Even so, if we
wanted to go some other route, such as having an API that users used to
add secrets, barbican would be more of a backend zuul secret storage
possibility, and less an interface we'd hand to zuul's users. (also,
none of our clouds have barbican)

More information about the OpenStack-dev mailing list