Table of Contents
Authentication helps control access to cluster resources by first verifying a user’s identity. In Kubernetes, the API server needs to verify the identity of every request it receives. Such requests may come from a program like a pod or from a human user. Since Kubernetes lacks a built-in feature for authenticating users, you’ll need to rely on auth providers for this service. Fortunately, the container orchestration platform accommodates a variety of authentication providers.
Among the options for auth providers is Dex, which relies on OpenID Connect to enable authentication for other applications. It’s a popular choice because it comes with connectors to allow user authentication against other third-party identity providers. Dex supports protocols such as Lightweight Directory Access Protocol (LDAP) and Security Assertion Markup Language (SAML) as well as platforms such as GitLab, Active Directory, and GitHub.
But Dex is not the only Kubernetes auth provider available. Following are five alternatives to Dex that offer smooth integration with your existing system, as well as scalability, easy configuration, and good security.
1. AWS IAM Authenticator for Kubernetes
Access to Kubernetes clusters in Amazon EKS is controlled by the AWS IAM Authenticator for Kubernetes. The authenticator runs on the EKS control plane and depends on the aws-auth ConfigMap for configuration settings. Every time you use kubectl to perform actions on the EKS cluster, the AWS IAM Authenticator generates an STS token (AWS Security Token Service). Kubernetes uses the IAM authenticator service to verify the identity of users specified in this security token.
By default, the party that creates the Amazon EKS cluster gets system : masters permissions. While this cannot be changed, the authenticator allows you to grant additional AWS users the ability to interact with your clusters. You can do this by editing the aws-auth ConfigMap within your EKS cluster and specifying the group of users that you want to access your clusters. Use the name of that group to create clusterRoleBinding and RoleBinding. With these roles, you can control which IAM users view the workloads and nodes in the EKS console.
The AWS IAM Authenticator has tight integration with identity management services such as
AWS STS and IAM. With these services, users can use AWS authentication credentials instead of Kubernetes credentials to obtain an authenticated session with the Kubernetes API. The tool establishes credentials on your behalf and passes control to kubectl.
Once kubectl gets the control, it sends the authenticated request to the Kubernetes API server. The server delegates the verification of credentials through webhook to the AWS IAM Authenticator’s server-side component. The user credentials and the AWS IAM user represented in this request are mapped to a cluster group for the user to be authorized to access cluster resources.
AWS IAM Authenticator uses multi-factor authentication (MFA) to provide extra security to your EKS resources. With MFA, a user must provide a unique authentication from an AWS-supported MFA strategy besides the usual sign-in credentials they use to access AWS services.
To enable scaling of AWS IAM Authenticator to accommodate your auth needs, you need to associate the IAM roles with an autoscaling group. An IAM role is added as a parameter in the autoscaling launch configuration, and an autoscaling group is created with that configuration. All the Kubernetes instances that you launch with an autoscaling group associated with that IAM role will come with the role as an input parameter.
2. GCP Authentication
Google Cloud Platform (GCP) provides OAuth to authenticate with the Kubernetes API server. As the preferred authentication strategy for Kubernetes clusters, OAuth is configured automatically in Google Kubernetes Engine (GKE). Using this method, you can authenticate your clusters by signing in to the gcloud command line tool to open a web browser that completes the authentication process to Google Cloud.
You can also authenticate your clusters using a static password or an X.509 certificate, but these methods are no longer recommended and are disabled on GKE version 1.12 and newer versions. They provide a larger attack surface that can increase the security vulnerability to your Kubernetes clusters.
OAuth 2.0 authenticates both service accounts and user accounts in GKE. This authentication protocol uses the OpenID Connect method to verify the identity of Kubernetes clusters. GKE is integrated with Google Cloud IAM, so you can also use IAM to control access to your clusters or to configure a user to control the GKE cluster and Google Cloud resources.
GCP provides a two-step verification, which acts as an additional step to your Kubernetes authentication process. You can enable automatic and one-tap sign-in for a better user experience while ensuring more secure Kubernetes clusters. You can also enable multi-factor authentication if you’re using OAuth 2.0 to authenticate your clusters.
With OAuth 2.0, you can scale authentication. OAuth can operate at an internet scale to accommodate the organization’s auth needs.
OAuth 2.0 allows you to integrate additional auth mechanisms. You can build OAuth 2.0 on top of your existing authentication mechanisms, such as SAML and LDAP.
3. Azure AD Auth
Azure AD uses cloud-based protocols such as OpenID Connect, OAuth 2.0, SAML, and Web Services Security (WS-Security) to authenticate users. While Azure AD allows Kubernetes users to authenticate themselves, it doesn’t allow them to configure access rights in detail.
This auth tool provides you with a single access portal that allows you to use Azure AD groups and users to manage access to Kubernetes clusters. When you create an admin user in Azure AD and associate it to the Azure AD group k8sadmins, the user can use kubectl to access the Azure AKS cluster.
Azure AD is a secure Kubernetes authentication platform that enables multi-factor authentication as an additional security layer to your AKS clusters. It also employs such security measures as privileged identity management, conditional access, and threat detection.
Azure AD integrates with existing infrastructure, including software-as-a-service (SaaS) applications such as Azure DevOps, Exchange Online, Zapier, and Microsoft Developer Network (MSDN). With this integration, you can choose to either use single sign-on (SSO) to applications directly or launch applications from a portal, such as the Azure AD access panel.
Authentication demand often fluctuates for many organizations, with a peak during certain hours of the day. Azure AD relies on the scalability of the Azure cloud to rapidly scale up and meet that demand. As a cloud-based authentication platform, Azure AD shows welcome flexibility in accommodating a team’s growing Kubernetes authentication needs.
4. Rancher
Rancher provides a Rancher authentication proxy that allows user authentication from a central location. With this proxy, you can set the credential for authenticating users that want to access your Kubernetes clusters. You can create, view, update, or delete users through Rancher’s UI and API.
For ease of authentication, Rancher Kubernetes Engine (RKE) comes with a cluster certificate and a kube-admin account already deployed to manage access to clusters. It also comes with a user account that provides full access to the cluster by default, but you cannot work with the default accounts; you need to set standards for applications and control access to your Kubernetes clusters. You can do this using webhook authentication and x509 authentication strategies.
With Rancher, you get simple and flexible authentication plugins. These come with pre-built user authentication integration with GitHub, LDAP, and Active Directory. The Rancher auth proxy also integrates with other external authentication backends, including Keycloak, Ping Identity, and FreeIPA. Tying Rancher into an external auth system simplifies user and group access into the Kubernetes cluster. With the flexibility of these external plugins, you’re guarded against downtimes at the authentication provider level.
Rancher builds on the foundation of Kubernetes authentication to provide a more secure authentication system. The auth offers first-class functionality for user and group management, which makes it easy to manage multiple Kubernetes clusters users, groups, and projects from a single pane view.
5. Loft
Loft contains a Kubernetes API gateway that you can use to integrate multiple clusters into a Loft instance. Loft’s multi-tenancy feature also enables the API gateway to work as a single contact point for incoming API requests. The gateway handles Loft-specific commands and sends generic API calls to Kubernetes interfaces in the background.
Loft’s CLI and UI functionality is similar to that of Kubernetes, enabling you to control everything through the Kubernetes API and kubectl. This is important because it guarantees Loft’s integration with your existing cloud-native tooling.
Loft offers the ability to create virtual Kubernetes clusters inside the parent cluster to give each tenant what looks like their own isolated cluster. With a Loft virtual cluster, you can reduce the challenges of managing different physical clusters. Virtual cluster tenants can apply cluster-wide resources, manage their own namespaces, and run pipelines without the overhead of managing real clusters.
Loft enables scaling the number of users that can access Kubernetes clusters. To ensure secure authentication to Kubernetes, Loft supports several SSO providers, including LDAP, SAML 2.0, Google, Okta, Microsoft, GitLab, OIDC, and GitHub.
Conclusion
Kubernetes may not provide a built-in user authentication mechanism, but multiple auth providers can capably fill this gap. You’ve learned about what Rancher, Loft, Azure AD auth, AWS IAM Authenticator, and GCP auth have to offer. One of these providers may be the right fit for your organization, depending on your use case.
Keep in mind that Loft offers plenty of benefits to Kubernetes users, including automated cost optimization, RBAC, and network policies, as well as SSO and audit logging. If you would like to expand self-service access to Kubernetes, Loft will help you reach your goal. To learn more, request a demo.
Photo by olieman.eth on Unsplash
