Whether you're following your internal information security policy or trying to meet regulatory requirements such as GDPR, ANSSI, PCI DSS, HIPAA, or NIST, you are likely looking for ways to protect the privacy and integrity of your data and software. That solution can be found in encryption. OpenStack provides all the ingredients necessary to deploy privacy and integrity solutions, but it is up to the operator to deploy them securely. This requires a key-management solution (KMS) to manage and protect the encryption keys.
Barbican is the OpenStack service that allows operators and users to manage and store secrets securely. It consists of an OpenStack API that provides keystone authentication, oslo.policy and quotas, and backends where the secret is stored. But secrets are only as secure as the storage backend deployed behind Barbican. This article will discuss Barbican deployment options and explore how each affects the security of your cloud.
User profiles, threats, and requirements
When evaluating key management options, there are a number of factors to consider. Depending on the use case, different criteria will carry different weights.
The first criterion is the solution's security. There should be an access policy so only authorized users have access to keys and an associated audit trail. The security of the keys (and the master keys that protect them) should be understood. Some choices will be certified as compliant to different standards, such as FIPS, while others may not. There must be protection from both tampering and eavesdropping.
Second, the KMS should be able to perform in the face of stress or failure. The key storage's availability, durability, and scalability should be considered. Ideally, key material will still be available during a hardware, software, or connectivity failure.
Finally, there are business factors to consider, including total price, ease of use, and compatibility with existing infrastructure.
With all these factors in mind, let's compare different Barbican deployment options.
Architecture
The first deployment consideration is Barbican's architecture. Like other OpenStack services, Barbican is composed of an API server, a database, and backends reachable via configurable plugins. An important design goal is the principle of least privilege. The key management administrator should have different access than the storage or compute administrator. Separating the encrypted and signed data and software from the encryption keys achieves this goal and increases the cloud's security. While it is common practice to colocate API services and share a common database among OpenStack services, it is best practice to separate Barbican from the services that use it.
Secure storage options
Secret store plugins allow Barbican to interact with a backend to store, generate, and retrieve secrets. There are two main types.
The first allows Barbican to interact with an external KMS like Hashicorp Vault or the Dogtag Key Recovery Authority to store secrets. To Barbican, the external KMS is essentially a secure black box. Barbican interacts with the KMS using the KMS's API and provided credentials and stores extra information in the Barbican database, like a reference ID, that enable it to access the secret later.
These plugins provide logical and privilege separation because the secrets are stored in an entirely separate application, often on a separate server on a dedicated network. Moreover, the system as a whole can be easier to certify as compliant with standards like Common Criteria because you could restrict the target of evaluation (TOE).
Crypto plugins are the second type of secret store plugins. They encrypt the secrets and store them directly in the Barbican database. They can offer performance benefits because they don't require Barbican to access an external KMS. Crypto plugins can provide privilege separation as long as the database admin does not have access to the encryption keys.
Let's look at some of the available plugins in more detail.
4 crypto plugins
Simple crypto plugin
Simple crypto is the simplest plugin and the one tested with devstack in the upstream gates. It is also the default, out-of-the-box secret store plugin. All secrets are encrypted by an AES-256-bit key, the key encryption key (KEK), stored in the Barbican configuration file.
This plugin is not only the simplest but probably also the most performant. On the other hand, it has significant shortcomings. First, since a single key is used for all encryption, if that KEK is compromised, all secrets from all tenants in the database are at risk. Moreover, it is impossible to rotate this key without re-encrypting all existing secrets.
PKCS#11 plugin + HSM
PKCS#11 is one of the most versatile plugins. It speaks PKCS#11 to a hardware security module (HSM), such as those from Yubikey, Thales, Safenet, or ATOS.
While the simple crypto plugin uses a single key, PKCS#11 uses several keys. The HSM stores two master keys: the master encryption key (MKEK) and the master HMAC signing key. Then the HSM uses these keys to encrypt and sign individual tenant key encryption keys (pKEKs). The pKEKs are used to encrypt secrets for each tenant. Finally, those encrypted values are stored in the Barbican database.
This is significantly better security than simple crypto. First, different tenants use different pKEKs to encrypt their secrets, so the compromise of one tenant's pKEK does not affect other tenants. In addition, key rotation is a lot simpler than for simple crypto. When the MKEK is rotated, only the pKEKs, and not every secret, need to be re-encrypted.
Second, all cryptographic operations take place within the cryptographic device's memory because the pKEKs are all encrypted by the MKEK, which is never extracted from the HSM. Physical HSMs provide auditing, tamper detection, and tamper resistance and have sufficiently random entropy sources to generate keys. They usually also restrict cryptographic algorithms and keys to meet Common Criteria, FIPS 140-2, or other standards.
But they can be expensive and may need to be tuned for optimal performance. If you can get by with lower performance or security guarantees, Yubikey or software-based HSM may be less expensive options.
PKCS#11 + software HSM
The software-based HSM, originally a project from the DNSSEC group, is a software implementation of a cryptographic device that communicates using PKCS#11. Like the hardware-based HSM, it uses a multiple-key approach. This includes a master key and a key encryption key, which is decrypted by the master key. The encryption keys and other artifacts are stored in files in the filesystem.
Using the PKCS#11 plugin with the software HSM does not provide the auditing, tamper protection, and security certifications of a hardware HSM. It does, however, offer significant improvements over simple crypto in that it allows easier key rotation and per-project KEKs.
There are plans in the OpenStack Stein cycle (now in development) to include a test gate in upstream continuous integration (CI) for this configuration.
SGX
Intel SGX is a new processor technology that allows applications to create secure areas in memory called enclaves. These enclaves provide applications with a trusted execution environment where confidentiality and integrity of any code and data inside the enclave are protected inside the CPU package boundary.
Intel has proposed creating a Barbican crypto plugin that can perform the secret encryption operations within that security boundary and store the encrypted secrets in the Barbican database.
This security feature and comparatively low cost would make this plugin an attractive solution. However, the code for the Barbican plugin and changes to the Barbican API have not yet been proposed to the open source Barbican project.
3 external KMS plugins
KMIP
The KMIP plugin, like the PKCS#11 plugin, uses an HSM to help secure the secrets. The difference is the KMIP plugin's encrypted secrets are stored directly on the HSM. This provides an even stronger security posture while potentially decreasing performance and scalability and increasing costs.
Hashicorp Vault
Vault is an open source secret-management tool sponsored by Hashicorp. It has become popular over the last few years because of its easy development setup and flexible configuration. Multiple authentication plugins exist (although not for keystone tokens), as well as multiple storage backends.
The Barbican vault plugin was introduced in the OpenStack Rocky cycle (August 2018) and is routinely tested in the Barbican upstream gate. It allows Barbican to store its secrets inside Vault. The Vault master key is used to encrypt the secrets, and it's easy to do key rotation.
The plugin is, however, not quite ready for production use. The biggest deficiencies are that authentication is done using the Vault root user (which is not a recommended security practice) and all secrets are stored uncategorized at the top level. There are efforts in Stein to address these deficiencies.
Dogtag
The Dogtag Key Recovery Authority (KRA) is a component of FreeIPA used to store secrets, with the master keys either in an NSS database or an HSM. Barbican stores secrets directly in the Dogtag KRA. Dogtag provides FIPS and other certifications and can be a good option for deployers that already have a FreeIPA deployment.
Tips for choosing the right secret storage
Choosing the secret storage behind Barbican is an important decision that will affect the security, performance, scalability, and cost of your secret management system. There are many factors to consider that will be specific to your needs.
Users with regulatory requirements or existing HSMs will gravitate toward the KMIP or PKCS#11 plugin. Users with tight budgets will look closely at software-only options. Those with high performance needs will look to crypto plugins.
Luckily, Barbican supports multiple plugins, which can be useful if your needs change later. It can also allow different secrets with different requirements to be stored by different plugins.
Ade Lee and Dave McCowan will present Are Your Secrets Secure? at the OpenStack Summit, November 13-15 in Berlin.
Comments are closed.