Open Stack

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?

-- 
Ian Cordasco