Back in June 2020, we released Starboard – an open source toolkit that integrates security tools into a Kubernetes environment. We’re now happy to announce a new Starboard Operator that automates the generation of security reports in your K8s cluster. Using Starboard Operator, you can rely on the tools you’re already familiar with, like kubectl, to easily access security information about your running workloads.
The initial release of Starboard provided custom security resources definitions and the command-line interface to integrate with various scanners from Aqua and third-party providers. By following the “getting started” guide for Starboard CLI, you can, for example, trigger a vulnerability scanner on a specified Kubernetes workload and retrieve the vulnerability report through the Kubernetes API.
Realtime decision making for Kubernetes security
Manual scanning is useful, but it quickly becomes a chore with even a moderate number of workloads. What’s more, it requires a certain operational knowledge of scheduling scanners when a new pod is started, or when the pod’s template is changed. Beyond that, Kubernetes pod controllers form a hierarchy of Kubernetes objects and it’s not always clear-cut at which level of such hierarchy a scan result should be stored. For example, it might not be obvious whether a vulnerability report should be owned by a Deployment or the active ReplicaSet created by the Deployment Controller.
Conceptually, Kubernetes Operators take human operational knowledge and encode it into software that is more easily shared with consumers. In the case of Starboard, the new operator automates the process of running security scanners in response to a change in the workloads running in your cluster.
The Starboard Operator watches over Kubernetes workloads and makes decisions in realtime about whether to run new security scan jobs. We’ve shared a link (below) to a video that shows how the operator automatically schedules a vulnerability scan when a new Deployment is created. It also acts on rolling update events when the Deployment’s container image is updated. Since the operator is built on custom security resources, it’s purpose-built to work with the Starboard CLI and the Octant plugin.
How Operator Works
The Starboard Operator automatically updates security reports in response to changes in a Kubernetes cluster – for example, initiating a vulnerability scan when a new pod is started. Starting now, the operator supports vulnerabilityreports security custom resources, but future versions will support all custom security resources.
There are two reconciliation loops in the operator. The PodController watches for pod events in target namespaces to lookup the immediate owner of a pod. Then it checks whether there’s already a vulnerability report for this owner. If none is found, it schedules a scan job using Trivy in the operator’s namespace. For Aqua customers, we also provide integration with the Aqua commercial scanner. The JobController watches for job events in the operator’s namespace. If a given job is completed, it parses the logs of the controlee pod and converts the logs output to instances of vulnerabilityreports resources.
Roadmap
Although today’s release of Operator provides a useful resource right out of the box, our roadmap already includes expanded capabilities in coming releases.
Future planned additions:
- Reconcile other types of reports
- Implement leader election and scan jobs throttling to scale with a huge number of Kubernetes workloads
Most importantly, our plans allow us to remain flexible based on feedback from users. So please give Starboard Operator a spin and let us know what you think.
Starboard Operator is available from OperatorHub.io, or Helm chart.
Interested to learn more about the design decisions we made while developing the Starboard Operator? Join this KubeCon Virtual talk: Kubernetes-native Security with Starboard,with Liz Rice & Daniel Pacak, Aqua Security
