How Kubernetes Secures Your Cluster: Auth, RBAC, and Admission Control Explained

Kubernetes Cluster Security Mechanisms

Kubernetes is a distributed cluster management tool, and protecting the cluster’s API Server is its core security task. Access to the API Server must pass three gates: authentication, authorization, and admission control.

1. Authentication

1.1 Three authentication methods in a k8s cluster

HTTP Token authentication : a long, unforgeable token string identifies a user; the token is placed in the HTTP Header.

HTTP Basic authentication : username and password are Base64‑encoded and sent in the Authorization header.

HTTPS certificate authentication (most strict) : mutual TLS using a CA‑signed client certificate.

Note: Token and Basic authentication are one‑way; HTTPS certificate authentication provides mutual authentication.

1.2 Authentication details

1) Access types that need authentication: Kubernetes components (kubectl, kubelet, kube‑proxy) and Pods (including coredns, dashboard) accessing the API Server.

2) Security notes: Controller Manager and Scheduler run on the same node as the API Server and can use the non‑secure port (8080); other components use HTTPS with mutual authentication on port 6443.

3) Certificate issuance: manual signing for binary deployments or automatic signing when kubelet first contacts the API Server.

4) kubeconfig file: contains cluster parameters (CA cert, API Server address), client credentials (certificate and key), and context (cluster name, user). It allows switching clusters by specifying different files.

5) Service Account: provides a token for Pods so they can access the API Server without per‑Pod certificates.

6) Secret and Service Account relationship: Kubernetes defines Secret objects of two types— service‑account-token for ServiceAccounts and Opaque for user‑defined data.

1.3 Service Account components

• Token – API Server‑signed token string used for server‑side authentication. • ca.crt – CA root certificate for client‑side verification of the API Server. • namespace – the namespace scope of the Service Account.

Note: Each namespace has a default Service Account; Pods use it unless another is specified.

2. Authorization

2.1 Authorization methods

Kubernetes supports several authorization modes (set via --authorization-mode):

AlwaysDeny – reject all requests (for testing).

AlwaysAllow – allow all requests (for testing).

ABAC (Attribute‑Based Access Control) – match user attributes against policies.

Webhook – call an external REST service for authorization.

RBAC (Role‑Based Access Control) – default from v1.6 onward.

2.2 Advantages of RBAC

Full coverage of both resources (Pod, Deployment, Service) and non‑resources (metadata, status).

Managed via standard API objects; operable with kubectl or the API.

Adjustable at runtime without restarting the API Server.

2.3 RBAC API resources

RBAC introduces four top‑level resources: Role, ClusterRole, RoleBinding, and ClusterRoleBinding. Official documentation: https://kubernetes.io/docs/reference/access-authn-authz/rbac/

2.4 Role and RoleBinding

Role

grants permissions within a namespace; ClusterRole grants cluster‑wide permissions. RoleBinding binds a Role to subjects (User, Group, ServiceAccount); ClusterRoleBinding binds a ClusterRole cluster‑wide.

2.5 Role and ClusterRole examples

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

Note: Assigning this Role gives the user get, watch, and list permissions on Pods in the default namespace.

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

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

3. Admission Control

3.1 Concept

Admission control is a list of API Server plugins that evaluate every request; if any plugin rejects the request, it is denied. The default set is usually sufficient.

Official plugin list (varies by version): NamespaceLifecycle, LimitRanger, ServiceAccount, DefaultStorageClass, DefaultTolerationSeconds, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota, NodeRestriction.

3.2 Example plugins

NamespaceLifecycle : prevents creation of objects in non‑existent namespaces and protects system namespaces.

LimitRanger : enforces resource limits defined by a LimitRange.

ServiceAccount : automatically adds a ServiceAccount to each Pod.

ResourceQuota : enforces namespace‑level quotas for resources.

NodeRestriction : limits node permissions when joining the cluster.

Reference: https://kubernetes.io/zh/docs/reference/access-authn-authz/admission-controllers/

3.3 Resource limits for Pods

Kubernetes enforces CPU and memory limits via cgroups. By default Pods have no limits; you can set requests (initial allocation) and limits (maximum) in the pod spec.

spec:
  containers:
  - image: xxxx
    name: auth
    ports:
    - containerPort: 8080
      protocol: TCP
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 250m
        memory: 250Mi

3.4 Namespace resource quotas

Compute resource quota example:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: spark-cluster
spec:
  hard:
    pods: "20"
    requests.cpu: "2"
    requests.memory: 1Gi
    limits.cpu: "4"
    limits.memory: 2Gi

Object count quota example:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
  namespace: spark-cluster
spec:
  hard:
    configmaps: "10"
    persistentvolumeclaims: "4"
    replicationcontrollers: "20"
    secrets: "10"
    services: "10"
    services.loadbalancers: "2"

To set default limits and requests for containers, use a LimitRange:

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
  namespace: test
spec:
  limits:
  - default:
      memory: 512Mi
      cpu: 500m
    defaultRequest:
      memory: 256Mi
      cpu: 100m
    type: Container