Starboard: Putting all the Kubernetes Security Pieces into One Place
Honeycomb is sponsoring The New Stack’s coverage of Kubecon+CloudNativeCon North America 2020.
Repeat after me: “Kubernetes is not secure by default.” Got that? Good, admitting that is the first step to Kubernetes security wisdom. But, Starboard, an open-source Kubernetes security CLI and operator from Aqua Security can help you understand what’s going on with security in your Kubernetes cluster.
In a KubeCon presentation, Liz Rice, Aqua Security’s vice president of open source engineering, and Daniel Pacak, an Aqua Security open source engineer, explained what’s up with Starboard.
Fundamentally, Starboard gathers security data from various Kubernetes security tools into Kubernetes Custom Resource Definitions (CRD). These extend the Kubernetes APIs so that users can manage and access security reports through the Kubernetes interfaces, like kubectl or the Octant Kubernetes web interface, that you already use every day. It also comes with a Go module to make it easier to work with existing security tools.
Besides coming as source code, you can run Starboard as a single binary. You can run it in two different modes:
- As a command-line tool (CLI), you can trigger scans and view the risks in a kubectl-compatible way or as part of your CI/CD pipeline.
- Or, as an operator to automatically update security report resources in response to workload and other changes on a Kubernetes cluster — for example, initiating a vulnerability scan when a new pod is started.
The easiest way to use Starboard is to simply run the Starboard CLI and let it scan your deployed Kubernetes workloads. Under the covers, by default Starboard uses Aqua Security’s Trivy vulnerability scanner to find problems in container images. When used as an operator it creates security reports stored in the cluster as custom resources for each of your workloads.
In either case, as Rice pointed out, Starboard doesn’t just work with Aqua’s tools. “It can enable results from vulnerability scanners, workload auditors, and configuration benchmark tests.” That said, Pacak admitted, “It’s not like a plug and play experience yet but in general, we believe that we can solve for other tools.
That’s no great surprise. Starboard is a young project. It first saw the light of day in June 2020. With so many Kubernetes security tools already out there, you might wonder why Aqua’s bothering.
The reason is Starboard’s competitors all use very similar methods:
- 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 freestyle schema.
What they don’t do, however, is produce results in a unified data format. If you use two or more tools, you’re stuck with trying to make sense of multiple formats. Starboard’s answers it to deal with these varied outputs 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
So, where do we go from here? Starboard’s team plans on working on fully pluggable security reporting.
But, beyond that, Rice said, we want your help in working out “what are the most important security issues in your cluster, or what are the most important security issues in the particular namespace you care about. We want to get to a point where we can summarize the most important issues from across these different types of security reports. Then, we can make it easier for engineers to find out what security issues he really needs to worry about.”
And, when you think about it, isn’t that a goal we can all agree on?
The Cloud Native Computing Foundation and KubeCon+CloudNativeCon are sponsors of The New Stack.
