There are lots of security tools in the cloud native world, created by Aqua and by others, for identifying and informing users about security issues in Kubernetes environments. However powerful and useful they might be, they tend to sit alongside Kubernetes, with each new product requiring users to learn a separate set of commands and tools in order to operate them and find security information. Here in the Aqua Security open source team, we’ve been thinking about what a Kubernetes-native, integrated security experience might involve, and today, we’re excited to release Starboard, an Apache 2.0 licensed toolkit for finding risks in your Kubernetes workloads and environments.
Starboard integrates existing Kubernetes tools, not just from Aqua but also from third-party projects, into the Kubernetes experience. This video shows how Starboard enables results from vulnerability scanners, workload auditors, and configuration benchmark tests to be incorporated into Kubernetes CRDs (Custom Resource Definitions) and from there, accessed through the Kubernetes API. Users familiar with kubectl or with a dashboard tool like Octant can find security risk information at their fingertips.
“The Starboard project leads the way in Kubernetes-native security reporting.” said Bryan Liles, Senior Staff Engineer at VMware. “Using this approach, Octant users can view the details of security risks exactly where they belong, alongside the Kubernetes resources to which they apply.”
In this first release of Starboard we’re providing a kubectl plugin, a set of custom security resources definitions, a Go module, and an Octant plugin to enable a range of use cases. By following our Getting Started guide you can access the following types of security information through the Kubernetes API:
- Vulnerability information in your running workloads, scanned using Trivy
- Workload audits provided by Fairwinds Polaris
- CIS benchmark results per node provided by kube-bench
- Pen-testing results provided by kube-hunter
“Running and managing multiple Kubernetes security tools is a major challenge,” said Robert Brennan, Director of Open Source at Fairwinds. “We’re excited to see Fairwinds Polaris helping security and DevOps teams validate their configurations as part of the Starboard project.”
For Aqua’s customers, we also provide a proof-of-concept implementation of a webhook integrating Aqua vulnerability scan results into Starboard.
Puja Abbassi, Developer Advocate and Product Owner at Giant Swarm, supports this approach:
“We strongly believe that Kubernetes-native interfaces are the future of our community. I’m really excited about Starboard, as it creates exactly that for the security side of Kubernetes and removes the need to learn and integrate with proprietary systems.”
This first release is illustrative of the range of results that can be incorporated into the Starboard approach. Before discussing the roadmap, let’s consider the motivations behind this project.
Motivation: The Kubernetes Security Tool Landscape
Looking at existing Kubernetes security tools you can quickly realize two things. On one hand they differ in many ways, i.e. have different capabilities, data models, output sinks, license, maturity level, and credibility. On the other hand, they usually have the same or very similar modus operandi:
- Discover Kubernetes objects via the Kubernetes API or by parsing descriptor YAML files
- Invoke some kind of risk evaluation against those objects (for example, run a Trivy binary executable to find container image vulnerabilities, invoke a Go function to check the SecurityContext of a given Pod, or use some Rego rules to evaluate a Pod spec)
- Output a risk assessment report, typically to stdout or to a file, often in JSON or YAML with a free-style schema.
It’s not easy to deal with the results from these different, standalone Kubernetes security tools. With all these heterogeneous data models it’s very hard to take advantage of all the features provided by a given tool, let alone combine the results from several different tools.
What if all the Kubernetes security tools spoke the same language that everyone knows and understands? Similar to the standardized and well-known Pod spec, we could come up with the schema for a vulnerability, a risk assessment check, an allowed or denied vulnerability, or maybe even a scanner config. What if you could combine the results from different tools to give an easy-to-understand overview of current security status? This would allow security vendors to focus on what they do best, while others could consume the data in the homogeneous format.
Starboard illustrates how the outputs from different security tools can be stored and combined using native Kubernetes approaches:
- Storing results in Kubernetes CRDs that can be queried using the Kubernetes API
- Using Kubernetes Operators to efficiently manage security assessments of different resources within the cluster
- Leveraging Kubernetes role-based access control (RBAC) to make it easier to control who has access to different security reports
- Using Kubernetes Operators to aggregate results, using flexible policies, into Kubernetes-native CRDs
Let’s explore some specific scenarios where Starboard can help.
Starboard Use Cases
Security Tool Kit for Development Teams
One idea behind Starboard is to help development teams deliver secure and compliant applications from the get-go. As shown in the figure below, Dave Loper is using kubectl to deploy and test his applications. He can now use a familiar kubectl starboard plugin interface to scan his application’s container images, to find potentially dangerous and exploitable vulnerabilities. He can also look for configuration issues that might affect stability, reliability, and scalability of his deployment. This effectively implements the “shift left” security principle, giving Dave Loper information he can use to improve the security of his application.
Dave also uses Octant, a Kubernetes introspection, and object management platform. With Starboard Octant plugin we’re extending Octant to present vulnerability and configuration audits in a user-friendly manner. A similar approach could be used to build custom dashboards or extend pluggable third-party UIs like the OpenShift Web Console.
Using CRDs allows administrators to take advantage of Kubernetes RBAC, limiting Dave’s access so that he can only query the security reports for the projects he is involved in.
Security Tool Kit for Enterprise DevOps
Manual scanning through the command line is useful, but it has its limitations: it doesn’t scale well with a huge number of Kubernetes workloads and / or multi-tenant clusters as is the case for enterprises.
We’re working on a Starboard Security Operator that provides a better option for these scenarios, constantly monitoring Kubernetes-native resources, such as Deployments, and running appropriate scanners against the underlying deployment descriptors. The scan reports can be saved as custom resources in the same instance of etcd used by the Kubernetes cluster running the workloads, or an etcd instance external to the cluster.
Because they are accessible over the Kubernetes API, the vulnerability reports or any other security audits can be used to build or integrate with dashboards tailored for SRE and Security teams.
The same data can be used by a future Starboard Admission Webhook to accept or reject new deployments based on security policies put in place, e.g. number of critical vulnerabilities found in a container image. This policy enforcement could be based on the results from a range of third-party security tools integrated with Starboard.
Tool Kit for Security Product Development
Starboard provides a Go module to help integrate additional security tools into the framework.
Many tools may be able to reuse one of the existing CRDs for the tool’s results. For example, all image scanners report similar information about package vulnerabilities – they may have differing degrees of accuracy, but the content of the results looks very similar whichever scanner you use. Our vision is that CRDs should be reused where possible to aid re-use and pluggability.
We’ll soon be publishing a detailed spec for the custom resource definitions so that third parties can add Starboard-compliant CRDs for cases where the existing set doesn’t already meet their needs, and we’re interested to hear feedback from users on.
Roadmap
Today’s release gives a flavor of Starboard’s potential, but we have lots of ideas for extending and improving this in the future – and we’d very much welcome your feedback.
Our plans include creating a flexible, pluggable Starboard Security Operator that enables a “roll-up” of security risk information in each namespace and across the cluster so that users can easily identify the highest risks. As described in the Enterprise DevOps scenario, we are also planning a Starboard Admission Webhook that can take policy decisions based on the security information from any Starboard-compatible CRD.
But most importantly, our plans will evolve based on feedback from users. So please give Starboard a spin, and let us know what you think!
