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:
- Authentication: Verifies the identity of the requester.
- Authorization: Checks if the authenticated user has permission to perform the action.
- 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:
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:
2. Create a ServiceAccount:
# serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: secure-app-sa
namespace: secure-app
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
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
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.