Application Identity

A fundamental tenet for the application security offering of F5® Distributed Cloud Services is Zero Trust, which requires a verifiable identity for every application managed.

At present, applications are typically identified by a combination of IP address and port or DNS entry. However, there is no method to verify if the application is indeed the one it is claiming to be, based on its IP address or DNS entry. Moreover, IP address-based identity is not global across heterogeneous locations - private/public cloud and edge sites. In a microservices world, applications could restart or a new replica may be created, potentially in a different location, with a completely different IP address. On the server-side, a database will accept connections from any client with the user-name/password; it cannot selectively accept a connection from one application and reject another, because the database cannot identify the source of the connection, i.e., it does not have an identity for the application. To solve this problem, enterprises configure gigantic IP address lists, that instruct the database to accept connections from whitelisted IPs. This method of manually managing IP addresses does not scale when thousands of applications are deployed on the edge, still connecting back to centralized databases. The operational model to deal with changing IP addresses becomes extremely complex and brittle in a scaled environment.

Application Identity Features

The solution is to provide an X.509 certificate-based identity tied to the application service name and application attributes. This identity is generated by the F5 Distributed Cloud’s Identity Authority, a certificate authority, provided as-a-service as part of the F5® Distributed Cloud App Stack Application Identity service. Since a certificate is provided to every application instance launched, the application’s identity is cryptographically verifiable. Moreover, the F5 Distributed Cloud-provided application identity is decoupled from environment parameters such as IP address and port and is therefore globally unique.

The benefit of Application identity to enterprises is the ability to define intent aware application policies that are universally applicable across multiple deployment environments. E.g., the App of type X is prohibited from communicating with the App of type Y. This intent aware policy is applicable across public/private, network and edge clouds; there is no need to maintain a large list of IP addresses per deployment environment. The Application identity service manages the life-cycle of X.509 identity for each application instance by automatically performing certificate rotation based on CISO’s policies, reducing the burden on operational teams and eliminating human errors.

The process for generating an X.509 certificate for an application is described next.

1. When a customer deploys an app to their fleet, App Stack control plane informs local control plane on each site of the fleet to create a pod
2. Site control plane invokes an identity webhook during the POD creation process
3. The webhook checks if the POD contains Wingman, a security side-car. If not, the webhook inserts Wingman. In addition, it also generates a security document, a JSON token, that is extremely short-lived (order of minutes).
4. Customer POD is created with Wingman as the security side-car and security doc.
5. Wingman provides a security doc to Identity Authority (IA) and requests a certificate for the specific POD instance.
6. Identity Authority (IA) provides an instance certificate to Wingman. This instance certificate resides in Wingman’s memory and is valid for the lifetime of the instance.
7. Next Wingman provides instance certificate to Identity Authority and requests for a system-wide identity.
8. Identity Authority provides a passport certificate, a PKI certificate that is used by the POD as the system-wide identity. The passport certificate resides in the customer’s POD and is shared by all containers in the POD.

Application’s identity is used for several purposes:

1. mTLS encryption of the communication between applications.
2. Retrieving of application secrets. Application secrets could be stored in Vault, for example, an application’s identity is used to authorize access to the secret. To learn more, please refer to Secrets Management.
3. Accessing keys stored in the Key management service (KMS) for purposes of encryption, decryption, and HMAC. To learn more, please refer to Key Management Service (KMS).

Concepts

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

• Application Identity
• Wingman
• Secret Policy