Compliance And Security Frameworks practice questions

Host OS security

Why it fails: Host OS security focuses on the underlying node kernel and OS hardening.

Runtime orchestration security

Why it fails: Orchestration security handles pod placement, network policies, and RBAC.

Cluster networking

Why it fails: Cluster networking manages traffic flow between pods and services.

hostNetwork: true

Why it fails: hostNetwork shares the node network namespace with the pod.

readOnlyRootFilesystem: false

Why it fails: This controls whether the root filesystem is mutable.

privileged: true

Why it fails: Privileged mode grants full access to host capabilities.

DefaultTolerationSeconds

Why it fails: DefaultTolerationSeconds sets default eviction tolerations.

AlwaysAdmit

Why it fails: AlwaysAdmit allows all requests and is discouraged by CIS.

NodeRestriction

Why it fails: NodeRestriction limits what kubelets can modify.

Ensure that the --tls-cert-file argument is omitted

Why it fails: TLS certificates are required for secure kubelet communication.

Enable the NodeRestriction admission controller to limit kubelet permissions.

Why it fails: The NodeRestriction admission controller restricts what a kubelet can modify about its own Node and Pod objects; it does not constrain the privileges of container workloads. It addresses node-level API access, not workload privilege escalation. For least-privilege container execution, the team needs controls that directly limit the capabilities and privilege of running containers, which NodeRestriction does not provide.

Configure the kube-apiserver with --authorization-mode=RBAC,Node.

Why it fails: Setting the authorization mode to RBAC and Node ensures that API requests are authorized using role-based access control and node authorizers, but it does not restrict container runtime privileges. This controls who can perform actions on the API server, not what a container can do once running. The auditor's concern is about workload privilege, so this setting alone is insufficient.

Use Kubernetes NetworkPolicies to deny all ingress traffic to the workloads.

Why it fails: NetworkPolicies control network traffic to and from pods, which is a network segmentation control. They do not affect the Linux capabilities, privilege escalation, or user context of containers. While network policies are important for least privilege in networking, they do not address the excessive process privileges that the auditor is asking about, so they are not the right mechanism here.

ValidatingWebhookConfiguration

Why it fails: ValidatingWebhookConfiguration intercepts API requests to validate object schemas and admission policies, not to authorise the requesting identity. It cannot grant or deny access based on user, group or service account. It is the right object when you need custom admission-time validation, such as rejecting non-compliant pod specs before persistence.

NetworkPolicy

Why it fails: NetworkPolicy governs pod-level traffic filtering, not API server authorisation; fine-grained authorisation decisions at the API server are enforced by RBAC through Roles, ClusterRoles and bindings. NetworkPolicy is correct when the requirement is restricting ingress and egress traffic between pods within the cluster.

ResourceQuota

Why it fails: ResourceQuota caps aggregate resource consumption per namespace, such as CPU, memory and object counts. It makes no authorisation decision about who may call which API verb on which resource. It is the correct object when the requirement is to constrain namespace resource usage, not to enforce NIST AC access control.

Clusters

Why it fails: Clusters sit above the cloud layer, covering orchestration and nodes, not physical data centres and hardware. It is tempting because cluster security is prominent in cloud-native work, but the outermost layer encompassing physical infrastructure is the cloud layer, not clusters.

Code

Why it fails: Code is an inner layer covering application source and dependencies, not physical data centres and hardware. It is tempting because code security is central to cloud-native practise, but the outermost layer encompassing physical infrastructure is the cloud layer, not code.

Containers

Why it fails: Containers sit innermost, above the cluster and code layers, so they cannot represent physical data centres and hardware. It is tempting because container security is a core cloud-native concern, but the outermost layer covering physical infrastructure is the cloud layer, not containers.

--authorization-mode=Node,RBAC

Why it fails: Node,RBAC governs authorisation of authenticated requests, not authentication of unauthenticated ones, so anonymous requests still reach the API server. It would be correct when restricting which nodes and users may perform actions after identity is established.

--enable-admission-plugins

Why it fails: This flag enables specific admission control plugins.

--insecure-port=0

Why it fails: Disabling the insecure port is a separate CIS control.

Log shippers

Why it fails: Log shippers forward runtime logs to a backend; they neither parse manifests nor evaluate them against policy before apply. A manifest-scanning admission or CI tool is needed. Log shippers are correct for aggregating container and node logs for later search.

Packet analyzers

Why it fails: Packet analyzers capture and decode network traffic, which carries no manifest content, so misconfigurations in YAML are invisible. Static manifest scanning is required. Packet analysis is correct for diagnosing network faults or inspecting unencrypted protocol exchanges.

Kernel debuggers

Why it fails: Kernel debuggers inspect running kernel state and memory, operating after deployment rather than scanning manifests pre-apply. A manifest-scanning policy tool is needed. Debuggers are correct for diagnosing kernel crashes or driver faults, not for shift-left configuration auditing.

