Why Kubernetes doesn’t manage users?

Kubernetes stands at the forefront of the container orchestration revolution by becoming most people’s go-to container orchestration platform. While looking at all the features that Kubernetes brings into the picture, you may notice that the platform does not manage its own users. This stumps most first-time users, however, this is considered to be out of its primary responsibilities and by doing this, Kubernetes can focus on what it does best while offloading the authentication & authorization to more specialized providers.

Understanding authentication and authorization in Kubernetes

Authentication and authorization take precedence when we look at how Kubernetes verifies and grants access to its clusters.

In standard deployments of Kubernetes, the user authentication takes place with the use of Transport Layer Security (TLS) certificates where any user with a valid TLS certificate that is signed by the certificate authority and accepted by the API server is authenticated. After authentication, Role-based access control (RBAC) takes over when deciding the level of authorization the authenticated user gets.

However, in large-scale environments, it is not always feasible to manage authentication via certificates, therefore Kubernetes allows organizations to integrate and offload the authentication and authorization to third-party services.

Why doesn’t Kubernetes handle user management?

Some users may argue that it would be easier if Kubernetes managed its own set of users. This maybe true in small-scale deployments, however, when we look into large enterprises that operate with over 5000 employees, the story of managing each user in individual systems becomes a tedious task, therefore these large scale organizations often use a single source of truth, for all their authentications needs within the organization such as a centralized directory.

Kubernetes allows its users to integrate with various authentication mechanisms in order to allow for a far greater set of use cases. Some of the most common reasons as to why Kubernetes doesn’t manage its own users comes from this principle.

Let’s take a look at some of the most common reasons for this:

1. Flexibility and Extensibility: The lack of user management within the platform should not be considered a disadvantage. It is actually desirable since it gives organizations the flexibility to integrate with one of the many authentication services that they are running already, such as but not limited to LDAP & OAuth.
2. Diverse Use Cases: A Kubernetes platform operates in many different environments, ranging from public and private clouds to on-premises data centers and hybrid infrastructures. For example, when running Kubernetes on multiple cloud providers, each cloud provider may have its own identity and access management system. Kubernetes allows organizations to integrate with these existing systems or implement a unified user management strategy that spans across different cloud environments.
3. Security Considerations: With security compliance and regulations such as ISO 27001, PCI DSS, GDPR and NIST requiring a lot of care and attention with regard to user management, it is nearly impossible to have a single solution to cater to all these requirements. Therefore having the flexibility within Kubernetes to integrate a variety of authentication mechanisms, allows organizations to focus on aligning with their security policies and compliance requirements.

How do you add users with external connectors?

Now that we know Kubernetes supports various external connectors for authentication and authorization, we will look into how we can integrate these into our Kubernetes clusters.

Here are some popular options that most large scaled organizations use:

1. OIDC (OpenID Connect)
2. LDAP (Lightweight Directory Access Protocol)
3. Webhooks and Custom Auth Plugins

Integrating Kubernetes with OIDC (OpenID Connect)

There are various OIDC providers such as Keycloak, Azure AD and Okta that you are able to integrate with. However in this example we will look into integrating Kubernetes with Azure AD.

In order to begin you would need to register and configure an application within Azure AD

1. Register an Application in Azure AD:

• Go to the Azure portal and register a new application in your Azure AD.
• Note down the Application (client) ID and Directory (tenant) ID.

2. Configure Authentication in Azure AD:

• Configure the authentication settings for the registered application.
• Add a Redirect URL for your Kubernetes API server. This is typically in the format: https:///callback.

3. Generate a Client Secret:

Generate a client secret for the registered application. Note down the secret, as it will be needed for Kubernetes configuration.

After the configuration on the Azure AD is complete, you can move on to configuring the Kubernetes cluster configuration.

4. Update Kubernetes API Server Configuration:

Edit the Kubernetes API server configuration to include the Azure AD OIDC parameters. This is often done in the kube-apiserver configuration file or via command-line flags. Replace the placeholders with your Azure AD information.

kube-apiserver \
  --oidc-issuer-url=https://login.microsoftonline.com/<your-tenant-id> \
  --oidc-client-id=<your-client-id> \
  --oidc-client-secret=<your-client-secret> \
  --oidc-username-claim=upn \
  --oidc-username-prefix=azuread:

