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

F5® Distributed Cloud Services solution is to provide a cryptographically secure blind-encryption technique to provide secure access to the application’s secrets. The solution 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.

• Enterprise encrypts application secret (S), for example, database password, using an offline tool provided by F5® Distributed Cloud App Stack 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 - F5 Distributed Cloud policy-id and enterprise’s public key. The 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.

• 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, App Stack 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 App Stack 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 App Stack Secret Management service.
• App Stack Secret Management service does an authentication check with F5 Distributed Cloud Identity authority to validate the application’s identity.
• After the application’s identity is verified, the App Stack 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 F5 Distributed Cloud generated application identity.
• Once the request is authenticated and authorized, App Stack 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.

Concepts

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

• Application Identity
• Blindfold
• Wingman
• Secret Policy