Kubernetes has some impressive baked-in role based access controls (RBAC). These controls allow administrators to define nuanced permissions when querying Kubernetes resources, like Pods, Deployments, ReplicaSets, etc. For those familiar with Kubernetes, the value of RBAC is immediately recognizable. A single Kubernetes cluster can contain your organization’s entire CI/CD pipeline, highly available SaaS products, or infrastructure that is in the process of being moved to the cloud. For what’s at stake, weak access controls are a nonstarter.

Authenticating with SAML

Authorization is only half the battle. Even the strictest access policy is obsolete if the authentication can be spoofed. For this reason, Kubernetes supports a range of common authentication patterns, such as static tokens, client certificates, OIDC, and other methods. With all the components available, secure access should be simple: (1) request access to a cluster through SSO, (2) have the K8s API authenticate against your identity provider (IDP), and (3) apply rules based on identity information. Voila.

Unfortunately, if your protocol of choice is SAML, which it is for many enterprise organizations, this setup requires extension. We can accomplish this by placing a proxy between the user and Kubernetes API that can read SAML assertions and translate attributes into a format the API is built to read and process. There are three readily documented ways to accomplish this, authenticating proxy, webhooks, or user impersonation. This blog post focuses specifically on user impersonation. Why? Because if you are using a hosted Kubernetes provider, which many are doing due to its complexity, users don’t have control over the kube-apiserver flag required to set up webhooks or an authenticating proxy.

By the end of this article, we will have:

• Understood what User Impersonation is
• Created a SAML connector
• Assigned a proxy impersonation privileges
• Impersonated a user
• Mapped SAML attributes to Kubernetes Groups

What is Single Sign On (SSO)?

Single sign on, or SSO, is an important tool in federating identity across multiple different systems. SSO disposes the need to create a new set of credentials for each application accessed. Instead, the process of authentication is outsourced to identity providers like Okta, GSuite, or Keycloak. This allows organizations to enforce a consistent method of authentication across all internal corporate services.

What is SAML?

To enable SSO for a particular application, it must support an authentication protocol. One of these protocols is the Security Assertion Markup Language (SAML). These protocols allow identity providers to authenticate users on behalf of the application and pass on authorization information back to the application. If you are not familiar with SAML, I recommend reading through How SAML 2.0 Authentication Works.

What is Kubernetes User Impersonation?

To understand what impersonation is and why it is useful, let’s take a step back and quickly go over Kubernetes RBAC. The RBAC API uses the Role and ClusterRole objects to define a set of permissions. These roles are then bound to accounts that the roles apply to using RoleBindings and ClusterRoleBindings respectively. Take this snippet that would grant read only access to all pods.

## pod-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

We can take this pod-reader role and bind it to a particular user, jane.

#kubernetes