Open Stack

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)