Understanding DevSecOps for Kubernetes

Table of contents

Reading Time: 4 minutes

Increase in Security Demands for Cloud Native Ecosystems

In today’s world, the need for securing our cloud native clusters has increased more than ever. Also this year, cloud-native security is again top trending, according to a report published by Gartner. DevSecOps is a simple answer to multiple questions.

In the recently concluded KubeCon 2020, we saw that a lot of organisations are taking huge strides and wanting more people in the DevSecOps sector. We also have a specific branch for Kubernetes which is appropriately name KubeSecOps.

Another factor in understanding how important security is to the different organisations now is that even after already high demand certifications like CKA and CKAD, the Cloud Native Computing Foundations has introduced a new course, Certified Kubernetes Security Specialist.

DevSecOps: Security at Container Level

In regard to container security, there are basically 6 factors that need to be considered:
1. Image Scanning
2. Container Compliance
3. Runtime Security
4. Network Security
5. Forensics
6. Kubernetes Audit

Concerns related to container security:

Container host security
Container network traffic
Application security inside the container
Malicious behaviour within the application
Securing your container management stack
The foundation layers of your application
The integrity of the build pipeline

The reasons for above concerns can be traced to the following possible reasons but not limited to these:

Kubelet API not secured
Unrestricted cloud metadata with sensitive information
Unprotected secrets
Lacking adequate network policies
No ingress authentication for services
No authentication on etcd
Privileged containers
More than required service account privileges

The main thing that DevSecOps concerns itself with is finding vulnerabilities at the time of cluster creation. We can always list out some of the questions to be asked for securing our Kubernetes cluster:

Has authentication been enabled?
Are we familiar with the base image while building our custom images and are those official images?
Is root access required for our application while running the container?
Are the containers in the proper namespaces while deployment?
Is there a need for Transport Layer Security
Has cluster hardening been done?
Are pod security policies implemented?
What ports are exposed for a pod?
Is there audit logging?
Are we using sidecars while injecting secrets?
Are we implementing security policies while storing secrets?

Below are the charts sourced from various forums giving recommendation for different tools that can be used for ensuring security while creating a cluster and deploying our applications.

devsecops-tools3 — Language Recommendations

DevSecOps: Designing a Security Pipeline

We have now made our-self familiar with most of the demands and factors needed for ensuring security on the grounds of KubeSecOps and ultimately DevSecOps. Now, the next question that arises is how do we ingest security in a Kubernetes pipeline while making it accessible for the required components?

kubesecops-pipeline — KubeSecOps Pipeline

Lets take a look at various type of tools we can use for creating the Pipelines:

Development

IDE: Any well maintained IDE will work fine.
Open Policy Agent: Defines policy in linting the code and integrates with the IDE itself.
Vault: For secret management
Image Registry: If possible, image registry should be private. Recommendations are JFrog and Harbor
Image Scanner: Tool to find vulnerabilities in an image. The most popular is Trivy.
Update Framework: Image signing and secure upgrades is done via tools like TUF.

Staging

The above tools are most useful for the development process. Now lets have a look at the factors and see we can use during the staging process:

Bench-marking: It is required for getting recommendations and warnings to correct possible vulnerabilities. Kube-bench is a highly rated tool for the same.
Penetration: We can use Kube-Hunter as a penetration tool. For instance, it will look for network, interface security breach/weakness remotely.
Audit: Scan manifests and cluster to perform audit because of various vulnerabilities might get exposed there.
Network Policies: There should be regular scan for network policies. Illuminatio is a tool which will do so along with building test cases and execute them to determine if the policies are in effect.

Once we have considered all these factors and setup our cluster accordingly, our application is ready to go to production. As a result, we will be needing runtime security analysis based on kernel scanning of vulnerabilities and notify for any live attacks. Falco is a tool that can be used for the same and it is also capable of sending security metrics to Prometheus. Thus, we can the integrate Prometheus and Grafana for better visualisation for the whole team.

Conclusion

We have seen and understood how important DevSecOps is in 2020. It is required on our whole pipeline and overlooking it is inviting danger because of various attacks. We looked at the questions that are answered while setting a cluster and how can we design our DevSecOps pipeline. Hopefully we will be getting more advanced tools that will be performing multiple tasks at once in the coming future!