Standardize List of allowed Barbican Plugins

[josephineSei]

Barbican is used to store secrets for encrypted resources in OpenStack. To store those secrets different plugins / backends can be used. For security issues, we should not allow all possible plugins.
E.g. there is the simply crypto plugin, that simply stores the Master KEK in the config file, and all other secrets in the database, which makes it easy to access all secrets.

Most likely testing this will be only possible through audits, as this is something configuration specific and/or deployment specific.

Definition of Done:

• Proposal has been written with name of the form scs-xxxx-v1-slug.md (only substitute slug)
• Proposal has the fields status, type, track set
• Proposal has been voted upon in the corresponding team
• Status has been changed into Draft, file renamed: xxxx replaced by document number
• If applicable: test script has been written (this item may be moved into a separate issue so long as the state is Draft)

[josephineSei]

As we will at least support Barbican (see issue SovereignCloudStack/issues#528), we should also require or at least advice some configuration of Barbican.

[josephineSei]

At first I have to note, that it is better to use encryption with a not-optimal backend than to not use encryption at all.

There is the possibility to configure multiple plugins: https://docs.openstack.org/barbican/latest/configuration/plugin_backends.html
-> this adds a lot of complexity to this issue, as we have to do a deep dive into the correct choosing of backend.

The Plugins are described here: https://docs.openstack.org/barbican/latest/install/barbican-backend.html
Plus: There is the possibility to use a software HSM instead of a hardware one.

Plugin	Master KEK store	alternative	possible security risk
simple crypto	config file	config and Barbican processes in enclave1	vulnerable controller Host
PKCS#11	HSM	-	HSM access
KMIP	KMIP device	-	access info in config file
Dogtag	HSM	software-based NSS security database	access info in config file
Vault	Vault	-	access info in config file

We should evaluate the usage of the different Plugins through the CSPs.

The problem is also the testing of this issue: We would need to audit the config file used for Barbican in the deployment to know exactly which plugin is used. But doing so would compromise the security of Barbican, as information from this file should not be available to anyone outside the few operators of the CSP.

My conclusion is, that in regards of the lack of possible testing, we could only give some recommendation to CSPs. And we should only do so, if we find, that we want to exclude one of the plugins OR if we want to rather give advice on how to rise the protection level of the config files / controller nodes / wherever Barbican is executed.

Footnotes

1. https://www.youtube.com/watch?v=vh-Q9HWdYsQ ↩

[mbuechse]

First of all: very instructive and intriguing!

Second: I know I'm probably rather obnoxious by now, but I'm still wondering how much of this is relevant to the user, and how much is only relevant to the operator. As you already pointed out, we can provide advice on how to configure Barbican (or, maybe more importantly, how not to do it), but I'm not sure if this is a standard then. Maybe it can be attached to some standard as a Supplement.

At any rate, I would expect participating CSPs to gather around in the SCS community and exchange their best-practice knowledge. We can of course encourage them to codify this knowledge.

[mbuechse]

I recall our k8s versioning policy stating something about a time window for applying critical patches for CVEs. I guess this is something that we can require: to not use plugins that are deficient.

[josephineSei]

I created a hedgedoc to gather CSP answers for the usage of Barbican and their Plugins.
This is now the correct link: https://input.scs.community/Xy5SLtTjQAqn-fgliIFp3A

[markus-hentsch]

@mbuechse

I know I'm probably rather obnoxious by now, but I'm still wondering how much of this is relevant to the user, and how much is only relevant to the operator.

From my point of view, Barbican serves at least up to two key roles in an OpenStack environment:

1. Managing and securely generating as well as storing the encryption keys for the data-at-rest encryption for volumes in Cinder.
2. Securely storing user-specific secrets a user chooses to store in Barbican via its Key Manager API. Users can also have random secrets generated for them using this API¹, effectively using Barbican as a secrets generator.

In both cases the user has to trust in the cryptographic capabilities and integrity of Barbican. The source (entropy) quality of randomness for secret generation and the protection mechanisms for the stored secret assets are crucial for this.

The actual implementation varies greatly between the available Barbican plugins. For example, the Security Guide states²:

[The simple crypto plugin] is considered a less secure option and is only suitable for development and testing as the master key is stored within a config file in plain text, and is therefore not recommended for use in production deployments.

This means, simply offering Barbican (and the Cinder volume encryption) to the user in an OpenStack cloud does not tell the user anything about the underlying security quality in terms of key management, currently. We could attempt to change that in SCS with a standard establishing some guarantees about the Barbican configuration (if feasible) that a SCS customer can rely on. I think this could differentiate SCS from a generic OpenStack cloud with arbitrary Barbican configuration.

Footnotes

1. https://docs.openstack.org/barbican/latest/api/reference/orders.html#post-v1-orders ↩

2. https://docs.openstack.org/security-guide/secrets-management/barbican.html ↩

[mbuechse]

@markus-hentsch I don't disagree ;)

What I wanted to achieve: instead of naming specific plugins, rather make an abstract set of requirements, which can then be used to evaluate the plugins and to derive whether they are compliant or not.

[markus-hentsch]

Remarks about the cryptography implementation (Fernet) used by the "simple crypto" plugin:

• The simple crypto plugin uses Fernet to implement the key encryption of stored secrets¹.
• Fernet is a spec that only allows up to AES128². Adding AES192 and AES256 support to Fernet was attempted 8 years ago but was never implemented³.
• Fernet does not seem to be actively maintained, yet there are concerns about its design choices not reflecting current security recommendations anymore⁴.
• Keystone also saw this as a problem⁵, since its current default auth token provider is based on Fernet. As a result they introduced JWS tokens as a modern alternative.

Footnotes

1. https://github.com/openstack/barbican/blob/a00fcade4138ffc52cd9c84b5999297966f019b5/barbican/plugin/crypto/simple_crypto.py#L86 ↩

2. https://cryptography.io/en/latest/fernet/#implementation, https://github.com/fernet/spec/blob/20dead475f53f11d20592baf29ad697163afc0cd/Spec.md ↩

3. https://github.com/fernet/spec/pull/17 ↩

4. https://github.com/fernet/spec/issues/8 ↩

5. https://specs.openstack.org/openstack/keystone-specs/specs/keystone/stein/json-web-tokens.html#problem-description ↩