[openstack-dev] [tripleo] [barbican] [tc] key store in base services

Bogdan Dobrelya bdobreli at redhat.com
Thu May 17 08:18:11 UTC 2018

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/

> 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")

Best regards,
Bogdan Dobrelya,
Irc #bogdando

More information about the OpenStack-dev mailing list