Some notes about Bottlerocket Security

This post includes some notes about Bottlerocket security.

• CIS Hardening Benchmark for Bottlerocket
• FIPS Support / ValidationDoes Bottlerocket have integration with AWS Inspector?
• Is OS host logs available? Does it have integration with CloudWatch Log?
• Reduced attack surface, verified software, enforced permission boundaries
• ECS/EBS encryption vs. OS crypto

CIS Hardening Benchmark for Bottlerocket

Bottlerocket now has a Center for Internet Security (CIS) Benchmark. The CIS Benchmark is a catalog of security-focused configuration settings that help Bottlerocket customers configure or document any non-compliant configurations in a simple and efficient manner. The CIS Benchmark for Bottlerocket includes both Level 1 and Level 2 configuration profiles.

See also https://github.com/bottlerocket-os/bottlerocket/issues/1297

FIPS Support / Validation

Issue (Open): https://github.com/bottlerocket-os/bottlerocket/issues/1667

FIPS compliance is our second most requested feature, behind CIS (which is in progress), and I'm planning to focus on it once the CIS benchmark is complete.

Does Bottlerocket have integration with AWS Inspector?

Coming Soon - Issue (Open) https://github.com/bottlerocket-os/bottlerocket/issues/2056

We're working with the AWS Inspector team to add first-class support for Bottlerocket - meaning that its vulnerability scan would be aware of our security advisories and flag nodes that are not running versions of Bottlerocket that contain the fix.
It's tentatively slotted into the 1.10.0 release, roughly August.

Is OS host logs available? Does it have integration with CloudWatch Log?

No. There is no current plan to add a logging agent to the host OS.

Issue (Open) https://github.com/bottlerocket-os/bottlerocket/issues/850

Comments from Maintainers:

We have no current plans to add a logging agent to the host OS.

When talking with many EKS customers, we found that a common pattern is to use Kubernetes facilities for log streaming, even for system level logs. Another method is to use Fluent Bit as covered in this blog post. These are our suggested methods for customers to get both container logs as well as other logs off the box.

Reduced attack surface, verified software, enforced permission boundaries

• Bottlerocket contains less software, and notably eliminates some components you might expect: Bottlerocket doesnt have SSH, any interpreters like Python, or even a shell; it is expected that Bottlerocket to be "hands-off" most of the time, and removing components like this makes it harder for an attacker to gain a foothold in the system. Beyond removal of software, Bottlerocket also reduces the attack surface of the operating system by applying software hardening techniques like:
  • building position-independent executables (PIE),
  • using relocation read-only (RELRO) linking, and
  • building all first-party software with memory-safe languages like Rust and Go.
• Bottlerocket uses SELinux in enforcing mode to restrict modifications to itself even from privileged containers. SELinux is an implementation of Mandatory Access Control (MAC) enforced by the Linux kernel, and limits the set of actions processes can take. Today, Bottlerockets SELinux policy is intended to restrict orchestrated containers from causing undesired and unexpected changes to the operating system. Going forward, we want to extend this policy to apply to all categories of persistent threats.

See

• Blog post: https://aws.amazon.com/blogs/containers/bottlerocket-a-special-purpose-container-operating-system/
• Bottlerocket Packages

ECS/EBS encryption vs. OS crypto

Bottlerocket operates with 2 default storage volumes - standard EBS encryption applicable

• The root device, holds the active and passive partition sets. It also contains the bootloader, the dm-verity hash tree for verifying the immutable root filesystem, and the data store for the Bottlerocket API.
• The data device is used as persistent storage for container images, container orchestration, host-containers, and bootstrap containers.

Bottlerocket cryptographically verifies itself

The operating system is composed of a disk image that is verified on boot with dm-verity; unexpected changes to the contents of the disk image will cause the operating system to fail to boot.

Bottlerocket uses its own software updater rather than a more common Linux package manager. Updates to Bottlerocket are vended from a repository that follows The Update Framework (TUF) specification; TUF mitigates common classes of attacks against software repositories present in traditional package manager systems.

Source: https://aws.amazon.com/blogs/containers/bottlerocket-a-special-purpose-container-operating-system/