← CKS: Kubernetes security in production
03 / 8 · 28 MIN

Linux hardening and kernel controls

Connect syscalls, local profiles, and node preparation.

Concept and mechanism

A container process still uses the kernel of its execution environment. Protection layers have different roles: capabilities limit privilege classes, seccomp filters syscalls, and AppArmor can apply process-associated access rules. Do not confuse these mechanisms with API RBAC. When EPERM appears after a profile change, correlate the call, effective profile, and functional need. Allowing every syscall can hide the symptom while removing protection. Diagnosis should produce a justified minimal change and a test of both permitted behavior and behavior that should remain blocked.

Guided application

Localhost profiles add an operational dependency: they must exist on the node where the Pod starts. In an autoscaling cluster, manually copying a file to two nodes does not prepare future nodes. Include profile distribution, version, and validation in provisioning. Likewise, removing unnecessary remote services needs consumer inventory and recovery planning. For a time-sensitive batch, already prepared capacity can be used while fixing the process if capacity is sufficient and the decision is approved. Do not turn privileged into a universal fix. Document profile ownership, runtime-update testing, and detection of drift before receiving traffic.

IN PRACTICE

If only new nodes fail with a missing profile, address provisioning before changing application code.

Common pitfalls

Profile in Git treated as installed profile; privileged treated as neutral; RBAC treated as syscall control; nonrepeatable manual fix.

Related topics: Admission and workload protection · Secrets, encryption, and recovery

Take this idea with you

The control must be present, enforced, and maintained on every eligible node.

Create account

Reference: Linux kernel security constraints · Kubernetes v1.35; current six-domain CKS outline