AWS announced a Linux based operating system called Bottlerocket.
InfoQ caught up with Deepak Singh, VP of compute services at AWS, regarding details about the announcement.
Deepak Singh covers the motivation for a new Linux-based operating system and how it builds on the lessons learned from operationalizing Amazon Linux, primarily dealing with security and performance issues.
He talks about how these issues are addressed in Bottlerocket and the roadmap which goes beyond the current Kubernetes support.
InfoQ: What makes Bottlerocket unique? Can you go into the brief history of how this came about?
Deepak Singh: Before starting to build Bottlerocket, we spent a long time learning about what options were already available and talking with our customers about what a container focused distro should look like. What we wound up building is based on asks from those customers as well as what we’ve learned operating Amazon Linux. The things we felt were critical to address were:
- Security as a top priority: We’ve done this with dm-verity during boot and SELinux policies. We have plans for more work in this vein too including enabling customers to launch Firecracker VMs on Bottlerocket hosts.
- Flexibility: we wanted to be able to extend Bottlerocket to meet new and emerging customer needs. This manifested itself in a custom build system that we feel is the right balance between ease of use and complexity. We also worked hard to make design decisions that would allow a future where there are many variants of Bottlerocket, each tailored to meet the needs of specific customers.
- Modeled API settings: With Amazon Linux, we have a lot of experience with the complexity that comes with flexibility. We started from the idea that we should understand deeply all the configuration options we expose to customers. That way we can also reason about how changes to the OS might impact our customers and we can guard against breakage.
InfoQ: Can you go into a bit of technical depth as to how Bottlerocket improves protections for some of container-related issues such as security, start up time and so on?
Singh: Bottlerocket employs a number of techniques to help improve the security of the operating system, with a special focus toward both reducing the overall attack surface and enhancing barriers to establishing persistent threats. Bottlerocket limits the attack surface through an overall reduction in the amount of software included in the operating system, eliminating components that can be used in executing or escalating an attack like a shell, interpreters like Python, and even SSH. Bottlerocket employs an SELinux policy designed to restrict containers from causing undesired and unexpected changes to the operating system. Bottlerocket also applies modern 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.
Unlike most Linux distros, Bottlerocket has its root filesystem mounted as read-only. Bottlerocket also uses dm-verity to cryptographically verify that the contents of the filesystem have not changed. These techniques help to increase the difficulty of establishing an attack that can persist through updates and reboots.
InfoQ: Is the SDLC for Bottlerocket based apps exactly the same as running on any other OS? i.e. Do Developers and Devops users have to learn and use new tools?
Singh: Bottlerocket is designed so that developers can continue building their applications the same way that they do today. Bottlerocket uses containerd as its container runtime, which is conformant with the Kubernetes CRI; developers should be able to take their existing containers and run them on Bottlerocket without modification.
Bottlerocket is a bit different operationally. Bottlerocket uses an image-based update system instead of package-by-package updates, to make the operating system more consistent and predictable. Bottlerocket’s configuration is driven by its API and is strongly typed and validated before being applied to a given piece of software instead of the more traditional per-package configuration file (each with its own format). Bottlerocket does not include common system utilities like ps or top and does not make the operating system accessible over SSH; this is part of Bottlerocket’s design for security. Instead, Bottlerocket is intended to be operated from within its “control” and “admin” containers and provides tooling to “break-glass” for debugging.
InfoQ: Is this going to be an AWS play only? Or is there a plan/effort to make this available on multiple clouds?
Singh: I think it is important to distinguish between two things: AWS AMIs that we provide to our customers and the project we launched on GitHub. For the open source project, we’re excited to work with the community to define the path. We’ve built Bottlerocket in a way that it can be extended and modified by our users. We’d love to see community involvement in building new variants that have other orchestrators, new API features or something else we haven’t even thought of yet.
InfoQ: Can you outline the roadmap for Bottlerocket? Specifically into how it can be extended beyond Kubernetes?
Singh: Our roadmap is available on GitHub.Bottlerocket supports Kubernetes today, but Bottlerocket is not meant to be a Kubernetes-only operating system. It’s on our roadmap to add support for Amazon ECS on Bottlerocket and to integrate behaviors like non-disruptive updates into Amazon ECS clusters.
Security is an ongoing theme for our roadmap. We will continue to iterate and improve on the Bottlerocket SELinux policy, and we’re exploring ways to reduce the level of filesystem access to regular orchestrated containers. We’re also taking a look at alternative methods of running containerized workloads, including inside microVMs with Firecracker for use-cases that require high degrees of isolation.
We’re also planning to add support to Bottlerocket for additional EC2 hardware options, like instance types with attached GPUs or Arm processors.
In summary, Singh talked about the evolution of Bottlerocket and how it addresses some of the operational issues behind running containers on Amazon Linux or other regular Linux distros. He also talks about how EC2 and other compute services including GPUs that could potentially leverage these same improvements in Bottlerocket. Roadmap, getting started and other details about the project are on GitHub.