Adjust the parameters based on your Azure AD configuration. The oidc-username-claim and oidc-username-prefix flags are optional and depend on how user information is provided by Azure AD.

5. Restart the Kubernetes API Server:

• Restart the Kubernetes API server to apply the changes made to the configuration.

6. Test Azure AD Authentication:

• Test the Azure AD authentication by using the kubectl command-line tool.

kubectl version

The command should prompt you to authenticate via Azure AD. Follow the prompts and use your Azure AD credentials to log in.

7. Define RBAC Roles and Bindings:

• Create RBAC roles and bindings based on Azure AD user or group information.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: azuread-cluster-admin
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
##Add additional rules as needed

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: azuread-cluster-admin-binding
subjects:
- kind: User
  name: "azuread:<username>"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: azuread-cluster-admin
  apiGroup: rbac.authorization.k8s.io

Replace <username> with the actual username obtained from Azure AD.

Integrating Kubernetes with LDAP

Integrating your Kubernetes cluster with OpenID Connect seems fairly straightforward with its native integration capabilities. However we cannot say the same about integrating your Kubernetes cluster with LDAP since there aren’t direct connectors to do this.

Instead, we rely on different approaches using third-party connectors to complete this integration.

In this example, we will look at how we can integrate Kubernetes with LDAP with the use of a Proxy; and we will be focusing on using Dex as our proxy.

We will be following the steps shown below in order to get this integration up and running.

Step 1: Install and Configure Dex

1. Install Dex:

• Follow the installation instructions for Dex

2. Configure Dex:

• Configure Dex to connect to your LDAP server. This involves specifying LDAP connection details, bind credentials, and mapping LDAP attributes to OpenID Connect claims.

3. Deploy Dex:

• Deploy Dex in your Kubernetes cluster, typically as a set of Kubernetes resources (Deployments, Services, etc.).

Step 2: Integrate Dex with Kubernetes API Server

1. Update Kubernetes API Server Configuration:

• Configure the Kubernetes API server to use Dex as an OIDC provider.

kube-apiserver \
  --oidc-issuer-url=https://dex.example.com \
  --oidc-client-id=k8s-client-id \
  --oidc-client-secret=k8s-client-secret

• You will need to replace “https://dex.example.com” with your Dex URL and configure “oidc-client-id” and “oidc-client-secret” parameters based on your Dex configuration.

2. Restart the Kubernetes API Server:

• Restart the Kubernetes API server to apply the changes.

Step 3: Test Authentication

1. Test Authentication:

• Use “kubectl” to test the authentication against the Kubernetes API server.

kubectl version

Dex should prompt you for LDAP credentials, and upon successful authentication, you should be able to access the Kubernetes API.

Integrating Kubernetes with Webhooks and Custom Authentication Plugins

We will now look into integrating your Kubernetes cluster with Webhooks and custom authentication plugins. However in order to proceed you need to be able to create and deploy your own Webhook, which is out of the scope of this blog post.

Step 1: Implement the Webhook Server

1. Develop the Webhook Server:

• Create a webhook server that implements the authentication logic. This server receives authentication requests from the Kubernetes API server and responds with the authentication result.

2. Expose the Webhook Server:

• Deploy and expose the webhook server so that the Kubernetes API server can reach it. Ensure that the server is secured and follows best practices for handling authentication-related requests.

Step 2: Configure Kubernetes API Server

1. Edit kube-apiserver Configuration:

• Edit the kube-apiserver configuration file (e.g., /etc/kubernetes/manifests/kube-apiserver.yaml).

2. Add Webhook Configuration:

• Add the configuration for the webhook authentication handler. Specify the URL of your webhook server.

spec:
  containers:
  - command:
    - kube-apiserver
    - --authentication-token-webhook-config-file=/path/to/webhook-config.yaml

• Create a webhook configuration file (webhook-config.yaml) with details about your webhook server.

Step 3: Restart the Kubernetes API Server

1. Restart the Kubernetes API Server:

• Apply the changes by restarting the kube-apiserver pod.

Step 4: Test Webhook Authentication

1. Test Authentication:

