Hardening operating system configurations

// Latticework implementation guidance · partial coverage

Set and verify workload isolation defaults

Practical suggestions for a Kubernetes or cloud system. Adapt these steps to your architecture and approved system boundary.

Implementation steps

1. Review ASD and vendor hardening guidance for the workload and runtime. Record conflicts and approved exceptions before changing production.
2. Set non-root execution, a read-only root filesystem, no privilege escalation, restricted capabilities and an appropriate seccomp profile. Remove unnecessary host namespace and hostPath access. Test application compatibility and admission enforcement.
3. Review who can install, load or modify kernel modules and drivers on nodes, including access through privileged workloads and added SYS_MODULE capabilities. Remove unnecessary access and retain approved duties and driver/module policy separately.

Evidence to retain

• Keep the guidance review, pinned policy revision, admitted workload manifests and dated scan or PolicyReport with exclusions.
• Use failing and passing fixtures to demonstrate the enforced policy. Retain runtime and node configuration evidence separately; manifest settings do not prove runtime isolation.
• Retain node access reviews and kernel module/driver configuration. The mapped privileged-container detector does not inspect SYS_MODULE or establish which human users require kernel-mode access.

Responsibility boundary

Platform team: admission controls, runtime and node configuration. Workload team: container settings and compatibility. Organisation: hardening standard, exception approval and system boundary.

The public mapping’s detector allocation is provisional for both managed and self-managed clusters. Agree the responsibility matrix for the engagement; provider inheritance and whole-control ownership require a reviewed system boundary and applicable customer/provider evidence.

Mapped checks to inspect

• kubescape: ism-no-privileged-containers
• kubescape: ism-drop-all-capabilities

These identifiers are from the pinned public mapping. Kyverno mappings describe the policy configuration you must inspect; they do not mean a policy is installed or enforcing. A manifest scan cannot establish live runtime behaviour. Record the exact tool, policy and framework versions, settings, exclusions and execution time with each result.

Review the mapping and control-specific limitations at revision 07b348a. Supporting mapping excerpts (checks, evidence notes and responsibility allocations) are adapted from Latticework Systems’ public repository under Apache-2.0. ASD’s control wording stays under CC BY 4.0.

Official source

ASD’s ISM OSCAL v2026.09.4 · Original catalogue JSON · Pinned checksums and edition details

Control source identifier: ism-2128. Check the official release before relying on this snapshot for an assessment.