Open Stack

On 05/17/2018 10:18 AM, Bogdan Dobrelya wrote:
> On 5/17/18 9:58 AM, Thierry Carrez wrote:
>> Jeremy Stanley wrote:
>>> [...]
>>> As a community, we're likely to continue to make imbalanced
>>> trade-offs against relevant security features if we don't move
>>> forward and declare that some sort of standardized key storage
>>> solution is a fundamental component on which OpenStack services can
>>> rely. Being able to just assume that you can encrypt volumes in
>>> Swift, even as a means to further secure a TripleO undercloud, would
>>> be a step in the right direction for security-minded deployments.
>>>
>>> Unfortunately, I'm unable to find any follow-up summary on the
>>> mailing list from the aforementioned session, but recollection from
>>> those who were present (I had a schedule conflict at that time) was
>>> that a Castellan-compatible key store would at least be a candidate
>>> for inclusion in our base services list:
>>>
>>> https://governance.openstack.org/tc/reference/base-services.html
>>
>> Yes, last time this was discussed, there was lazy consensus that
>> adding "a Castellan-compatible secret store" would be a good addition
>> to the base services list if we wanted to avoid proliferation of
>> half-baked keystore implementations in various components.
>>
>> The two blockers were:
>>
>> 1/ castellan had to be made less Barbican-specific, offer at least one
>> other secrets store (Vault), and move under Oslo (done)
> 
> Back to the subject and tripleo underclouds running Barbican, using
> vault as a backend may be a good option, given that openshift supports
> [0] it as well for storing k8s secrets, and kubespray does [1] for
> vanilla k8s deployments, and that we have openshift/k8s-based control
> plane for openstack on the integration roadmap. So we'll highly likely
> end up running Barbican/Vault on undercloud anyway.
> 
> [0]
> https://blog.openshift.com/managing-secrets-openshift-vault-integration/
> [1]
> https://github.com/kubernetes-incubator/kubespray/blob/master/docs/vault.md
> 

That just sounds lovely, especially since this allows to converge
"secure storage" tech between projects.
On my own, I was considering some secure storage (custodia) in the
context of the public TLS certificate storage/update/provisioning.
Having by default a native way to store secrets used by the overcloud
deploy/life is a really good thing, and will prevent leaks, having
ardcoded passwords in files and so on (although, yeah, you'll need
something to access barbican ;)).

>>
>> 2/ some projects (was it Designate ? Octavia ?) were relying on
>> advanced functions of Barbican not generally found in other secrets
>> store, like certificate generation, and so would prefer to depend on
>> Barbican itself, which confuses the messaging around the base service
>> addition a bit ("any Castellan-supported secret store as long as it's
>> Barbican")
>>
> 
> 

-- 
Cédric Jeanneret
Software Engineer
DFG:DF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180517/516be284/attachment.sig>