Authentication & Authorization in Kubernetes Cluster

“Security is not an afterthought, it should be the foundation of any technology implementation. In the world of Kubernetes, strong authentication is key to ensuring the safety and integrity of your application and data.” — Joe Beda, Co-creator of Kubernetes

Introduction

Kubernetes is a powerful platform that allows you to manage and deploy containerized applications. However, with all applications running on the same cluster, managing access control can be a challenge. This is where authentication & authorization (or ‘authN/authZ’) comes in.

By authenticating & authorizing users before accessing applications, you can manage access control more efficiently and save time by avoiding the need to implement authentication logic in every application. Additionally, authenticating users at the perimeter — or the edge of the cluster — ensures that traffic flowing inside the cluster is only from authenticated users, eliminating traffic from unauthenticated user requests and responses.

In this blog, we’ll explore the importance of authN/authZ in Kubernetes and the different ways available to secure your applications with authentication and authorization.

Authentication & Authorization

In a Kubernetes deployment, authentication and authorization can be configured using various methods such as X.509 client certificates, static passwords, or integrating with an IdP. By leveraging an IdP, you can centralize user management and ensure that your Kubernetes cluster is integrated with your existing identity and access management (IAM) infrastructure.

Two popular options are SAML and OIDC, which are often used as single sign-on (SSO) solutions. SAML handles both authentication and authorization by using a SAML Assertion token, while OIDC is built on top of the OAuth 2.0 protocol. With OIDC, the OIDC layer handles authentication (who the user is) and OAuth 2.0 handles authorization (what the user can access) by using an access token.

Approaches to Kubernetes AuthN/AuthZ

There are several perimeter solutions available for securing applications deployed in Kubernetes, including Ingress controllers and Service Mesh. In this article, we will focus on the Nginx Ingress controller, both the open-source and Nginx Plus versions. We will explore four approaches that can be used to integrate AuthN/AuthZ with the Nginx Ingress controller to secure our applications:

Approach 1 — Oauth2-proxy as an authentication proxy.

This approach leverages the Oauth2-proxy (https://oauth2-proxy.github.io/oauth2-proxy/) to handle authentication and pass authenticated requests to the Nginx Ingress controller. Oauth2-proxy is a reverse proxy that provides authentication service using integrating various Oauth2.0-supported IdPs. Advantages of this approach include:

Easy integration with any OIDC IdP
Access control based on email or group

However, there are some disadvantages to consider:

*Support for only OIDC IdP, not SAML
*Integration with only a single IdP at a time
Need to manage this service and its security

*there’s a solution for this, refer to Approach 5

Approach 2 — Oauth2-proxy with Dex.

This approach builds upon Approach 1 by integrating the dex IdP (https://dexidp.io/) to allow for more advanced authentication scenarios. Dex is an identity service that provides authN/authZ to applications by integrating multiple IdPs of various types. Advantages of this approach include:

Support for multi-IdP (multi-tenancy) scenarios
More granular access control

However, there are some disadvantages to consider:

Support for SAML is deprecated
Need to manage this service and its security

Approach 3 — Nginx Plus Ingress Controller with OIDC policy.

This approach integrates an OIDC provider directly within the ingress controller itself by utilizing the OIDC policy provided by nginx plus ingress controller. Advantages of this approach include:

Authentication is directly integrated into the ingress controller, so no need to manage separate services for authN
A robust way to integrate with the ingress controller

However, there are some disadvantages to consider:

*Support for only OIDC IdP, not SAML.
*Integration with only a single IdP at a time.
No access control based on the user’s role or group

*there’s a solution for this, refer to Approach 5

Approach 4 — Nginx Plus Ingress Controller with Istio Service Mesh.

This approach provides additional features, such as RBAC authorization, traffic management, and observability, in addition to the advantages of Approach 3 by using Istio service mesh (https://istio.io/). Advantages of this approach include:

All of the advantages of Approach 3
Access control based on roles
More features such as traffic management and observability

However, there is one disadvantage to consider:

*Support for only OIDC IdP, not SAML.
*Integration with only a single IdP at a time.
Need to manage both the ingress controller and service mesh.

*there’s a solution for this, refer to Approach 5

Approach 5 — Auth0 as External Identity Provider

This approach involves using Auth0 (https://auth0.com/) as an external identity provider to handle user authentication and authorization. Auth0 supports multiple IdPs, including OIDC and SAML, providing flexibility in choosing an appropriate IdP. Advantages of this approach include:

Allows you to connect to multiple IdPs
Supports a wide range of IdPs

However, there is one disadvantage to consider:

Need to manage authorization at client side — Ingress Controller / Oauth2-Proxy.

Best Practices

Based on the approaches discussed, here are some best practices for configuring Kubernetes authentication using Nginx Ingress:

Use a supported IdP: While all of the approaches discussed support OIDC, Approach 1 and Approach 2 are the only ones that support SAML. When selecting an IdP, ensure that it is supported by the approach you choose.
Secure your authentication proxies: With Approach 1 and Approach 2, you will be managing a separate authentication proxy. It’s important to secure this service to ensure that unauthorized users cannot access your applications.
Consider your access control needs: Access control is an important aspect of authentication, and different approaches provide different levels of granularity. Consider your access control needs when selecting an approach.
Leverage the Nginx Plus OIDC policy: Approach 3 is a robust way to integrate with the ingress controller, but it has limited access control capabilities. Consider using the Nginx Plus OIDC policy for a more streamlined approach to authentication.
Use a service mesh for additional features: Approach 4 provides additional features like RBAC authorization, traffic management, and observability. Consider using a service mesh if these features are important for your use case.
Regularly review and update your authentication configuration: As with any security configuration, it’s important to regularly review and update your authentication configuration to ensure that it remains secure and up-to-date with the latest best practices.

Conclusion

In conclusion, securing applications in Kubernetes requires careful consideration of different authentication and authorization options, as well as understanding solutions like Ingress controllers and Service Mesh. We explored different approaches for integrating AuthN/AuthZ, each with its own advantages and disadvantages. When selecting a solution, it’s important to consider the specific needs of your application and deployment. As a best practice, we recommend using a centralized identity provider for managing user authentication and access control across your Kubernetes cluster.

Thank you for reading! In upcoming articles, we will explore the implementation of each approach in greater detail. Stay tuned for more insights on this topic!