Kubernetes Security

Question 1

What is Kubernetes RBAC and what does it enforce?

Answer 1

Kubernetes Role-Based Access Control (RBAC) decides whether an authenticated subject may perform an API action.
- API server receives a request with a subject identity.
- API server evaluates RBAC rules against (verb, resource, namespace, name) and returns allow/deny.
- If denied, the API action does not execute.

Question 2

How do Kubernetes Roles and ClusterRoles differ?

Answer 2

They differ by scope of what rules can apply to.
- Role: rules apply within one namespace.
- ClusterRole: rules can apply cluster-wide and can also be bound into namespaces.
- Bindings determine which subjects receive those rules in which scope.

Question 3

How do RoleBindings and ClusterRoleBindings work?

Answer 3

Bindings attach RBAC rules to subjects.
- RoleBinding grants a Role or ClusterRole to subjects within a namespace scope.
- ClusterRoleBinding grants a ClusterRole to subjects across the cluster.
- API server uses bindings to map subject → effective rules before deciding allow/deny.

Question 4

How does Kubernetes RBAC authorization work for an API request?

Answer 4

Step 1: API server authenticates the request to determine the subject (user, group, service account).
Step 2: API server collects RBAC rules from Roles/ClusterRoles referenced by bindings for that subject.
Step 3: API server matches request (verb, resource, namespace, name) to allowed rules.
Step 4: If a matching allow rule exists, request proceeds; otherwise it is denied.

Question 5

What breaks Kubernetes RBAC in practice?

Answer 5

Cause → system behavior → security impact.
- Cause: broad ClusterRoleBindings or wildcard rules on sensitive resources.
- Behavior: many requests match allow rules, including actions not intended for that subject.
- Impact: compromise of one credential or pod enables cluster-wide changes or secret access.

Question 6

What are Kubernetes authentication inputs (certs, tokens, OIDC)?

Answer 6

Authentication inputs are what the API server validates to determine who is calling.
- Client certificates: API server validates certificate chain and maps it to a user identity.
- Bearer tokens: API server validates token via configured authenticators and maps to a user/service account.
- OIDC (OpenID Connect): API server validates tokens issued by an OpenID Provider and maps claims to identity.

Question 7

How does Kubernetes authenticate a request using a client certificate?

Answer 7

Step 1: Client presents a certificate during TLS connection setup.
Step 2: API server validates the certificate chain against configured client CA trust.
Step 3: API server extracts identity fields (subject, organizations) to form user and group values.
Step 4: API server uses that identity as the subject for RBAC authorization.

Question 8

How does Kubernetes authenticate a request using a bearer token?

Answer 8

Step 1: Client sends an Authorization header with a token.
Step 2: API server validates the token using configured token authenticators.
Step 3: API server maps validated token to a subject identity (user/groups or service account).
Step 4: API server passes the subject into RBAC authorization.

Question 9

What is OIDC for Kubernetes authentication?

Answer 9

OIDC (OpenID Connect) lets the API server accept identity tokens issued by an OpenID Provider.
- API server validates token signature and required claims (issuer, audience, expiry).
- API server maps claims (subject, groups) to Kubernetes user and group identity.
- RBAC then authorizes actions based on those identities.

Question 10

What breaks Kubernetes authentication in practice?

Answer 10

Cause → system behavior → security impact.
- Cause: weak token validation constraints (wrong audience acceptance) or long-lived credentials.
- Behavior: stolen tokens or mis-accepted tokens authenticate successfully.
- Impact: attacker reaches RBAC with a valid subject identity and can act within granted permissions.

Question 11

What are Kubernetes service accounts and how are they used?

Answer 11

A service account is an in-cluster identity used by pods to call the Kubernetes API.
- Pods can be configured to use a specific service account.
- The service account token is used as bearer authentication to the API server.
- RBAC permissions bound to the service account determine what that pod can do via the API.

Question 12

How does a pod use a service account token to call the API server?

Answer 12

Step 1: Pod is associated with a service account.
Step 2: Pod obtains the service account token (mounted or requested via token API, depending on configuration).
Step 3: Pod sends API requests with the token as a bearer token.
Step 4: API server authenticates the token as that service account and applies RBAC to allow/deny.

Question 13

What breaks service account token usage in-cluster?

Answer 13

Cause → system behavior → security impact.
- Cause: tokens are mounted broadly or tokens are readable by unintended processes in the pod.
- Behavior: attacker in the pod reads the token and replays it to the API server.
- Impact: attacker gains the service account’s RBAC permissions and can pivot through the Kubernetes API.

Question 14

What is Kubernetes admission control?

Answer 14

Admission control is the API server stage that can modify or reject objects after authentication/authorization but before persistence.
- Mutating admission can change the object (defaults, injections).
- Validating admission can reject the object based on rules.
- If admission rejects, the object is not stored and the requested change does not happen.

Question 15

How does validating vs mutating admission control differ?

Answer 15

They differ in what they are allowed to do to the request object.
- Mutating: can alter fields (add labels, inject sidecars, set defaults).
- Validating: evaluates final object and returns allow/deny without modifying it.
- Order matters because validation often runs after mutation so it can evaluate the final spec.

Question 16

How does admission control enforce policy on object creation?

Answer 16

Step 1: User submits create/update request to API server.
Step 2: API server authenticates and authorizes the request (RBAC).
Step 3: Mutating admission runs and may modify the object.
Step 4: Validating admission runs and may reject the object.
Step 5: If allowed, API server persists the object; otherwise it returns an error.

Question 17

What breaks admission control in practice?

Answer 17

Cause → system behavior → security impact.
- Cause: policy not enforced on all relevant operations or namespaces, or bypass via alternate API paths.
- Behavior: unsafe objects are accepted because no validator applies.
- Impact: attacker can deploy privileged pods or unsafe workloads that expand blast radius.

Question 18

What are Pod Security controls (baseline/restricted mental model)?

Answer 18

Pod Security controls are enforcement rules that block pods with unsafe security context settings.
- Baseline blocks common risky settings while allowing many workloads.
- Restricted blocks a wider set and pushes toward least-privilege runtime settings.
- Enforcement happens at admission time: unsafe pod specs are rejected before they run.

Question 19

How do Pod Security controls block unsafe pods?

Answer 19

Step 1: Pod spec is submitted to the API server.
Step 2: Pod Security evaluation checks the pod’s security-related fields against the selected profile.
Step 3: If the spec violates required constraints, admission denies the request.
Step 4: If allowed, the pod can be scheduled and started.

Question 20

What breaks Pod Security controls in practice?

Answer 20

Cause → system behavior → security impact.
- Cause: enforcement mode not enabled or inconsistent across namespaces.
- Behavior: attackers create pods with risky settings because nothing rejects them.
- Impact: privileged workloads enable host access and easier container escapes.

Question 21

What are Kubernetes NetworkPolicies?

Answer 21

NetworkPolicies define which pod-to-pod and pod-to-external network flows are allowed.
- Enforcement component matches traffic against policy based on pod labels, namespaces, ports, and direction.
- If no policy allows a flow (in a restricted namespace), the flow is blocked.
| Without an enforcing network policy engine, policies do not change traffic behavior.

Question 22

How do NetworkPolicies enforce traffic rules?

Answer 22

Step 1: A packet/connection is initiated from a pod to a destination.
Step 2: Enforcement component identifies source/destination pods and their labels/namespaces.
Step 3: It evaluates NetworkPolicy rules for ingress/egress that apply to the pods.
Step 4: If a rule allows the flow, it passes; otherwise it is dropped or rejected.

Question 23

What breaks NetworkPolicies in practice?

Answer 23

Cause → system behavior → security impact.
- Cause: no enforcing plugin or policies allow broad egress/ingress.
- Behavior: traffic is not actually restricted, or is restricted far less than assumed.
- Impact: lateral movement and data exfiltration paths remain open.

Question 24

What are workload identity patterns (in-cluster vs cloud IAM)?

Answer 24

Workload identity patterns are how a pod proves identity to access services.
- In-cluster: identity is typically a Kubernetes service account used to access the Kubernetes API.
- Cloud IAM integration: identity can be mapped so pods obtain cloud credentials scoped to a pod/service account identity.
- The security property is least privilege through identity-specific authorization checks.

Question 25

How do systems enforce workload identity for cloud access from pods?

Answer 25

**Step 1:** Pod is associated with an identity mapping (often via service account). **Step 2:** Pod requests credentials or a token through the identity integration mechanism. **Step 3:** Cloud provider validates the workload identity and issues scoped credentials. **Step 4:** Cloud APIs authorize actions based on those credentials and their attached policies.

Question 26

What are Kubernetes secrets and how are they used by pods?

Answer 26

Kubernetes secrets are API objects that hold secret values and can be delivered to pods. - A pod can consume secrets as mounted files or environment variables. - Access to read secrets is controlled by Kubernetes API authorization (RBAC). - If a process can read the mounted secret or env, it can use the secret regardless of RBAC.

Question 27

What breaks Kubernetes secrets handling in practice?

Answer 27

Cause → system behavior → security impact. - Cause: broad RBAC lets many subjects read secrets, or secrets are exposed via env/logs in workloads. - Behavior: attacker reads secret values through the API or from a running pod’s filesystem/environment. - Impact: attacker gains credentials for databases, registries, or cloud APIs and pivots outside Kubernetes.

Question 28

What are node and pod isolation boundaries in Kubernetes?

Answer 28

Isolation boundaries define how far a compromise can reach from a pod. - Pod boundary: limits process visibility and filesystem/network scope via namespaces and cgroups. - Node boundary: multiple pods share a kernel; compromise that reaches host-level can affect all pods on the node. - Host access settings determine whether a pod can cross from pod boundary into node boundary.

Question 29

What breaks node and pod isolation boundaries in practice?

Answer 29

Cause → system behavior → security impact. - Cause: pods with host access (hostPath mounts, hostNetwork, privileged settings) or kernel-level exploits. - Behavior: attacker reaches node-level resources and can observe or modify other workloads. - Impact: compromise expands from one pod to many, possibly to cluster control credentials.

Question 30

What are container runtime permissions in Kubernetes (capabilities, seccomp, AppArmor)?

Answer 30

Runtime permissions are OS-enforced limits on what container processes can do. - Linux capabilities control which privileged operations a process can perform. - Seccomp (secure computing mode) filters syscalls and can deny dangerous syscalls. - AppArmor applies policy rules to restrict file and operation access. | These controls reduce what code can do even if the pod is compromised.

Question 31

How do systems enforce capabilities and seccomp for a pod?

Answer 31

**Step 1:** Pod spec defines security context (user, capabilities add/drop, seccomp profile). **Step 2:** Container runtime starts the process with those constraints. **Step 3:** When the process attempts privileged operations or syscalls, the kernel checks constraints. **Step 4:** Disallowed operations fail, limiting attacker actions within the container.

Question 32

What breaks container runtime permission controls in practice?

Answer 32

Cause → system behavior → security impact. - Cause: overly permissive security context (extra capabilities, unconfined seccomp/AppArmor). - Behavior: kernel allows powerful actions that would otherwise be blocked. - Impact: exploits succeed more easily and can reach host-level impact.

Question 33

What are API server trust boundaries and common bypass paths?

Answer 33

The API server trust boundary is the interface where all cluster state changes should be authenticated, authorized, and admitted. - Bypass paths exist when components expose privileged operations outside the API server checks. - Examples include kubelet/other node-level endpoints or mis-exposed control plane interfaces. | Security depends on ensuring privileged state changes cannot be performed through weaker paths.

Question 34

What breaks Kubernetes API server trust boundaries in practice?

Answer 34

Cause → system behavior → security impact. - Cause: a privileged node-level endpoint is reachable and accepts weak authentication/authorization. - Behavior: attacker performs actions that impact workloads or secrets without going through intended API server controls. - Impact: attacker escalates from pod foothold to node or cluster impact despite RBAC and admission policy.

Question 35

What is Kubernetes supply chain trust in manifests and Helm?

Answer 35

Supply chain trust is what the cluster accepts as the desired spec and how changes are verified. - Manifests/Helm templates produce Kubernetes objects that the API server stores and acts on. - If the source of manifests or chart content is compromised, the cluster will deploy attacker-chosen specs unless verification gates block it. - Verification can include signature/provenance checks outside the cluster and admission policy checks inside the cluster.

Question 36

How do systems verify what is trusted and what is verified for Kubernetes deployments?

Answer 36

**Step 1:** Deployment inputs are selected (manifests, Helm chart version, values). **Step 2:** CI/CD verifies artifact integrity/provenance for those inputs (digests, signatures) if configured. **Step 3:** API server enforces admission policies and Pod Security on resulting objects. **Step 4:** Only verified inputs plus admitted specs reach running workloads; missing verification means attacker changes can be deployed.