listen to this article:

Vault Secret Management

As many start to realize the damaging potential of a major security breach, different sets of vault-like tools begin to emerge in the Cloud-Native eco-system. Logical vaults, as their physical predecessors, securely store the secrets while within the vault. They encrypt the data while at rest within the vault as well as using TLS for encrypting the secret while being transferred from the vault to the application.

Although utilization of such tools is far better than simply coding the secret into the source code, still severe security implications arise from the way they’re typically being used.

Why Cryptographic Vaults Represent Security Risks

Decryption from Same Storage Key

When an application needs to use a certain secret stored within the vault (e.g. a code signing key, database encryption key, connection string to a database containing sensitive information), it first has to authenticate itself with the vault by providing proper credentials.

Once the access request is authenticated by the vault it reads the secret data from its storage and decrypts it with a key stored on the same storage, or rarely in an external HSM. For the experienced security professional, this already raises a red flag, as this opens a possibility to compromise the key to the vault and obtain access to its whole content. Obfuscation methods that may be used to protect this key, can only slow down an attacker, but cannot prevent the breach.

Decryption at the Application

After decrypting the secret (either using an HSM or a local key), the vault provides it to the application in a secure manner via TLS, so it can be decrypted only by the application. However, the TLS-secured communication is decrypted at the application, the secret that we worked so hard to protect suddenly becomes available in clear text, and can be harvested, opening an easy and lucrative attack surface for the potential adversary.

This is a major security issue, with a broad effect on cloud-native applications, as cryptographic keys, credentials, and secrets are not strongly secured and exposed while in use. It strongly contrasts with private keys and credentials in traditional environments that are typically secured in hardware like HSM/TPM, especially in medium to high trust use cases.

This broadly practiced modus operandi opens a possibility for a skilled intruder to intercept secrets used by Cloud-Native applications. The security implication of revealing such secrets ranges from the relatively low impact of an attacker compromising a username and password for a low importance system, and steeply rising with gaining access to admin credentials, API tokens, or private encryption keys that can lead to leaking personally identifiable information on a large scale.

Lack of Centralized Secrets Management

In addition, direct passing of the secrets to the applications creates an auditing nightmare, as there is no possibility to trace the usage of a certain secret by the requesting applications in a centralized manner.