[openstack-dev] [tripleo] [barbican] [tc] key store in base services
cjeanner at redhat.com
Thu May 17 08:33:54 UTC 2018
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:
>> 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
>  it as well for storing k8s secrets, and kubespray does  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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the OpenStack-dev