Re: [openstack-dev] [OpenStack-Infra] [infra][security] Encryption in Zuul v3
David Moreau Simard 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
Re: [openstack-dev] [OpenStack-Infra] [infra][security] Encryption in Zuul v3
On Tue, Mar 21, 2017 at 6:10 PM, James E. Blair wrote: > David Moreau Simard 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 __ 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
Re: [openstack-dev] [OpenStack-Infra] [infra][security] Encryption in Zuul v3
On 03/22/2017 06:10 AM, Ian Cordasco wrote: > On Tue, Mar 21, 2017 at 6:10 PM, James E. Blair wrote: >> David Moreau Simard 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) __ 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
Re: [openstack-dev] [OpenStack-Infra] [infra][security] Encryption in Zuul v3
Ian Cordasco writes: > On Tue, Mar 21, 2017 at 6:10 PM, James E. Blair wrote: >> 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? Right -- we don't want to require another service or tie Zuul to an authn/authz system for a fundamental feature. However, I do think we can look at making integration with Barbican and similar systems an option for folks who have such an installation and prefer to use it. -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
Re: [openstack-dev] [OpenStack-Infra] [infra][security] Encryption in Zuul v3
On 22 March 2017 at 15:02, James E. Blair wrote: > Ian Cordasco writes: > > > > > I suppose Barbican doesn't meet those requirements either, then, yes? > > Right -- we don't want to require another service or tie Zuul to an > authn/authz system for a fundamental feature. However, I do think we > can look at making integration with Barbican and similar systems an > option for folks who have such an installation and prefer to use it. > > -Jim > Sounds like you're going to make this plugable, is that a hard requirement that will be added to the spec? or just a possibility? -- Darragh Bailey "Nothing is foolproof to a sufficiently talented fool" __ 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
Re: [openstack-dev] [OpenStack-Infra] [infra][security] Encryption in Zuul v3
Darragh Bailey writes: > On 22 March 2017 at 15:02, James E. Blair wrote: > >> Ian Cordasco writes: >> >> > >> > I suppose Barbican doesn't meet those requirements either, then, yes? >> >> Right -- we don't want to require another service or tie Zuul to an >> authn/authz system for a fundamental feature. However, I do think we >> can look at making integration with Barbican and similar systems an >> option for folks who have such an installation and prefer to use it. >> >> -Jim >> > > Sounds like you're going to make this plugable, is that a hard requirement > that will be added to the spec? or just a possibility? More of a possibility at this point. In general, I'd like to off-load interaction with other systems to Ansible as much as possible, and then add minimal backing support in Zuul itself if needed, that way the core of Zuul doesn't become a choke point. -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
