Kubernetes Risk Assessment with Octarine’s Kube-Scan
After I saw the news about VMware’s intent to acquire Octarine, I wanted to know what Octarine is all about and what solutions they have. Octarine offers intrinsic security and compliance for Containers and Kubernetes workloads from build (Octarine Guardrail) to run (Octarine Runtime). This allows organizations to adopt DevSecOps principals for the complete application life cycle.
DevSecOps
Just in case you haven’t heard the term DevSecOps before. Here is my short take on it. DevOps is a methodology or a set of practices to bring Software Development and IT Operations together, with the overall goal to accelerate business by faster (increase velocity) and better (improved quality & reliability) application development. DevSecOps incorporates Security into DevOps practices and essentially makes everyone responsible for security-relevant decisions along the complete application lifecycle. This ensures security is built into the application rather than added subsequently.
Kube-Scan
Besides their enterprise security platform offering, Octarine is maintaining a very interesting open-source project called Kube-Scan to assess the risk of your Kubernetes workloads. In this blog post, I want to give a short overview of Kube-Scan.
Installing Kube-Scan is pretty straightforward. Kube-Scan is running as a single Pod in your Kubernetes cluster. You can install it with direct access to the pod and port-forwarding or behind a load balancer. For more details, have a look at Kube-Scan on GitHub. In my case, I used the load balancer option. Simply execute the following command on your Kubernetes cluster.
(⎈ |tkgcl1-admin@tkgcl1:default)➜ ~ kubectl apply -f https://raw.githubusercontent.com/octarinesec/kube-scan/master/kube-scan-lb.yaml namespace/kube-scan created configmap/kube-scan created serviceaccount/kube-scan created clusterrole.rbac.authorization.k8s.io/kube-scan created clusterrolebinding.rbac.authorization.k8s.io/kube-scan created deployment.apps/kube-scan created service/kube-scan-ui created (⎈ |tkgcl1-admin@tkgcl1:default)➜ ~ kubectl get pods -n kube-scan NAME READY STATUS RESTARTS AGE kube-scan-78f85b5d94-w4mt9 2/2 Running 0 35s (⎈ |tkgcl1-admin@tkgcl1:default)➜ ~ kubectl get svc -n kube-scan NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-scan-ui LoadBalancer 100.68.63.11 172.16.10.10 80:31935/TCP 45s
That’s it, Kube-Scan is running, and we can access the Dashboard to look at our Risk Assessment. As a side note, if you want to do another scan of your cluster, simply kill the Kube-Scan pod, and it will do another scan when it comes back up. Otherwise, it will wait for 24 hours until it will do another scan.
As you can see, I have a Deployment called yelb-ui that has a risk score of 7. By the way, the scoring is done via KCCSS (Kubernetes Common Configuration Scoring System). KCCSS is an open-source framework from Octarian that rates your workloads from 0=no risk to 10=high risk.
Let’s look at the risk rating for my yelb-ui deployment in more detail. Multiple medium risks have been detected.
We can drill down to the individual risks to get more details. This particular risk states that the workload may have containers running as root as we don’t have a non-root user id specified nor the runAsNonRoot setting defined for the Pods security context. Additionally, we see information about the potential impact. E.g., this risk has a high Confidentiality Impact but a low Availability Impact. It also gives an indication of Exploitability=Low, Attack Vector=Local, and Scope=Host.
Another good example is the risk of having no CPU and Memory limits configured. This obviously has a high impact on Availability as it could starve other Pods running on the same node. This risk has no impact on Integrity or Confidentiality.
This risk can be easily fixed by adding resource limits to the application manifest.
Conclusion
Kube-Scan can be easily used to quickly assess the risk of Kubernetes workloads running in your cluster. It gives a good first idea of the risk that you are exposed to. No data is collected or is leaving the cluster. Nevertheless, this is just a first step into the security-related challenges that need to be addressed when running Kubernetes workloads in production and adopting DevSecOps practices. I cant wait to see how Octarine’s solutions will be integrated into the VMware Security and Tanzu portfolio. Have a look at this blog post to see how Octarine can be used in combination with Tanzu Service Mesh.
Sources
Categories
Beyond Elastic 