CKS Notes - Apiserver request security

1. Identity = kubeconfig

Here the identity equals kubeconfig file

Every kubeconfig file specifies:

• the certificate

• the client key

• the username (CN)

• the group (O)

• the cluster endpoint

This determines:

• Who you are (identity)

• What you can do (RBAC permissions)

Now let’s first distinguish 2 types of identity: admin cluster identity vs node identity.

1.1 kubelet.conf

Location:

each nodes /etc/kubernetes/kubelet.conf

Identity inside it:

user = system:node:<nodeName>
group = system:nodes

Meaning:

• This identity belongs to the kubelet on that node

Permissions (through RBAC):

• can update its own node object

• can update pod status for pods assigned to it

• cannot get/delete/list arbitrary pods

• cannot label other nodes

This identity is heavily restricted by NodeRestriction.

---

1.2 $HOME/.kube/config (admin.conf copy)

Location:

on control plane node

Identity:

user = kubernetes-admin
group = system:masters

Meaning:

• This is the cluster admin identity

• Full power (cluster-admin cluster role)

Permissions:

• can do “everything” — (get/delete/list/create/patch ANY resource)

NodeRestriction does NOT apply to this identity.

2. Workflows

there is one section about Admission control phase, but it may not easy to understand. Here is my previous post for the workflow (Kubernetes workflow).

2.1 Basic concepts

Let’s first have a overlook of some basic components.

kubelet

• runs the containers

• updates pod/node status

kubectl

• send requests

kubelet.conf = identity of kubelet

• Used by kubelet when it talks to API server, (NodeRestriction)

admin.conf / ~/.kube/config = identity of cluster admin

• Used by kubectl

2.2 Diff workflows

Now let’s see the workflow for diff process

API request:

kubectl → API server → etcd

Pod scheduling:

scheduler → API server → etcd

Pod execution:

kubelet → containerd → pod runs

Status updates:

kubelet → API server → etcd

Controllers maintain desired state:

controller manager → API server → etcd

3. Security

the basic security flow is Authentication - Authorization - (Admission Control)

3.1 Authentication (Identity)

Here we see when using these 2 type (node identity, cluster identity) config file their workflow:

1. When human/admin runs kubectl (on controlplane)

# eg. on controlplane
k get node
k label node node01 test/thislabel=123

0. ~/.kube/config

1. kubectl sends HTTPS request with admin cert

2. API server authenticates admin identity

1. When kubelet talks to API server (on each node)

# eg. on node01
k label node node01 test/thislabel=123 --kubeconfig=/etc/kubernetes/kubelet.conf

0. /etc/kubernetes/kubelet.conf  (local to that node)

1. kubelet loads cert/key

2. kubelet sends HTTPS request to API server

3. API server authenticates "system:node:NODENAME"

notice:

• kubectl sends requests for user operations

• kubelet sends requests for node/pod management

3.2 Authorization (RBAC)

• Uses CN and O from the certificate

• Checks “is this identity allowed to do this verb on this resource?”

RBAC uses this identity to check:

1. Which User? eg. system:node:node01
2. Which Groups? eg. system:nodes (all kubelets), system:authenticated
3. Which verb/resource?
   • update node/worker1
   • patch node/worker1
   • get pods
4. RBAC rules that apply to those groups
   • eg. Kubernetes has a built-in ClusterRole

more details can refer to official doc or previous post here.

3.3 Admission Control (NodeRestriction)

Check the data/operations that try to modify the resource in the arriving request. Prevents kubelets from doing dangerous modifications:

• Node labels

• Node annotations

• Node taints

• Pods on other nodes

More details can check in official doc “Admission Control in Kubernetes” and “Using Node Authorization”