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 https://github.com/SovereignCloudStack/issues/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 enclave^1	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.

[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^1, 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^2:

[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.

[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^1.
• Fernet is a spec that only allows up to AES128[^2]. Adding AES192 and AES256 support to Fernet was attempted 8 years ago but was never implemented^3.
• Fernet does not seem to be actively maintained, yet there are concerns about its design choices not reflecting current security recommendations anymore^4.
• Keystone also saw this as a problem^5, since its current default auth token provider is based on Fernet. As a result they introduced JWS tokens as a modern alternative.

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

[markus-hentsch]

Adding to https://github.com/SovereignCloudStack/standards/issues/509#issuecomment-1994568967 from above I had a look at the Fernet situation for Keystone in https://github.com/SovereignCloudStack/issues/issues/568#issuecomment-1997112240. Fernet uses 256 bits of key material in total because of a 128 bit signing key used in addition to the AES key. For Keystone this makes this situation benign because the encryption part is not protecting any highly sensitive information.

For Barbican, this is a bit different I think. Breaking only the AES-128 portion of the Fernet encryption might already give access to the plaintext of a secret that Barbican protected (e.g. the LUKS key to an encrypted Cinder volume). Furthermore, since these Barbican secrets are usually not rotated in contrast to Keystone's Fernet keys, an adversary is not as limited in terms of the timeframe a successfully decrypted secret is useful. In addition, having records of old data (e.g. data-at-rest encrypted blocks of a Cinder volume) and the corresponding secret, the data could still be decrypted much later using the correct LUKS key retrieved from the recorded secret after breaking the secret's Fernet encryption.

[josephineSei]

Until now, no CSP had worked on the list, I will add it again to the list of Team IaaS.

[josephineSei]

From the fact, that until now, no CSP answered to the list of Barbican Plugins, I conclude that Barbican is rarely used.

That means, we should assume that most CSPs will go from not using Barbican to using it. Upgrading from not using a KeyManager to using one is already an upgrade in security, because it provides the option to encrypt data for users. To let as many CSPs as possible get to that point, we maybe should not require certain cost-intensive plugins. Maybe we should limit us to one point: "There SHOULD NOT be a visible Barbican-Config that has the master KEK written in it." That would require any solution that stores the master-KEK somewhere else than in the Config OR requires the config to be protected (e.g. by SGX or so?)

The testing would require a manual audit regardless of what we want to standardize here - We would at least need to inspect the config + where it resides. If it is not findable or does not contain the masterKEK everything is fine.

[josephineSei]

I tried to start write a standard, but soon I thought about the fact, that most CSPs are not currently using Barbican at all.

While we should aim towards a high level of security, maybe allowing to encrypt the user data at all, would be more of a benefit than having a standard that would require CSP to either have HSM(s) or to otherwise store the MasterKEK safely (e.g. in an SGX enclave or a TPM or something similar). The latter might put too much of a financial burden upon CSPs.

Let us look at it closer:

1. Right now in many deployments the user data lays around unencrypted. An attack would simply target the storage of a deployment.
2. If using Barbican with the simple crypto plugin, the user data can be encrypted. An attacker would need access to the storage and either to the network, sniffing the key (that should be prevent by the secure communication standard) or to the Barbican config (to get the masterkek) and the Barbican database. We should acknowledge that this is an improvement compared to the first option.
3. If using Barbican with any other plugin, it is way harder to get access to the masterKEK. This would be an improvement of the second option.

We should discuss whether we need a standard here or if we maybe just want some advisory in the IAM/Security Meeting.