Hacker News Reader

Comment by stigz | Hacker News Reader

This seems to still be very much an AWS/Amazon project with no clear path to becoming its own independent thing. For example, you want vulnerability scanning on the OS? Well you can use an Amazon product for that, otherwise *shrug* [1]. So I guess as long as you plan to run Bottlerocket in AWS, you're fine.

I wish the Bottlerocket team would do 1 of 2 things. Either own up that this is just an AWS project, or start to solve for things like this and actually be a product that "runs in the cloud or in your datacenter" as they suggest on their website.

[1] https://bottlerocket.dev/en/faq/#4_2

View on HN

To be fair, I think "VM" on the OS for Flatcar / BottleRocket / CoreOS is not a requirement in the same way as on RHEL etc.

Do you want to know if you are patched? Are you running the latest version? If so, you have all the available patches.

I appreciate this can cause difficulties in some regulated domains because there's a "vm" box that needs to be ticked on the compliance worksheet.

Most of the reason we need VM on a "traditional" OS is to handle the fact that they have a very broad configuration space and their software composition can be - and often is - pretty arbitrary (incorporating stuff from a ton of sources / vendors and those versions can move independently).

But that's not how you're supposed to use a container OS.

If you do "extra work" to discover vulnerabilities in "latest", you are not really doing the job of a system owner (whose job is to apply patches from upstream in a timely fashion), you are doing the work of a security researcher.

If you’re interested in something not AWS check out Talos https://www.talos.dev/

It’s been around longer than Bottlerocket

It's not like something is stopping one from doing a vuln scan, right? Like, there's something that SSM's in (or uses the admin container) and then runs the scan. Couldn't you just do the same thing?

Genuine questions, I don't know if this is the case or not.

That's a good point. And it sounds like it would work to me as well. I don't know the answer either.

I guess my point is the project should be providing a clear path that doesn't involve AWS instead of just stopping short.

I just wrote a post on this. We have an eBPF + SBOM based security tool and it runs great due to hooking the kernel directly via Kube DaemonSet: https://edgebit.io/blog/base-os-vulnerabilities/

tl;dr: Amazon prioritizes patching really well, fixing real issues first

Why would one need vulnerability scanning on an immutable OS image? It can be done before deploying the image to the host machines.

Indeed, but it's just an example. Imagine it said "For example, you want Feature X on the OS? Well you can use an Amazon product for that, otherwise shrug" instead if it makes it easier.

I missed it was just an example. That’s a fair concern otherwise. Thanks!

Reply on news.ycombinator.com