Member-only story
Journey Of A Microservice Application In The Kubernetes World
Security considerations : policies enforcement
TL;DR
In the previous article we enhanced the Deployment specifications of the webhooks app from the audit results we got from a couple of security tools. In this article we will discuss about policy enforcement tools whose purpose is to ensure misconfigured specifications cannot be created in the cluster.
Articles in this series
- Presentation of the webhooks.app
- Running the application on a local one-node Kubernetes using Helm
- Running the application on a Civo Kubernetes cluster
- Continuous Deployment using GitOps with Argo CD
- Observability using the Loki stack
- Defining the application using Acorn
- Security considerations : security related tools
- Security considerations : fixing misconfigurations
- Security considerations : policies enforcement (this article)
- Security considerations : vulnerability scanning (coming soon)
Policy enforcement tools
In the previous article we enhanced the Deployment specifications of the webhooks app’s microservices in order to make the whole app more secure (we will keep on enhancing those specifications in future posts). Below is the original Deployment of the api and the same Deployment with additional security related properties.
Even if we know how we must specify a Deployment so it is more secure, nothing prevents us from sending the original version (the one on the left above) and have it created in the cluster. This can be harmful for different reasons, for example:
- there is no resources.requests nor resources.limits thus making it possible for the api Pod to exhaust the resources need by other Pods (noisy neighbors)
- there is no securityContext preventing a corrupted image from…
