I'm not sure there's a general agreement about removing the fixed key
manager code in future. It serves several purposes, testing being the most
significant one, though it also covers some people's usecase from a
security PoV too where something better might not be worth the complexity
trade off. I
On Wed, Oct 11, 2017 at 1:17 PM, Dave McCowan (dmccowan)
wrote:
> Hi Alan--
> Since a fixed-key implementation is not secure, I would prefer not
> adding it to Castellan. Our desire is that Castellan can be a best-practice
> project to encourage operators to use key management securely.
>
Hi Alan--
Since a fixed-key implementation is not secure, I would prefer not adding
it to Castellan. Our desire is that Castellan can be a best-practice project
to encourage operators to use key management securely.
I'm all for consolidating code and providing good migration paths from
Seems really well thought out. Super impressed by the level of detail here.
Consolidation of duplicated code is pretty much always a good idea in my
book. Thanks for getting this rolling.
I am happy to review as you push patches. Might also be good to get Kaitlin
Farr involved too since she knows
>
> To that end, I identified a series of small steps to get us there:
>
> 1) Unify the "fixed_key" oslo_config definitions in Cinder and Nova
> so they are identical (right now their help texts are slightly
> different). This step avoids triggering a DuplicateOptError exception
> in the next ste
There is an ongoing effort to deprecate the ConfKeyManager, but care
must be taken when migrating existing ConfKeyManager deployments to
Barbican. The ConfKeyManager's fixed_key secret can be added to Barbican,
but the process of switching from one key manager to another will need
to be done smooth