• Use the kubectl command-line tool to test authentication against the Kubernetes API server.

kubectl version

• The webhook server should be triggered during the authentication process.

Importance of RBAC Within An Enterprise

Having to configure access for each entity within your Kubernetes cluster may seem like a daunting task, especially if you’re running a complex enterprise-scale cluster with 500+ users and accounts.

However, with the many connectors we looked at within this article, we don’t need to create individual mappings for each user. Instead, we can define roles for each of the access requirements and merge multiple entities into a single role.

Defining distinct roles and access permissions are crucial for many reasons such as:

1. Granular Control: RBAC provides strict control over resource access and manipulation in a Kubernetes cluster, ensuring users only have the permissions they need and reducing the likelihood of unauthorized actions.
2. Compliance and Auditing: It assists organizations in meeting regulatory requirements by defining and implementing access restrictions. By tracking user behaviors, RBAC logs aid in post-incident analysis and compliance reporting.
3. Scalability: RBAC streamlines user access management as Kubernetes clusters scale. Administrators can establish roles and role bindings, which simplifies permission assignment and revocation as the cluster grows.
4. Resource Isolation: RBAC enables resource isolation by providing users and components access to only the resources they need. This is especially important in multi-tenant setups, where various teams or projects may share the same cluster. This concept is also referred to as the “Principle of Least Privilege”.
5. Zero Trust Security Model: The Zero Trust approach, which aligns with RBAC in Kubernetes, assumes no default trust for any entity, whether inside or outside the network. RBAC enforces the concept that users and components must constantly prove their identity and need for access.

• RBAC ensures that users and components have only the permissions they need, removing trust assumptions based on location or status.
• RBAC’s continuous authentication and authorization checks adhere to the Zero Trust concept by not depending exclusively on entity presence within the network.

How to choose the right connector for the right situation?

Now that we’ve looked at integrating your Kubernetes clusters with these various authentication mechanisms, you must be wondering, What method should I use?

Let’s take a look at how you can use each of these connectors

OIDC (OpenID Connect):

Here are some use cases where using OIDC would be better:

1. Multi-Cluster Collaboration: In a large organization with multiple Kubernetes clusters, OIDC is ideal for enabling secure collaboration and resource sharing across clusters.
2. Third-Party Application Integration: The organization integrates third-party applications with its Kubernetes clusters. OIDC provides a secure and standardized authentication mechanism for users accessing these applications.

LDAP (Lightweight Directory Access Protocol):

Using LDAP for Kubernetes authentication has its own set of use cases where some organizations already have a centralized directory service that they use within the organization:

1. Service Account Authorization Across Departments: Various departments within the organization utilize service accounts to interact with Kubernetes. LDAP’s RBAC integration ensures fine-grained access controls based on departmental roles.
2. Hybrid Cloud Authentication: The organization adopts a hybrid cloud architecture, and LDAP serves as a unified authentication mechanism for Kubernetes clusters across on-premises and cloud environments.

Webhooks and Custom Auth Plugins:

There are some use cases where webhooks are the way to go:

1. Dynamic Authentication Logic for Specialized Workloads: Certain specialized workloads within the organization require dynamic and customized authentication logic. Webhooks and custom auth plugins enable the organization to implement tailored authentication processes.
2. Integration with IoT Devices: The organization deploys IoT devices that require secure authentication to access Kubernetes resources. Webhooks and custom auth plugins facilitate seamless integration with diverse IoT authentication mechanisms.

Wrapping Up

Kubernetes not managing its own users does not mean the end of world! Rather, it opens up numerous possibilities for flexible and extensible solutions. Looking back at the connectors that we looked at shows how versatile these connectors can be and where we can use each of them.

It is important to note that like any configuration, these external connectors are subject to drift and require monitoring. Regular audits and reviews are necessary to ensure that the user management systems remain aligned with the organization’s security requirements.

To help with this, ARMO Platform offers a powerful RBAC visualization tool that simplifies the auditing and control of RBAC configurations in Kubernetes. By leveraging ARMO Platform’s RBAC visualization capability, organizations can streamline their auditing processes, enhance their control over user management configurations, and ensure the ongoing security and compliance of their Kubernetes deployments.