5 Methods for Kubernetes Application Access Control

As Kubernetes adoption increases, so too, has the need for developers to put more secure access controls and authentication in place to protect their containerized applications. Let’s take a look at some of the most effective methods for implementing authentication protections and how to integrate them with Kubernetes.

Authentication Method Options

LDAP

FinConDX 2021

Many enterprises have plenty of experience storing user and other organizational information using a directory service such as Active Directory. Most systems like this adhere to the open Lightweight Directory Access Protocol (LDAP) protocol standard. Integrating applications with LDAP authentication enables seamless user verification via information managed by an IT department. Additionally, LDAP allows access control to be enforced based on specific policies and groups. LDAP integrations are particularly well-suited to applications handling internal-facing and line-of-business workloads.

OAuth 2.0

The absence of a unifying authentication solution can leave users logging into multiple unique accounts to access third-party web applications. This scenario isn’t scalable nor preferable. To address the issue, OAuth 2.0 enables users to approve delegated access for applications. This method utilizes existing identity providers—such as a Google account—to achieve authentication while also controlling the data shared with third-party applications. The OAuth 2.0 protocol, often leveraged within authentication flows, are implemented in tools such as OpenID Connect.

JSON Web Token (JWT)

JSON web tokens have emerged as a popular authentication method, especially for use with APIs. JSON web tokens are Base64URL-encoded JSON objects, built by concatenating a header JSON object, payload JSON object and cryptographic signature. Calculating the signature requires a shared secret or public/private key pair used to authenticate the object’s source.

For instance, it’s possible to compute a JWT signature using a shared secret and the HS256 (HMAC with SHA-256) algorithm:

The complete JWT is formed by concatenating its three components:

 

It’s important to note that these tokens aren’t encrypted and therefore don’t offer data security. Still, their simplicity lends itself to use by APIs in identifying callers. In scenarios requiring integrations of authentication providers with user-facing APIs and interservice communications, JWTs are certainly a reliable choice. OAuth 2.0 flows are also useful (and often leveraged) when implementing these integrations.

HMAC

The JWT example demonstrates the HMAC (Hash-based Message Authentication Code) with SHA-256 algorithm as used to compute a token header and payload signature. It’s possible to create a signature for any payload utilizing any number of specifications. Therefore, HMACs are often deployed generically. In the JWT case, a payload is a JSON object, but this method can work with other data to authenticate signed messages.

Mutual TLS

TLS authentication is now commonplace for web applications. Certificates enable websites and web services to demonstrate their identity to clients. With mutual TLS, this same authentication goes both ways. The server also identifies the client and enforces any authorization or access control policies in place. Most often, mutual TLS exists within interservice or interbusiness communications, in which a limited set of clients access specific endpoints.

Integrating Authentication With Your Applications Deployed by Kubernetes

Kubernetes offers helpful flexibility when it comes to implementing authentication methods. Most use cases are addressed by leveraging ingress controllers and authentication servers, which I’ll cover below.

Ingress controllers

Today, most developers connecting with applications in Kubernetes do so through an ingress controller. Because specific controllers require different implementations and base themselves on various technologies, developers should make their selections carefully. These considerations should include looking at the authentication methods a particular ingress controller supports. The open source edge router Traefik, for example, has built-in ForwardAuth middleware that integrates into Kubernetes ingress strategies to add authentication management without bringing in individual-service-layer complexities.

Authentication servers

Teaming up the right ingress controller with dedicated authentication servers can meaningfully extend application authentication capabilities in Kubernetes. For example, Authelia is an open source authentication and authorization server that works well with Kubernetes and trusted ingress technologies. These servers can also enable multi-factor authentication, single sign-on and other more advanced authentication capabilities.

Wrapping Up

Leveraging Kubernetes’ power reinforces the need to control application access with effective authentication measures. Implementing the right technologies and architecture will enable authentication best practices, minimize management efforts and successfully safeguard the correct user access to applications running on Kubernetes.

Kevin Crawley

Kevin Crawley serves as the Developer Advocate for Containous, a cloud-native networking company behind the open source projects Traefik and Maesh. He is passionate about championing the benefits of Open Source, DevOps, automation, observability, distributed tracing, and control theory.

Kevin Crawley has 2 posts and counting. See all posts by Kevin Crawley