Integration with Aws inspector

[rverma-jm]

Can we have preinstalled inspector agent on this. Also can we evaluate the default inspector report generated over this. For eks ami it always shows multiple vulnerabilities.

[iliana]

Could you tell me more about your use cases for the Inspector agent?

Because Bottlerocket is built from scratch and not based on an existing Linux distribution (apart from using an Amazon Linux 2 kernel), without some additional work with the team that maintains the Inspector agent I'm not sure it would tell you anything useful.

If you're looking for patching status information, there are no package upgrades with Bottlerocket; there is simply the Bottlerocket image version. We recommend users set up automatic updates. A host is considered patched when it's on the latest available version of the OS.

[philm]

Since Bottlerocket is based on AL2, are the changes published on https://alas.aws.amazon.com incorporated in each update? Or will there be a separate list of vulnerabilities, perhaps in this repo?

[jhaynes]

@philm Bottlerocket isn't based on AL2. We use the AL2 5.4 kernel source (and apply a few changes), but otherwise, the entire OS is built directly from upstream sources.

As far as vulnerability reporting, we’re initially looking at using GitHub’s security advisories, to keep things open and as close as possible to the project.

[rverma-jm]

My usecase revolves around compliance reporting. Currently we use aws provided CIS and cve rulesets. It would be nice if either aws can publish a different set of cis and cve rulesets for this os too, removing the rules which are not applicable. Also would be nice to publish an official list of those not applicable rules too. It's very helpful in dealing with old school clients :)

[rverma-jm]

@iliana , @jhaynes is there any progress on this. Even wondering if we can install inspector agent using ssm, i doubt it will work as of now.

[mattlorimor]

Could you tell me more about your use cases for the Inspector agent? - @iliana

As @rverma-jm suggested: in addition to other compliance frameworks, obtaining and maintaining a FedRAMP Authorization to Operate (ATO). Specifically, meeting control RA-5 (essentially NIST RA-5). There are strict CVE scanning, reporting, and remediation guidelines regarding host operating systems.

I can find no mention of Bottlerocket on the Services in Scope page or in the entire FedRAMP partner package. It's probably new enough that it's silly to expect it to be mentioned anyway.

In the absence of a tool that can effectively scan and report on CVEs in packages in a host OS, one would have to look toward the claim that:

A host is considered patched when it's on the latest available version of the OS. - @iliana

and:

Bottlerocket isn't based on AL2. We use the AL2 5.4 kernel source (and apply a few changes), but otherwise, the entire OS is built directly from upstream sources. - @jhaynes

A Cloud Service Provider (CSP) striving for their initial ATO or one attempting to work Bottlerocket into their processes and documentation would face some hurdles, though I'm not convinced they are insurmountable. A CSP would have to work with their Third Party Assessment Organization (3PAO) and/or the Program Management Office (PMO) out-of-band or during an annual assessment to make sure an understanding is reached about the following:

• Explain what Bottlerocket is: a minimalist host OS designed specifically to run Docker workloads
• Explain how it differs from running something like RHEL or AL2 and the ability to scan them with something like Amazon Inspector or a Tenable product
• Conversations and claims like those I quoted above, along with the official documentation, would certainly be referenced as evidence for what "updated" and "vulnerable" mean in the context of Bottlerocket.

If a CSP were attempting to run Bottlerocket in a FedRAMP-regulated space, it would essentially have to strive for an alternative implementation showing that the intent of the control is met - justification for RA-5 that redefines "scanning" (in the context of host OSs) more to mean doing an inventory of the version of Bottlerocket being used within the Authorization boundary and comparing it against what the latest version available is. Anything not running the latest version would be considered "vulnerable" and be updated within the minimum remediation timeline of thirty days. If not, it'd be reported. The 3PAO, PMO, Authorizing Agency, or any combination of the three may or may not accept the alternative implementation.

I'm not sure how something like this page would come into play: https://github.com/bottlerocket-os/bottlerocket/security/advisories.

All of this becomes a heck of a lot easier if there were a tool, like Inspector, that can scan and report on vulnerabilities.

[mattlorimor]

@iliana

As a minor follow-up to the thoughts in my previous comment...

As far as vulnerability reporting, we’re initially looking at using GitHub’s security advisories, to keep things open and as close as possible to the project. - @jhaynes

This is a stance I have an easy time sympathizing with.

It makes sense that the Bottlerocket team/project would be owners of the security advisory process and that the medium of choice for disclosure is via GitHub Security Advisory (GHSA), but that seems about as far as I would reasonably expect them to go. In this case, GHSA is to Bottlerocket as Amazon Linux Security Advisories (ALAS) is to AL2.

I don't know how Inspector builds its database of things to look for in the OSs it supports, but trivy, a Docker image scanning tool from Aqua, looks directly at ALAS advisories in order to build its vulnerability database for AL2. It does something similar for all the other OSs and language dependency ecosystems it supports scanning. I'm sure other scanning tools and organizations do similar vuln database building. It's not out of the question that somebody other than Amazon could alter an already-existing scanner or make a new scanner capable of interrogating Bottlerocket. In fact, all the pieces necessary to do so seem to already exist.

This request may be better served as an appeal to the Inspector team (or your scanner of choice) than the Bottlerocket team. Of course, that's not to say that there is zero overlap or help that the Bottlerocket crew can provide with getting the sentiment of this request addressed.

Unless the Inspector agent is incapable of running (or being tweaked to run) on Bottlerocket, it's not hard for me to imagine a future where Inspector would be able to report the current ~ALAS~ GHSA advisories that apply to a given host running Bottlerocket. CIS scanning is a completely different problem.

[kdaula]

Bottlerocket is now supported by AWS inspector in commercial regions.

[mattlorimor]

YES!

I commented what I did almost two years ago. I think I might cry.

[fishtaco84]

Bottlerocket is now supported by AWS inspector in commercial regions.

Can we get this GovCloud regions?

[yeazelm]

@fishtaco84 This support is in all regions Inspector is supported. So this should work in GovCloud regions today! I just verified my instances work just fine so you should be able to use it there!