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
xyzzy123|2 years ago
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.
JustinGarrison|2 years ago
It’s been around longer than Bottlerocket
insanitybit|2 years ago
Genuine questions, I don't know if this is the case or not.
stigz|2 years ago
I guess my point is the project should be providing a clear path that doesn't involve AWS instead of just stopping short.
robszumski|2 years ago
tl;dr: Amazon prioritizes patching really well, fixing real issues first
ngrilly|2 years ago
capableweb|2 years ago