This post continues looking at some of the Kubernetes concepts I’ve been learning with the 50 days of Kubernetes (K8s). Specifically in this post, I’m writing and thinking about the flow of containers from code to a Kubernetes cluster.
The video talks about pipelines, which is the way in which you get code running in a Kubernetes cluster. The start looks at the idea that we don’t want arbitrary containers running in the cluster, so we limit access to the cluster to somewhere like a container registry, like Azure Container Registry. This ensures that only those containers loaded into your space get onto the cluster. No pulling from Docker Hub or some arbitrary location.
However, then we worry about developers loading containers into the registry that haven’t been checked. So, we don’t give them permission, we give it to some CI/CD pipeline, which means any code written by a developer that builds a container has to be checked in.
Now, we have a pipeline flow that we can control. As Brendon mentioned, this isn’t simple, and really, I think you have a lot of work here before you want to trust things running on a production Kubernetes cluster. Really now you need these in your CI pipeline:
- Unit tests
- Vulnerability scanning
- credential scanning ( I see this from MS for Github repos)
- every other type of scanning you can do
In this way, you ensure some quality level in your containers as far as security goes and code working. The big win here, at least for me, is that you can continue to raise the bar by adding more tests and scans, something that’s hard to do for developers without automation.
Not a lot new here, but certainly the idea of putting access and control into the CI/CD flow makes sense.