I would like to document a recurring compliance oversight I have observed, both in my own early implementations and in several recent audit reviews of containerized workloads. The oversight pertains to the omission of resource limits—specifically CPU and memory—within the pod specification. While the principle of constraining resources is a well-established tenet in risk management frameworks, its practical application in container orchestration is frequently deferred or neglected entirely, leading to systemic stability risks.

From an information security and operational risk perspective, the failure to define resource limits creates a significant control gap. Without these constraints, a single containerized process, potentially compromised or simply malfunctioning, can consume all available node resources. This scenario directly impacts the confidentiality, integrity, and availability of co-located workloads, violating the core principles of data classification and isolation. Consider a container hosting an OpenClaw agent process: if it were to develop a memory leak, it could starve other critical security or application containers on the same node, thereby disabling the security monitoring for multiple workloads simultaneously.

The compliance implications are equally serious. Frameworks like SOX, which mandate controls over financial reporting systems, and GDPR, which require appropriate technical measures to ensure data security, implicitly demand that such resource exhaustion risks be mitigated. An audit trail would show a lack of preventive controls, and in the event of an incident, the inability to demonstrate guaranteed resource allocation for critical functions would be a notable finding.

Implementing these limits is methodically straightforward. A basic but effective configuration should, at minimum, include both `requests` and `limits`. The `requests` inform the scheduler, while the `limits` enforce a hard ceiling at runtime.

Example structure for a container spec:
```
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
```

I recommend the following steps be integrated into the standard container hardening checklist:
* Establish organization-wide baseline `requests` and `limits` for different workload classifications (e.g., agent, frontend, backend, database).
* Enforce these baselines via admission controllers or policy engines (e.g., OPA/Gatekeeper, Kyverno) to prevent deployments without resource definitions.
* Ensure monitoring and audit trails are configured to alert on and log limit violations (e.g., Kubernetes `OOMKilled` events, CPU throttling metrics).

This control is not merely a performance configuration; it is a foundational security and compliance requirement for any production runtime environment.

CIS controls applied.