By Neel Shah, member of technical staff, Cloud-Native Apps BU

An identity management system is critical to enable large-scale software systems to authenticate and authorize users, operators, and software. Traditionally, enterprise security best practices aim to establish trust at the perimeter by securing and segmenting networks. In the cloud-native space, however, security best practices shift from trusting the perimeter to trusting the workload because environments become dynamic and network boundaries thin. With this shift, operators need to take more in to consideration when designing their systems.

In this context, a workload can be a microservice, a daemon process, a container, or a Kubernetes pod. So, why should the focus be on establishing trust for the workload? Here are a few reasons:

  • Workloads can span clouds.
  • Cloud-native practices entail rapid and continuous deployments at scale.
  • The scale of a deployment can change quickly and considerably.
  • New instances of workloads come and go quickly.
  • If a single cluster or single instance of a workload is compromised, the attacker can gain access to application credentials or API keys to impersonate a workload. This information can allow a malicious user to wreak havoc throughout the system.


Certificates to the Rescue

Certificates are the solution. Cloud-native workloads heavily utilize X.509 certificates to grant identity to infrastructure, workloads, and users to establish trust.

X.509 is a standard defining the format of public key certificates. Although the X.509 certificate standard has been around and used widely for years, these certificates are now being rapidly adopted in the cloud-native space to secure communications among dynamic services. In the Kubernetes world, the two forms of credentials used are tokens and certificates.


Benefits of Certificates in Kubernetes

Here’s a list of the benefits that come from using certificates in Kubernetes:

  • All Kubernetes API clients, such as nodes and users, must be authenticated through either service accounts or X.509.
  • Certificates are created for each cluster node when a cluster starts.
  • Each cluster has its own certificate authority (CA), which is the root of all certificate operations in the cluster (issuance, verification, revocation, authentication, etc.).
  • The certificate trust bundle from the cluster CA should be automatically distributed throughout the cluster so that each cluster node can intrinsically trust each other.
  • Workloads running on top of a cluster can leverage the cluster CA for their security and identity.
  • Authentication and authorization for users and groups can be done through certificates.
  • Additional plugins can be added to Kubernetes to check access to ensure a requestor is allowed to call an API.

These properties show that X.509 is tightly coupled with the architecture and security model of Kubernetes.

Benefits of Certificates for Microservices

Cloud-native workloads frequently take the form of distributed microservices, and these services communicate over TLS-encrypted HTTPS channels. TLS is backed by X.509 certificates to provide identity information to server and client. Many applications prefer mutual TLS to provide bi-directional identity verification.

Because of the ever-changing, fluid nature of many cloud-native workloads and how they communicate, it is natural for X.509 to be a way to provide identity to workloads. With X.509, management can become much simpler—when a workload instance goes away, its certificate can be revoked, and then it will cease to be trusted.

The certificate for a new workload instance will be issued by the same certificate authority that the other instances were signed by so it will automatically be trusted by its peer instances. (In this context, an instance can be an individual service or a container within a Kubernetes pod.)

If any cluster or workload is compromised, having an X.509 certificate-backed identity source lets you minimize the intrusion and stop the malicious behavior before serious damage can occur. To clean up, you can revoke the CA that issued the identities for that cluster or workload, rendering the certificates useless to the malicious user or attacker.

X.509 Certificates in Lightwave

Project Lightwave is an open source multi-tenanted, highly available cloud directory service from VMware. One of the Lightwave services is a directory-integrated certificate authority that simplifies key management across infrastructure. This means that any user, host, or service that has joined a Lightwave domain is trusted and can get a signed certificate from the certificate authority.

With Lightwave, for instance, you can join the nodes of your Kubernetes cluster to your domain. After being joined, the Kubernetes nodes can be configured to use Lightwave as the upstream certificate authority. With this configuration, all certificate operations use the Lightwave CA as the source of truth.

This approach simplifies certificate management: The biggest prerequisite is joining the master and worker nodes to the domain. Once that is done, the node will have its own user principal, called a machine account, with which it can obtain signed certificates from the Lightwave certificate authority. The same is true of user and service accounts—after being registered in Lightwave, any principal is free to obtain signed certificates.

A rogue Kubernetes worker has not joined the Lightwave domain and thus cannot obtain a certificate from the Lightwave certificate authority (CA). Because the attacker tries to use a certificate from a third-party CA, the attempt to connect to the Kubernetes API is rejected.


Securing Communications with Lightwave

Each certificate is affinitized to an identity backed by Lightwave. All authentication can be managed through Lightwave—for example, in the case that a user password is compromised, an administrator would change the password through Lightwave and revoke issued certificates. Then, the user could request new certificates with their new password without having to take any additional steps because Lightwave takes care of synchronizing the trusted roots and certificate revocation List (CRLs) across the entire infrastructure.

In this way, Lightwave can secure communications among nodes in a Kubernetes cluster—and that’s precisely what it does for VMware Kubernetes Engine. VKE delivers Kubernetes as a VMware-managed cloud service so you can deploy, orchestrate, and scale containerized applications without the burden of implementing, operating, and maintaining Kubernetes.

The Role of Lightwave in VKE

VKE uses Lightwave behind the scenes to secure the communications of nodes in a Kubernetes cluster. If you want to see Lightwave in action, you can sign up to use VKE as a beta service; for more information or to request access to VKE, see