[openstack-dev] [Barbican] Multiple KMIP servers on a single barbican
john.wood at RACKSPACE.COM
Wed Jun 10 00:20:11 UTC 2015
I defer to Nate and Kaitlin for things KMIP.
>From a config perspective though, it seems that something needs to decide which KMIP backend handles which secret. Where ever that decision-making logic lives (in Barbican or in a proxy that Barbican talks to), it has to know what KMIP backends are available. If this list of backends is known/static then it seems that storing these in a config file (like barbican-api.conf) would be acceptable. Keep in mind that more than one Barbican API node might be hitting the same KMIP backends concurrently.
As for multiple plugins in Barbican, the current approach favors having an instance per plugin class, so IMHO it would be better to have a single multi-KMIP plugin class that handles the above decision logic. This would most likely be your 'active' secret store plugin.
From: Christopher N Solis <cnsolis at us.ibm.com<mailto:cnsolis at us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Friday, June 5, 2015 at 12:41 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [Barbican] Multiple KMIP servers on a single barbican
I wanted to get people's opinion on allowing barbican to talk to multiple KMIP servers.
I got good advice from Nathan and John and it seems like it would be pretty easy keeping track of
which secret resides in which KMIP applicance. You would just store the url in the DTO.
However, in order for barbican to be aware of all KMIP servers wouldn't that mean that each
kmip server url would need to be in the barbican-api.conf file? Or somewhere for barbican
to know that multiple kmip servers are available? I noticed that there is a blueprint to introduce
the concept of a single active and multiple inactive secret store plugins so I'm trying to stray away from
making multiple active plugins.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev