Starboard is joining the Trivy family

[itaysk]

As Trivy is growing from strength to strength we have realized that there is a strong interest from the community to implement Trivy into your Kubernetes cluster natively. At the same time Trivy continues to expand with more scan targets and findings, and it has rapidly grown to overlap with Starboard. The next phase in Starboard's life is to join Trivy.

starboard-operator is becoming trivy-operator, which will be focused on exposing Trivy's capabilities in a Kubernetes-native way.
starboard (cli) will be replaced with a new trivy k8s command, which will follow Trivy's lightweight, client-side model for scanning, bringing it in line with the familiar Trivy experience.

It is important to highlight that this change is not happening overnight. Released artifacts will remain available and existing users will not be affected. We are here to answer your questions and highly appreciate your input. Please share your ideas in the discussion forum on GitHub or on Slack.

This is our commitment to take open source Kubernetes Security to the next level through Trivy. We have an exciting roadmap for Trivy-Kubernetes security which we will soon make publicly available on GitHub. Some of the upcoming features: UI experience, RBAC assessment, sensitive information scanning, native prometheus exporter, admission controller, and much much more...

---

Update 14 May 2022: #1173 (comment)

Thanks for the feedback everyone! Allow me to update and clarify a few things:

1. In the first stage, we will leave Starboard repository untouched. To that end, we will work on the new Trivy stuff in new repositories (trivy-operator, trivy-kubernetes).
2. trivy-operator will focus only on exposing trivy capabilities in kubernetes, and therefore will not include kube-bench (which is not in Trivy). This should not be an issue to existing users since Starboard remains available. (Same applies to kube-hunter)
3. Ideally kube-bench would have been superseded by the new trivy k8s scanner, but some feature are still missing. We will work separately on providing full Kubernetes CIS Benchmark coverage with trivy k8s - Then it will be naturally supported by trivy-operator.
4. Although we are leaving Starboard's repo untouched for now, the plan is to replace it with Trivy. We will refrain from adding features or releases of Starboard. New users who are interested in Vulnerability scanning and configuration audits in Kubernetes will be encouraged to start with Trivy.

[NissesSenap]

Really interesting.

What is the plan for starboard features that isn't related to image scanning? For example yaml parsing and kubehunter? I personally think that the image scanning feature is the most important but I thing in starboard but I could see how other people of the community would want this.

I guess at some time there will be a feature freeze of starboard and fully focus on trivy-operator. When will that happen?
Do you plan to have some online community meeting to share more of your plans of the future?

[itaysk]

If you consider the starboard-operator, then in the short term it's just a rebranding to trivy-operator (same capabilities). In the long term, yes we will want trivy-operator to focus on Trivy capabilities. BUT something important to understand is that Trivy is no longer just a vulnerability scanner. when you said "yaml parsing" I suppose you meant Starboard ConfigAudit report (IaC Misconfigurations)? If so, then Trivy has this capability, and therefore it's in-scope for trivy-operator. More scanning types will be added to Trivy (such as secret scanning, Lincese detection etc), and these will be surfaced through the trivy-operator as well.

As for kube-hunter, it was never available through the starboard-operator (only through starboard cli).

[sanferjesus]

Hi @itaysk, what about the kube-bench? it was integrated with starboard-operator...

[itaysk]

I've shared more details in a reply to this thread. TL;DR over time kube-bench like capabilities will make their way over to trivy k8s scanner, and then trivy-operator will naturally provide CIS Kubernetes Benchmark coverage. We don't have a timeline to share at this point

[skuethe]

I have mixed feelings about this tbh.
Did you consider just creating a new trivy-operator instead of reworking starboard?
Or adapt starboard to support all the functionality from Trivy (which then needs to be done anyway, right?).

At the same time Trivy continues to expand ... and it has rapidly grown to overlap with Starboard

But is that true? Starboards functionality is very specific and it totally depends on the plugins input data (f.e. from Trivy)?

It seems to me that the basic idea behind starboard is being totally rewritten with this approach (Trivy "vendor lock-in" if you want to go so far).
Yes, Trivy functionality is increasing, but it is probably safe to assume that it will never merge with things like kube-bench and kube-hunter?

[itaysk]

Thanks for the feedback. I've shared updates as reply to this post, but to answer you directly: In the first stage, we will leave Starboard repository untouched. To that end, we will work on the new Trivy stuff in new repositories (trivy-operator, trivy-kubernetes).

[itaysk]

Regarding the plugability story - yes you got it right. We realized that most of the users don't really care about manually swapping internal scanners or configuring them (they just use the default), and at the same time, Trivy was going to cover all of those scanning needs anyway. Maintaining this design complexity in Starboard doesn't make much sense now if the underlying tools are mostly Trivy. If you are interested in a generic tool operator like Starboard was becoming, you can still use it, or fork it for longevity.

[skuethe]

Thank you for the update! Sounds like a better solution than just working on this repo 👍🏽

[NissesSenap]

Agree with @skuethe .
Creating a new repo with a new operator in it would also give you the opportunity to create a bunch of breaking changes.
It would also make it possible for the community to have a easier migration path. When we want to use all the fancy new features we can change our config in a needed way and run it. We could even run both operators at the same time assuming you name the crd:s to something else. To make sure that we are happy with the result.

