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
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