cgroups v2

Why it fails: cgroups v2 limits and accounts for CPU, memory and I/O consumption; it does not filter which system calls a process may invoke. It is tempting because both are runtime isolation primitives, but cgroups v2 is the correct control for resource exhaustion, not syscall least privilege.

AppArmor MAC profiles

Why it fails: AppArmor confines a process to a path-based profile governing file and capability access; it does not intercept the syscall table, so individual calls cannot be allowed or denied. AppArmor is correct when restricting a container to specific filesystem paths rather than filtering syscalls.

Namespaces

Why it fails: Namespaces partition kernel resources such as PIDs, mounts and network interfaces, giving each container an isolated view; they do not restrict which system calls a process may make. Namespaces are correct for isolating containers from one another, not for enforcing syscall least privilege.

strict

Why it fails: The CIS Benchmark requires anonymous authentication disabled, so the value must be false; strict is not a recognised setting for this boolean parameter and would not disable anonymous requests. It is tempting because strict sounds like the most locked-down posture, and would be correct for a genuinely strict-mode authentication field.

auto

Why it fails: 'auto' is not a valid value for authentication.anonymous.enabled; the parameter accepts only true or false, so it cannot satisfy the benchmark. It is tempting because kubelet's clientCAFile and webhook modes use 'auto'-style negotiation elsewhere, but anonymous authentication itself is strictly boolean.

true

Why it fails: Setting anonymous authentication to true is precisely the insecure state the auditor flagged, so it cannot be the CIS-compliant value. It is tempting because anonymous access genuinely simplifies unauthenticated health probes and metrics scraping in isolated lab clusters, where no API credentials exist.

kube-hunter

Why it fails: kube-hunter performs penetration testing, probing for exploitable vulnerabilities from an attacker's perspective, rather than checking configuration against CIS control items. It is tempting because it targets Kubernetes clusters, but it reports attack paths, not the pass/fail benchmark results kube-bench generates.

falco

Why it fails: Falco is a runtime security monitor that detects anomalous syscall and container behaviour, not a CIS Benchmark compliance scanner. It is tempting because it audits Kubernetes activity, but it produces runtime alerts rather than the configuration checks kube-bench performs against CIS control items.

velero

Why it fails: Velero backs up and restores cluster resources and persistent volumes; it performs no configuration assessment. It is tempting because it inspects cluster objects, but its purpose is disaster recovery and migration, whereas CIS Benchmark evaluation requires kube-bench's control-by-control checks.

Trivy

Why it fails: Trivy scans container images, filesystems and IaC for known vulnerabilities and misconfigurations before deployment; it does not hook system calls at runtime. It is the correct tool when the requirement is pre-deployment image scanning rather than live intrusion detection.

Fluentd

Why it fails: Fluentd is a log collection and forwarding agent, aggregating and shipping telemetry rather than inspecting system calls against rule sets. It would be the right pick when the requirement is centralised log aggregation across containers, not runtime threat detection.

Cert-manager

Why it fails: Cert-manager automates issuance and renewal of TLS certificates inside Kubernetes; it has no system-call monitoring or rule-evaluation capability. It would be the right choice when the requirement is automated certificate lifecycle management, not runtime security enforcement.

kubeadm.conf

Why it fails: kubeadm.conf configures cluster bootstrap parameters for kubeadm, such as networking and versions, and is consumed only during init or join. It cannot specify audit rules or levels. It is tempting because it is a central cluster configuration file, but audit policy belongs in the separate audit policy YAML passed to kube-apiserver.

Kubelet configuration file

Why it fails: The kubelet configuration file governs kubelet behaviour such as pod admission and node settings, not kube-apiserver audit policy. Audit rules and levels live in the audit policy file passed via --audit-policy-file. It is tempting because kubelet configs are commonly edited on nodes, but they cannot define which API requests are logged.

Admission configuration YAML

Why it fails: Admission configuration YAML controls admission control plugins and their ordering, not audit logging rules. The audit policy file, referenced by --audit-policy-file, defines which requests are logged and at what level. It is tempting because both are apiserver flags, but admission config governs request mutation and validation, not audit event selection.

Kubelet TLS bootstrapping

Why it fails: Kubelet TLS bootstrapping issues client certificates so kubelets authenticate to the API server; it never touches etcd storage, so Secrets remain unencrypted. It is tempting because it is a security-related Kubernetes configuration, and would be correct if the audit asked how kubelet-to-API-server authentication is established.

SecretProviderClass CRD

Why it fails: SecretProviderClass is a Secrets Store CSI Driver CRD that mounts external secrets into pods; it does not configure etcd storage encryption, so data at rest stays plaintext. It is tempting because it concerns secret handling, and would be correct if the requirement were retrieving secrets from an external vault.

