"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 using (guessed) reStructured Text source code syntax highlighting (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 Using Secret Store Plugins in Barbican
    2 ======================================
    5 Summary
    6 -------
    8 By default, Barbican is configured to use one active secret store plugin in a
    9 deployment. This means that all of the new secrets are going to be stored via
   10 same plugin mechanism (i.e. same storage backend).
   12 In **Newton** OpenStack release, support for configuring multiple secret store
   13 plugin backends is added (`Spec Link`_). As part of this change, client can
   14 choose to select preferred plugin backend for storing their secret at a project
   15 level.
   18 .. _Spec Link: https://review.opendev.org/#/c/263972
   21 Enabling Multiple Barbican Backends
   22 -----------------------------------
   24 Multiple backends support may be needed in specific deployment/ use-case
   25 scenarios and can be enabled via configuration.
   27 For this, a Barbican deployment may have more than one secret storage backend
   28 added in service configuration. Project administrators will have choice of
   29 pre-selecting one backend as the preferred choice for secrets created under
   30 that project. Any **new** secret created under that project will use the
   31 preferred backend to store its key material. When there is no project level
   32 storage backend selected, then new secret will use the global secret storage
   33 backend.
   35 Multiple plugin configuration can be defined as follows.
   37 .. code-block:: ini
   39     [secretstore]
   40     # Set to True when multiple plugin backends support is needed
   41     enable_multiple_secret_stores = True
   42     stores_lookup_suffix = software, kmip, pkcs11, dogtag, vault
   44     [secretstore:software]
   45     secret_store_plugin = store_crypto
   46     crypto_plugin = simple_crypto
   48     [secretstore:kmip]
   49     secret_store_plugin = kmip_plugin
   50     global_default = True
   52     [secretstore:dogtag]
   53     secret_store_plugin = dogtag_plugin
   55     [secretstore:pkcs11]
   56     secret_store_plugin = store_crypto
   57     crypto_plugin = p11_crypto
   59     [secretstore:vault]
   60     secret_store_plugin = vault_plugin
   62 When `enable_multiple_secret_stores` is enabled (True), then list property
   63 `stores_lookup_suffix` is used for looking up supported plugin names in
   64 configuration section. This section name is constructed using pattern
   65 'secretstore:{one_of_suffix}'. One of the plugin **must** be explicitly
   66 identified as global default i.e. `global_default = True`. Ordering of suffix
   67 and label used does not matter as long as there is a matching section defined
   68 in service configuration.
   70 .. note::
   72    For existing Barbican deployment case, its recommended to keep existing
   73    secretstore and crypto plugin (if applicable) name combination to be used as
   74    global default secret store. This is needed to be consistent with existing
   75    behavior.
   77 .. warning::
   79    When multiple plugins support is enabled, then `enabled_secretstore_plugins`
   80    and `enabled_crypto_plugins` values are **not** used to instantiate relevant
   81    plugins. Only above mentioned mechanism is used to identify and instantiate
   82    store and crypto plugins.
   84 Multiple backend can be useful in following type of usage scenarios.
   86 * In a deployment, a deployer may be okay in storing their dev/test resources
   87   using a low-security secret store, such as one backend using software-only
   88   crypto, but may want to use an HSM-backed secret store for production
   89   resources.
   90 * In a deployment, for certain use cases where a client requires high
   91   concurrent access of stored keys, HSM might not be a good storage backend.
   92   Also scaling them horizontally to provide higher scalability is a costly
   93   approach with respect to database.
   94 * HSM devices generally have limited storage capacity so a deployment will
   95   have to watch its stored keys size proactively to remain under the limit
   96   constraint. This is more applicable in KMIP backend than with PKCS11 backend
   97   because of plugin's different storage approach. This aspect can also result
   98   from above use case scenario where deployment is storing non-sensitive (from
   99   dev/test environment) encryption keys in HSM.
  100 * Barbican running as IaaS service or platform component where some class of
  101   client services have strict compliance requirements (e.g. FIPS) so will use
  102   HSM backed plugins whereas others may be okay storing keys in software-only
  103   crypto plugin.