Five ways to control access to your applications on Kubernetes

Development teams have grown adept at leveraging modern programming languages and cloud technologies in a bid to increase their productivity and reduce development cycle times. Given the flexibility of the cloud-native ecosystem, these advancements have also expanded the surface area of security-related issues such as access-control. While many organizations are adopting Kubernetes (K8s) as their platform of choice for deploying and managing containerized applications, a natural question arises: How should developers implement access control, particularly authentication, within the context of k8s? In this article, we’ll explore this question by covering the following topics:

1. Reviewing common methods for authentication
2. Identifying how some of these methods can be readily integrated with Kubernetes

Common authentication approaches

LDAP

Many organizations have historically adopted some form of directory service implementation such as Active Directory (AD) for storing information including user and organizational data. The majority of these systems support the open Lightweight Directory Access Protocol (LDAP) protocol standard. By integrating with LDAP applications may seamlessly authenticate users within an organization by leveraging the existing user information managed by IT. Moreover, LDAP allows applications to utilize additional information such as groups and policies to enforce access-control. Therefore, integrating with LDAP for both is a reasonable option to consider for line-of-business and internal-facing workloads.

OAuth 2.0

In the context of third-party web applications, users often find themselves having to log in to many disparate systems where a central user identity service isn’t available. While creating unique accounts for each service is an option, this solution does not scale. The OAuth 2.0 protocol is one approach that can help solve this challenge, and it is commonly used as part of authentication flow implementations such as the OpenID Connect standard. The main benefit of using OAuth 2.0 is it gives the ability for the user to approve delegated access for applications. This enables users to leverage existing identity providers (such as their Google account) to authenticate themselves, allowing control over the information being shared, with third-party applications.

JSON Web Token (JWT)

JSON web tokens are an increasingly popular choice for authentication, particularly for APIs. These tokens are composed of Base64URL encoded JSON objects. Specifically, the token is constructed by concatenating a header JSON object, payload JSON object, and signature. The cryptographic signature is calculated using a shared secret or public/private key pair and can be used to authenticate the source of the object. For example, given a shared secret, a JWT signature can be computed using the HS256 (HMAC with SHA-256) algorithm as follows:

signature = HS256(
    Base64URLEncoding(header) + '.' + Base64URLEncoding(payload),
    secret
)

The final JWT is derived by concatenation of the three components:

Base64URLEncoding(header) + '.' + Base64URLEncoding(payload) + '.' + signature

It’s worth noting these tokens won’t provide data security as they aren’t encrypted but their straight forward approach can be used by APIs to identify callers. JWTs are a good option when integrating authentication providers with user-facing APIs and inter-service communications, and are often implemented utilizing OAuth 2.0 flows.

HMAC

The JWT example above highlights the use of the HMAC with SHA-256 algorithm when computing the signature of the token header and payload. The use of HMACs can be generalized in that a signature for any payload can be generated using any number of specifications. The JWT is a special case where the payload happens to be a JSON object but the same mechanism can be used with other data to achieve the objective of authenticating a signed message.

Mutual TLS

TLS authentication in the context of web applications is fairly ubiquitous these days. The general idea is that certificates are used to authenticate a website (or web service) so the client can be confident that the server is who it claims to be. Mutual TLS extends this model to be bidirectional. Not only does the client authenticate the server identity, but the server confirms the identity of the client so that it may enforce access control and authorization policies. Mutual TLS is commonly deployed as part of inter-service and business-to-business communications where there are a limited and known set of clients that are designed to access common endpoints.

Integrating application authentication with Kubernetes

Given our brief review of common authentication approaches, let’s turn to the question of how they can be incorporated when applications are deployed on Kubernetes. As is often the case with K8s, there is a high degree of flexibility to implement a solution that meets the needs of individual organizations. Let’s review a couple of important patterns that can be adopted for most use cases.

Ingress Controllers

Ingress Controllers are the most common mechanism used today when connecting users to applications in Kubernetes. There are many considerations to make when selecting a specific controller, as each is often implemented differently and based upon different underlying technology. Among the many decision criteria when comparing controllers, one must consider how well candidates can support the relevant subset of authentication approaches we’ve highlighted.

Traefik comes with a built-in ForwardAuth middleware feature that can be used to delegate authentication to an external service. By integrating this capability as part of your K8s Ingress strategy, all services exposed in the traffic flow obtain the benefits of authentication management without incurring the complexity at the individual service layer. TraefikEE simplifies the management of auth providers even further by integrating support for LDAP, OAuth 2.0, JWT, and HMAC all within a unified solution.

Authentication servers

The pattern of integrating authentication capabilities through an Ingress Controller can be extended even further by employing dedicated authentication servers into the architecture. Authelia is an example of an open-source authentication and authorization server which works with K8s and has been successfully integrated with Ingress technologies such as Traefik. In addition to the mechanisms covered earlier, these function-specific services can provide advanced authentication capabilities such as 2FA and SSO.

Conclusion

Controlling application access through authentication is an important consideration in any enterprise scenario, and its importance is only amplified when adopting Kubernetes. By thoughtfully selecting architectural patterns and technologies, users can easily integrate their choice of best-practice authentication approaches with minimal additional effort.

There has never been a better time than now to get started with Traefik in Kubernetes. Our open-source Traefik edition with the support of a large and active community is available for free and includes support for the most recent advancements in Kubernetes Ingress technology. If you’re an enterprise looking to implement the most popular cloud-native load balancer with commercial support, high-availability, and authentication modules already built-in you should schedule a demo with our sales team and learn more about how we make networking boring.