ServiceAccount token volume projection

Why it fails: ServiceAccount token volume projection mounts short-lived, audience-bound tokens into pods; it never touches etcd storage. Encryption at rest is configured through the kube-apiserver's encryption configuration, which defines EncryptionConfiguration providers for Secret resources. Token projection is tempting because it hardens credential handling, but it addresses token lifetime and audience, not data-at-rest encryption.

NIST SP 800-37

Why it fails: NIST SP 800-37 defines the Risk Management Framework process for authorising and continuously monitoring information systems, not container-specific controls. It suits enterprise RMF authorisation work. Container and orchestration security is specifically addressed by NIST SP 800-190, Application Container Security Guide.

NIST SP 800-53

Why it fails: NIST SP 800-53 is a broad catalogue of security and privacy controls for federal information systems, not a container-specific publication. It is the right choice when selecting control baselines for system accreditation. Container and orchestration security is specifically addressed by NIST SP 800-190, Application Container Security Guide.

NIST SP 800-88

Why it fails: NIST SP 800-88 covers media sanitisation and data disposal techniques, not container or orchestration security. It is the right reference when planning secure erasure of storage media. Container and Kubernetes security guidance is addressed by NIST SP 800-190, Application Container Security Guide.

777

Why it fails: World-writable permissions let any local user alter kubelet configuration and escalate to node compromise, directly violating CIS 4.2.x. The 777 mode is used for shared scratch directories where every account must write, never for credential files.

755

Why it fails: Group and world read/execute bits on a kubelet config expose cluster credentials to any local account, breaching CIS 4.2.x, which mandates 600. The 755 pattern suits executables or directories needing traversal, not secret-bearing configuration files.

644

Why it fails: CIS requires kubelet.conf to be 600, restricting it to root; 644 lets any local user read credentials and cluster endpoints. It is tempting because 644 is the default for many configuration files, and it would be acceptable only for non-sensitive files that all users must read.

Envoy

Why it fails: Envoy is a layer 7 proxy handling traffic routing, load balancing and mTLS between services; it holds no CVE database and never reads image contents. It is tempting because Envoy appears in service mesh security discussions, but it would be correct for questions about ingress, traffic policy or mutual TLS enforcement.

CoreDNS

Why it fails: CoreDNS resolves service names inside the cluster; it does not inspect image layers or match packages against CVE databases. It is tempting because DNS is part of every cluster, but CoreDNS would be the answer to a question about service discovery or cluster DNS resolution failures, not vulnerability scanning.

Calico

Why it fails: Calico enforces network policy and pod-to-pod connectivity at layer 3/4; it does not unpack images or compare installed packages against CVE feeds. It is tempting because Calico is a security-adjacent component, but it would be the right answer for questions about network segmentation or egress restrictions between namespaces.

Increasing pod memory limits

Why it fails: Increasing pod memory limits addresses resource contention, not image integrity; it cannot verify signatures or digests. It is tempting because memory limits do govern runtime pod behaviour, and raising them is the right response to OOMKilled containers or memory-pressure evictions — a capacity-tuning scenario, not cryptographic enforcement.

Disabling the default namespace

Why it fails: Disabling the default namespace addresses workload isolation and RBAC scoping, not image integrity; it neither verifies signatures nor blocks unsigned images from starting. It is tempting because removing the default namespace is a genuine hardening step for multi-tenant clusters, but admission control with signature verification (for example, Sigstore policy enforcement) is what satisfies this requirement.

Using ClusterRoleBindings with wildcards

Why it fails: ClusterRoleBindings with wildcards grant broad RBAC permissions across the cluster; they perform no cryptographic verification of image digests or signatures, so runtime integrity cannot be enforced. They are tempting because RBAC genuinely controls who may deploy workloads, and least-privilege ClusterRoleBindings would be the right answer to an authorisation-scoping question.

IPsec tunnel encapsulation

Why it fails: CIS benchmarks require etcd peer and client connections to use TLS certificates, not IPsec encapsulation, so this fails the stated control. It is tempting because IPsec does encrypt traffic between hosts, and it would be correct for securing node-to-node communication at the network layer rather than etcd's own client authentication.

HTTP with token bearer headers

Why it fails: CIS benchmarks require etcd peer and client traffic to use TLS certificates for mutual authentication, so bearer tokens over plain HTTP leave the data store open to any client that can reach the port. Token headers suit API-server authentication, not etcd's certificate-based transport security.

Plaintext loopback interface binding

Why it fails: Binding etcd to the loopback interface restricts it to local clients only, which breaks the multi-node client access the audit requires. It is tempting because loopback binding genuinely removes external exposure, and it would be correct for a single-node development cluster where no remote client connects.