5 ms·

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

by stigz 3y ago

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 https://bottlerocket.dev/en/faq/#4_2

JustinGarrison 3y ago
If you’re interested in something not AWS check out Talos https://www.talos.dev/ https://www.talos.dev/ It’s been around longer than Bottlerocket
ngrilly 3y ago
Why would one need vulnerability scanning on an immutable OS image? It can be done before deploying the image to the host machines.
- capableweb 3y ago
  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.
  - ngrilly 3y ago
    I missed it was just an example. That’s a fair concern otherwise. Thanks!
insanitybit 3y ago
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.
- robszumski 3y ago
  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/ https://edgebit.io/blog/base-os-vulnerabilities/ tl;dr: Amazon prioritizes patching really well, fixing real issues first
- stigz 3y ago
  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.
xyzzy123 3y ago
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.

by stigz 3y ago

JustinGarrison 3y ago

If you’re interested in something not AWS check out Talos https://www.talos.dev/ https://www.talos.dev/ It’s been around longer than Bottlerocket

ngrilly 3y ago

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

capableweb 3y ago
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.
- ngrilly 3y ago
  I missed it was just an example. That’s a fair concern otherwise. Thanks!

insanitybit 3y ago

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.

robszumski 3y ago
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/ https://edgebit.io/blog/base-os-vulnerabilities/ tl;dr: Amazon prioritizes patching really well, fixing real issues first
stigz 3y ago
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.

xyzzy123 3y ago

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.