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)

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

Thierry Carrez (ttx)

OpenStack Development Mailing List (not for usage questions)

Reply via email to