Static analysis of user workloads, such as Kubernetes resources and Dockerfiles, is a key aspect of DevSecOps. By analyzing these resources before they are deployed, organizations can identify potential security vulnerabilities and issues that could compromise the integrity of their systems.
One way to perform static analysis is through the use of static analysis tools. These tools can analyze Kubernetes resource configuration files (such as YAML files) and Dockerfiles to identify potential problems, such as the use of deprecated APIs or the inclusion of sensitive information in image layers.
Incorporating static analysis into the development process can help organizations catch potential issues early on, allowing them to be addressed before they become a problem in production. This can help to reduce the risk of security breaches and downtime, improving the overall security and stability of the system.
Here is an example of a YAML file that could be analyzed as part of a static analysis process:
apiVersion: v1
kind: Pod
metadata:
name: test-pod
namespace: development
spec:
containers:
- name: my-container
image: ubuntu:latest # best practices are to have a defined image with version never use latest
ports:
- containerPort: 80
protocol: TCP
By analyzing this YAML file, a static analysis tool could identify issues such as the use of an outdated image version or the exposure of a potentially vulnerable port. By addressing these issues early in the development process, organizations can improve the security of their systems and reduce the risk of potential issues arising in production.
There are several open source tools that can be used for static analysis of Kubernetes resources. Some popular options include:
kube-score: Kube-score is a static analysis tool that analyzes Kubernetes resource configuration files (such as YAML files) to identify potential issues and provide recommendations for improvement. It can be used to check for issues such as the use of deprecated APIs, resource overprovisioning, and the inclusion of sensitive information in image layers. Kube-score is available on GitHub at https://github.com/zegl/kube-score.kube-bench: Kube-bench is a tool for checking the hardening level of Kubernetes clusters against the CIS Kubernetes Benchmark. It can be used to identify potential issues with the configuration of a cluster, such as the use of insecure protocols or the lack of network segmentation. Kube-bench is available on GitHub at https://github.com/aquasecurity/kube-bench.kube-audit: Kube-audit is a tool for auditing the configuration of Kubernetes clusters and nodes. It can be used to identify issues such as the use of outdated software, insecure configurations, and the inclusion of sensitive information in image layers. Kube-audit is available on GitHub at https://github.com/Shopify/kube-audit.
Here is an example of the output that you might see when using kube-score to perform static analysis of a Kubernetes resource configuration file:
Similar to how we use Cloud Security Posture Management in Azure for recommendations populated by Defender for Cloud to harden our workloads the aim of static analysis is to have the heavy lifting done prior to pushing code to production. While most tools are open-source its also important to identify how your organization can integrate these tools into your DevOps toolset for enablement along with the support of the tool. CNCF has established the project phases to help in that direction of governance as the phases of projects accepted go from Sandbox, Incubated to Graduated. Perhaps when measuring your risk your CISO and CIO don’t want to utilize tools that are in the early stages of Sandbox.
In that case, focus on the tools that are graduated for use cases such as kubernetes and argo. It does appear CSP will start offering more integration and acceptance of these tools in offerings as support for these features are desired and known industry wide such as the popularity gained from Prometheus and others.