Secrets Management

Applications frequently require secrets to talk to each other. For example, in the case of a microservice talking to the database, it needs a secret such as a user-name/password to access the database. Presently, many applications store secrets in-the-clear, in code or configuration. This practice was tolerated when the microservice and database were in the private data center behind a firewall and the source code and configurations were also very tightly controlled. But when applications are distributed to the edge, where the edge gateway is not under the application owner’s control, these secrets could be compromised.


Secrets Management Features

Volterra’s solution is to provide a cryptographically secure blind-encryption technique to provide secure access to the application’s secrets. Volterra only sees an encrypted version of the secret, while the secret remains in enterprise’s control, reducing the risk of exposure. This helps IT and line-of-business comply with their CISO’s strict security policies while enabling them to deliver new services faster. A high-level overview of how this works is as follows

Scenario 1: Blindfold

Stage 1: Encrypting secret offline

The workflow for preparing the secret can be visualized as follows.

Figure 1
  • Enterprise encrypts application secret (S), for example, database password, using an offline tool provided by VoltStack Secret Management service, called vesctl. Vesctl provides the ability to enterprise to encrypt any secret, offline and on an air-gapped computer if so desired, using two attributes as inputs - Volterra policy-id and enterprise’s public key. Volterra policy-id represents the security authorization policy authorizing access to the secret for a chosen set of applications.

Stage 2: Using the secret at run-time

The workflow for using the secret can be visualized as follows.

Figure 2
  • The application uses the encrypted form of the secret (E) (i.e., the database password) in code without worrying about the secret being stolen.
  • When an application is launched, VoltStack automatically injects a security sidecar, called Wingman, into the application pod.
  • When the application wishes to use the secret, it requests Wingman, running inside the application’s pod, to decrypt the secret (E)
  • Wingman reaches out, on the application’s behalf, to VoltStack Secret Management service to decrypt the secret. Before doing so, Wingman performs a Blinding operation on encrypted secret E to transform it into W and provides W to the VoltStack Secret Management service.
  • VoltStack Secret Management service does an authentication check with Volterra Identity authority to validate the application’s identity.
  • After the application’s identity is verified, the VoltStack Secret Management service does an authorization check using the security policy (defined earlier) to determine if the particular application is authorized to access the specified secret. Note that this authorization is only possible because of Volterra generated application identity.
  • Once the request is authenticated and authorized, VoltStack Secret Management service performs a decryption operation on W to transform it into X and returns X to Wingman running in the application pod.
  • Wingman, running in the application pod, does an unblinding operation on X to transform it into a clear secret (S) and provides it to the application. Note, the secret S exists in clear, only in run-time memory of Application and Wingman (running in application’s pod), not in code.

Scenario 2: Vault and Blindfold

  • Enterprise encrypts the Vault credentials such as Vault password, using an offline tool provided by VoltStack Secret Management service, called vesctl. Vesctl provides the ability to enterprise to blind-encrypt any secret, offline and on an air-gapped computer, with two attributes as inputs - Volterra policy-id and enterprise’s public key. Volterra policy-id represents the Secret authorization policy authorizing access to a particular secret for a chosen set of applications.
  • The application can now use the encrypted form of Vault credentials in code without worrying about credentials being stolen.
  • Next, when an application is launched, VoltStack injects a security sidecar, called Wingman, into the application pod.
  • When the application wishes to use a particular secret, it requests Wingman, running inside the application’s container, to retrieve the secret from Vault. The application presents the encrypted form of Vault credentials (E) to Wingman as configuration.
  • Wingman reaches out, on the application’s behalf, to VoltStack Secret Management service to decrypt the Vault credentials. Before doing so, Wingman performs a Blinding operation on encrypted Vault credentials (E) to transform it into W and provides W to the VoltStack Secret Management service.
  • After the application’s identity is authenticated, the VoltStack Secret Management service does an authorization check using the Secret Policy (defined earlier) to determine if the application is authorized to access Vault. Note that this authorization is only possible because of Volterra generated application identity.
  • Once authenticated and authorized, VoltStack Secret Management service performs a decryption operation on W to transform it into X and provides X to Wingman running in the application container. Note that the VoltStack Secret Management service is only aware of the encrypted version of the Vault credentials.
  • Wingman, running in the application pod, does an unblinding operation on X to transform it into unencrypted Vault credentials. Next Wingman reaches out to Vault presenting the Vault credentials and requests access to the secret requested by the application. Once enterprise Vault’s security policy authorizes access to the secret, Wingman provides the secret to the application. Note, the secret exists in clear only in run-time memory of Application and Wingman, not in code.

Concepts

The following topics are used by Secret Management features. Click on each one to learn more:


How-to’s

The following How-to guides are examples of using Secret Management features: