TT Lab
Get started
Learn Learning paths Courses

KCSA — Kubernetes Security Associate

A Framework Is a List of Questions, Not the Answer

Continue in TT Lab

In one line

CIS, NSA/CISA, and MITRE ATT&CK are not competing standards but tools with different roles. CIS is a configuration checklist, NSA/CISA is a design guide, and ATT&CK is a dictionary of attacker behavior. And what ties these three to real evidence is the audit log.

Why this was needed

To answer "is our cluster secure?", you need a standard. Without one, inspections differ from person to person, you cannot compare last year and this year, and you cannot explain to outsiders.

The value of a framework is completeness and a common language. It reduces omissions and makes different organizations use the same words. But a framework does not tell you "if you do this, you are safe." It is a list of questions, not an answer key.

How it works

CIS Kubernetes Benchmark — a configuration checklist

Each item is a concrete checklist asking "is this setting at this value?" It is divided by area: control plane file permissions, apiserver flags, etcd settings, the controller manager and scheduler, the kubelet, and policies.

A caution when using CIS — many items do not apply to managed clusters (EKS/GKE/AKS). Because you cannot access the control plane files. That is why a separate benchmark for managed clusters exists. More than the number "how many items passed," understanding why each item exists matters both on the exam and in the field.

NSA/CISA Kubernetes Hardening Guidance — a design guide

It is not a checklist but a narrative guide that says "design it like this." It is organized into five axes.

  1. Pod security — running as non-root, immutable filesystems, image scanning, admission policy
  2. Network separation and hardening — namespace separation, NetworkPolicy, restricting control plane access, encryption at rest and in transit
  3. Authentication and authorization — disabling anonymous access, strong user authentication, RBAC least privilege
  4. Log auditing — enabling audit logging, sending logs out of the cluster, configuring alerts
  5. Upgrades and configuration management — regular patching, removing unneeded components, periodic vulnerability checks

If CIS asks "is this value right?", NSA/CISA asks "is this structure right?" The two are complementary.

MITRE ATT&CK for Containers — a dictionary of attacker behavior

It is not from the defender's point of view but lists what attackers actually do as tactics and techniques. The tactic flow of the containers matrix is roughly as follows.

초기 접근 → 실행 → 지속성 → 권한 상승 → 방어 회피 → 자격증명 접근
        → 탐색 → 측면 이동 → 영향

The representative techniques in it overlap exactly with what we saw in the earlier modules — initial access through an exposed API, execution through container deployment, escape through a privileged container, credential access through the container API, and cluster resource discovery.

The use of ATT&CK is detection design. If you ask, technique by technique, "can we detect this technique?", then log collection and alert rules become concrete. If CIS is on the prevention side, ATT&CK is on the detection side.

Audit logs — what ties the three frameworks to evidence

The audit log does three jobs in compliance.

  1. Proof — show "we operate this control" with records
  2. Investigation — reconstruct what happened when an incident occurs
  3. Detection — find the signals of an attack in progress

Kubernetes' audit policy adjusts the recording volume in four levels.

Level What is recorded
None Not recorded
Metadata Requester, action, resource, and time. No body
Request Metadata + the request body
RequestResponse Metadata + the request + the response body

If you apply RequestResponse to a resource such as Secrets, the audit log itself becomes a secret leak path. So practical policies usually keep Secrets and ConfigMaps at Metadata only, and record sensitive things such as changes to RBAC objects at RequestResponse.

And something just as important as what you record — do you record denials? Permission probing shows up only as a repetition of failures. A pattern in which one subject is denied dozens of times against different targets in a short period is the fingerprint of an enumeration attempt. If you do not record denials, that signal does not exist. The reverse is useful too — if denial logs suddenly disappear after a deployment, you should suspect that the check itself may have disappeared.

Finally, logs must be sent out of the cluster. Logs inside a compromised cluster can be erased, and the Pods may already be gone.

What it looks like in the field

The RBAC audit procedure presented on the author's blog is a good example of turning CIS items into real queries.

The emphasis here is that there is a set cadence. It means compliance is not a one-time inspection but an operating routine.

The author's argument about wildcard permissions is also worth quoting as it is — if you use resources: ["*"] or verbs: ["*"], you allow unlimited access not only to the present but also to resources added in the future. It is a logic that cuts off exactly the rebuttal "it's safe for now, so it's fine."

The operating principles of policy engines are also worth reading from a compliance perspective — manage them as Policy as Code, always assess the impact with dryrun before a change, and prepare in advance an emergency recovery procedure for outages. And the author's last sentence — "RBAC and policy engines are technical tools, but to operate them effectively you must connect them with the organization's access control governance."

What you will do in the next lab

In the last lab, you run a cluster-wide RBAC audit yourself. You find the ClusterRoles that have * permissions and list them, detect those that have escalate, bind, and impersonate, check a service account's effective permissions with kubectl auth can-i --list --as=, create a new least-privilege Role and prove by measurement that only what you want works and the rest does not, and then write an audit report that gathers that evidence.