Overview
A container-optimized OS is an operating system image that is designed for secure managed hosting of containers on compute instances.
Use cases for container-optimized OSes might include:
- Docker container or Kubernetes support with minimal setup.
- A small-secure container footprint.
- An OS that is tested, hardened, and verified for running Kubernetes nodes in your compute instances.
Rationale
Container-optimized OSes have a smaller footprint which will reduce the instance's potential attack surface. The container runtime is pre-installed and security settings like locked-down firewall are configured by default. Container-optimized images may also be configured to automatically update on a regular period in the background.
Impact
A container-optimized OS may have limited or no support for package managers, execution of non-containerized applications, or ability to install third-party drivers or kernel modules. Conventional remote access to the host (i.e. ssh) may not be possible, with access and debugging being intended via a management tool.
Audit
If a container-optimized OS is required examine the nodes in EC2 and click on their AMI to ensure that it is a container-optimized OS like Amazon Bottlerocket; or connect to the worker node and check its OS.
References
Remediation guidance
Depending on the provider and service that you use, check out the following resources:
AWS
- You can launch Auto Scaling groups of Bottlerocket nodes that register with your Amazon EKS cluster. After the nodes join the cluster, you can deploy Kubernetes applications to them. For more information, see Launching self-managed Bottlerocket nodes
Multiple Remediation Paths
SERVICE-WIDE (RECOMMENDED when many resources are affected): Apply organization/tenant-level guardrails and baseline policies for the entire platform.
ASSET-LEVEL: Fix only the affected resources identified by this control.
PREVENTIVE: Add preventive policy checks to CI/CD and periodic posture scans.
References for Service-Wide Patterns
- Platform policy/governance and preventive control patterns should be applied tenant-wide where supported.
Query logic
These are the stored checks tied to this control.
Kubernetes nodes without container-optimized OS
Connectors
Covered asset types
Expected check: eq []
{
kubernetesNodes(where: { osImage_NOT_STARTS_WITH: "Bottlerocket" }) {
...AssetFragment
}
}
Kubernetes