Breaking changes that would be nice:

• change vulnerabilityreports.aquasecurity.github.io.report to vulnerabilityreports.aquasecurity.github.io.spec
• Have vulnerabilityreports ttl on by default
  • think of it from the start to not have a seperate controller
• probably a bunch of other things that the maintainers can come up with

[AnaisUrlichs]

Thank you for sharing the input & those suggestions -- we will definitely take note of them and could incorporate them in the trivy-operator i.e. this is probably a great opportunity to share more ideas with us on changes that could benefit the community.

I cannot think of a reason that you would want to run both the trivy-operator and starboard at the same time. The trivy operator will first be starboard renamed in its simplest form.

[NissesSenap]

@AnaisUrlichs my point is that it shouldn't be a rename.
If i were you I would create a completely new operator in a new repo or a branch in this one.
Make all the breaking changes that you want.

As a part of migration to the new trivy-operator we could then use both the starboard-operator and the trivy-operator to verify that we have the same functionality and adjust all the config that we need to fix after the breaking changes.

Then we you as a administrator would be happy with the outcome you could delete the starboard-operator.

[itaysk]

Thanks for the feedback. I've shared updates as reply to this post, but to answer you directly: In the first stage, we will leave Starboard repository untouched. To that end, we will work on the new Trivy stuff in new repositories (trivy-operator, trivy-kubernetes).

[itaysk]

Love your ideas for improvements, happy to look at them for Trivy Operator

[erhan-]

Not to be confused with https://github.com/devopstales/trivy-operator.

[AnaisUrlichs]

Yes, there are actually many similar trivy operators and exporters written by different community members and other entities -- this is one of our data points, which contributed to the decision

[erhan-]

Yes, I understand that this allows control of the situation and how it develops in the future without standing in conflict with the interests of the company. That's why the kubehunter and bench questions above are interesting. Good luck and thank you for the tools.

[AnaisUrlichs]

Yes, the goal is to align the tools further with the needs and interests of the community -- a lot of it will definitely change over time and that's why we would love to hear your feedback and ideas

[itaysk]

Thanks for the feedback everyone! Allow me to update and clarify a few things:

1. In the first stage, we will leave Starboard repository untouched. To that end, we will work on the new Trivy stuff in new repositories (trivy-operator, trivy-kubernetes).
2. trivy-operator will focus only on exposing trivy capabilities in kubernetes, and therefore will not include kube-bench (which is not in Trivy). This should not be an issue to existing users since Starboard remains available. (Same applies to kube-hunter)
3. Ideally kube-bench would have been superseded by the new trivy k8s scanner, but some feature are still missing. We will work separately on providing full Kubernetes CIS Benchmark coverage with trivy k8s - Then it will be naturally supported by trivy-operator.
4. Although we are leaving Starboard's repo untouched for now, the plan is to replace it with Trivy. We will refrain from adding features or releases of Starboard. New users who are interested in Vulnerability scanning and configuration audits in Kubernetes will be encouraged to start with Trivy.

[NissesSenap]

Sounds good.
I'm already looking forward to the streamlining of the new trivy-operator.

It would be good if you create a issue that you pin in this repo pointing out that you don't take any new features and you will only fix new CVE related bugs in a forces able future (or something like that).

I guess also update the readme with similar info.

Might be the wrong place to ask for it but it would be really nice if you could publish a broad stroke roadmap for the trivy-operator in it's new repo.

[dirsigler]

I assume the trivy.serverURL will also be integrated into the Trivy-Operator, right?

Currently I run one dedicated Trivy-Server in a parent-cluster and all Starboard-Operator in my child-cluster connect to this Trivy-Server to reuse the downloaded vulnerabilities DB.

Else I am a fan of this change. ❤️

[itaysk]

Thanks for the suggestion! would you mind opening an issue under trivy-operator? https://github.com/aquasecurity/trivy-operator/issues

[chen-keinan]

@dirsigler yes, it is integrated into trivy-operator, same params

[nilesh-akhade]

Can someone please summarize the change in extremely easy words? Or confirm if I understood it correctly?

Previously

starboard cli = vulnerability scanner(trivy) + config scanner(polaris/aqua) + CIS benchmark scanner(kubebench) + kubehunter

Now/Future

trivy k8s cli = vulnerability scanner(trivy) + config scanner(inbuilt into trivy)
No inbuilt support for kubebench and kubehunter. Do it separately using starboard.

[AnaisUrlichs]

Hi, great question, I see that you are comparing the CLI.
Something to bear in mind is that the Starboard CLI was/is quite intrusive. Like several other security scanners in the space, it needs to install Kubernetes resources inside of your cluster to perform scans. This is highly suboptimal since it is not the expected behaviour using CLI tools and users might not even be aware of that behaviour.

Currently, we have disabled additional security standard scans such as CIS reports in Trivy Kubernetes, both the CLI and the operator. Note

Starboard CLI -- did not have NSA scans
Starboard Operator -- Did not have kube-hunter scans

The goal, by moving the functionality over to Trivy, is that we are providing cluster- but also security standard scans natively through Trivy in an optimised format both through the CLI and the operator.

Please let us know if there is something else we can help clarify; maybe one of the maintainers wants to add something as well