Securing Kubernetes: Authentication, Authorization, and Admission Control

Kubernetes security is a critical aspect of managing clusters, ensuring that only authorized users and processes can access and modify resources. This section covers API security, Role-Based Access Control (RBAC), and admission control.

Overview of Kubernetes Security

The Big Picture

Kubernetes is API-centric, with the API server as its core component. Every interaction with the cluster, whether from users, Pods, or internal services, goes through the API server. This makes securing the API server paramount.

Typical API Request Flow

A typical API request, such as creating a Deployment, follows these steps:

  1. Authentication: Verifies the identity of the requester.
  2. Authorization: Checks if the authenticated user has permission to perform the action.
  3. Admission Control: Ensures the request complies with policies.

Authentication (AuthN)

Understanding Authentication

Authentication (authN) is about proving your identity. Kubernetes does not have a built-in identity database; instead, it integrates with external identity management systems. Common methods include:

  • Client Certificates: Signed by the cluster's Certificate Authority (CA).
  • Webhook Token Authentication: Integrates with external systems.
  • Service Accounts: For intra-cluster communication.

Checking Your Authentication Setup

Your cluster's details and user credentials are stored in a kubeconfig file, typically located at: /home/<user>/.kube/config

Example kubeconfig File: 

apiVersion: v1
kind: Config
clusters:
- cluster:
    name: prod-eggs
    server: https://<api-server-url>:443
    certificate-authority-data: LS0mRS1F...LS0tRj==
users:
- name: vinny
  user:
    token: FfqwFGF1gASDF4...SZY3uUQ
contexts:
- context:
    name: eggs-admin
    cluster: prod-eggs
    user: vinny
current-context: eggs-admin

Integrating with External IAM Systems

Most production clusters integrate with enterprise-grade Identity and Access Management (IAM) systems such as Active Directory or cloud-based IAM solutions, providing robust authentication mechanisms.

Authorization (AuthZ)

Understanding Authorization

Authorization (authZ) determines what actions authenticated users can perform. Kubernetes uses a least-privilege model with deny-by-default, meaning you must explicitly grant permissions.

Role-Based Access Control (RBAC)

RBAC is a method of regulating access to computer or network resources based on the roles of individual users within your organization. Kubernetes RBAC allows you to dynamically configure policies through the Kubernetes API.

Setting Up RBAC

To set up RBAC, define roles and role bindings in YAML files.

Example Role: 

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

Example RoleBinding: 

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: ""
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: ""

ClusterRoles and ClusterRoleBindings

ClusterRoles apply to all Namespaces, allowing for broader permissions management.

Example ClusterRole: 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: read-deployments
rules:
- verbs: ["get", "watch", "list"]
  apiGroups: ["apps"]
  resources: ["deployments"]


Example ClusterRoleBinding: 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-deployments
subjects:
- kind: User
  name: jambo
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: read-deployments
  apiGroup: rbac.authorization.k8s.io

Admission Control

Understanding Admission Controllers

Admission controllers are plugins that govern and enforce how the cluster should react to requests. They can be used to set defaults, enforce policies, and perform validations.

Common Admission Controllers

  • NamespaceLifecycle: Prevents deletion of active namespaces.
  • LimitRanger: Enforces resource usage limits.
  • ResourceQuota: Ensures resource usage does not exceed specified limits.

Example: NodeRestriction

To check admission controllers in your cluster: 

$ kubectl describe pod kube-apiserver-docker-desktop -n kube-system | grep admission
--enable-admission-plugins=NodeRestriction

Certificates and Service Accounts

Using Client Certificates

Client certificates authenticate users and services within the cluster. They are stored in the kubeconfig file and verified by the API server.

Example of creating a client certificate: 

openssl genrsa -out client.key 2048
openssl req -new -key client.key -out client.csr -subj "/CN=my-user"
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 365

Service Accounts

Service Accounts provide identities for Pods and controllers, enabling secure intra-cluster communication. Unlike user accounts, which are meant for human users, service accounts are intended for processes that run in Pods.

Example ServiceAccount: 

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: default

Using a ServiceAccount in a Pod

To use a service account in a pod, specify the serviceAccountName field in the pod's spec. This binds the pod to the specified service account, allowing the pod to use the account's credentials to authenticate to the API server and other services.

Example of a Pod using a ServiceAccount: 

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: my-service-account
  containers:
  - name: my-container
    image: myimage

Practical Example

Deploying a "Secure" Application

1. Create a Namespace: 

$ kubectl create namespace secure-app

2. Create a ServiceAccount:

# serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: secure-app-sa
  namespace: secure-app

$ kubectl apply -f serviceaccount.yaml

3. Deploy a Pod using the ServiceAccount:

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
  namespace: secure-app
spec:
  serviceAccountName: secure-app-sa
  containers:
  - name: secure-container
    image: nginx

$ kubectl apply -f pod.yaml

4. Create a Role and RoleBinding:

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

# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: secure-app
subjects:
- kind: ServiceAccount
  name: secure-app-sa
  namespace: secure-app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

$ kubectl apply -f role.yaml
$ kubectl apply -f rolebinding.yaml

Best Practices

  • Secure the API Server: Use TLS to encrypt communication with the API server.
  • Implement Network Policies: Control traffic flow between Pods.
  • Regularly Update Clusters: Keep Kubernetes and its components up to date.
  • Use Secrets for Sensitive Data: Store sensitive information securely using Kubernetes Secrets.

Summary

Securing a Kubernetes cluster involves multiple layers of authentication, authorization, and admission control. By understanding and implementing these mechanisms, you can ensure that your cluster is protected from unauthorized access and that all actions comply with defined policies.