"Fossies" - the Fresh Open Source Software Archive

Member "barbican-12.0.0/doc/source/configuration/plugin_backends.rst" (14 Apr 2021, 4215 Bytes) of package /linux/misc/openstack/barbican-12.0.0.tar.gz:

As a special service "Fossies" has tried to format the requested source page into HTML format (assuming markdown format). Alternatively you can here view or download the uninterpreted source code file. A member file download can also be achieved by clicking within a package contents listing on the according byte size field. See also the latest Fossies "Diffs" side-by-side code changes report for "plugin_backends.rst": 11.0.0_vs_12.0.0.

Using Secret Store Plugins in Barbican


By default, Barbican is configured to use one active secret store plugin in a deployment. This means that all of the new secrets are going to be stored via same plugin mechanism (i.e. same storage backend).

In Newton OpenStack release, support for configuring multiple secret store plugin backends is added (Spec Link). As part of this change, client can choose to select preferred plugin backend for storing their secret at a project level.

Enabling Multiple Barbican Backends

Multiple backends support may be needed in specific deployment/ use-case scenarios and can be enabled via configuration.

For this, a Barbican deployment may have more than one secret storage backend added in service configuration. Project administrators will have choice of pre-selecting one backend as the preferred choice for secrets created under that project. Any new secret created under that project will use the preferred backend to store its key material. When there is no project level storage backend selected, then new secret will use the global secret storage backend.

Multiple plugin configuration can be defined as follows.

# Set to True when multiple plugin backends support is needed
enable_multiple_secret_stores = True
stores_lookup_suffix = software, kmip, pkcs11, dogtag, vault

secret_store_plugin = store_crypto
crypto_plugin = simple_crypto

secret_store_plugin = kmip_plugin
global_default = True

secret_store_plugin = dogtag_plugin

secret_store_plugin = store_crypto
crypto_plugin = p11_crypto

secret_store_plugin = vault_plugin

When enable_multiple_secret_stores is enabled (True), then list property stores_lookup_suffix is used for looking up supported plugin names in configuration section. This section name is constructed using pattern 'secretstore:{one_of_suffix}'. One of the plugin must be explicitly identified as global default i.e. global_default = True. Ordering of suffix and label used does not matter as long as there is a matching section defined in service configuration.


For existing Barbican deployment case, its recommended to keep existing secretstore and crypto plugin (if applicable) name combination to be used as global default secret store. This is needed to be consistent with existing behavior.


When multiple plugins support is enabled, then enabled_secretstore_plugins and enabled_crypto_plugins values are not used to instantiate relevant plugins. Only above mentioned mechanism is used to identify and instantiate store and crypto plugins.

Multiple backend can be useful in following type of usage scenarios.