Secure GitOps Pipelines for Kubernetes with Snyk and Weaveworks
Join Weaveworks and Snyk in an online webinar to learn why the typical CICD pipeline can be insecure and how by applying a GitOps in combination with Snyk’s automated vulnerability solution can protect you.
Feedback and Control - an Essential GitOps Component
How secure is your CICD pipeline?
GitOps - Operations by Pull Request
Join Weaveworks and Synk on March 12 for an online webinar on how to secure your GitOps pipeline. In past blogs and articles, we discussed how the typical CICD pipeline works and how by pushing code and deployments in one direction from code base to cluster can be insecure.
Questions to ask include:
- Does your CI environment have direct access to the container image repository?
- Does your CI environment have direct access to the production cluster?
Many organizations do implement this kind of pipeline. But let’s take a closer look, and assess the components that have access to each other.
The diagram below uses RW for Read Write access, and RO for Read Only access. As you can see, there are a lot of red lines on there.
This simple and very typical pipeline violates some of the Open Web Application Security Project (OWASP) security principles, including the Principle of Least Privilege and the Separation of duties. By removing direct developer access to the image repo and to the cluster, the attack surface is minimized, while privileged access is reduced and duties are separated.
What does GitOps add to my CICD Pipeline?
GitOps is an operating model for building Cloud Native applications that unifies deployment, monitoring and management. Automated delivery pipelines automatically roll out changes to your infrastructure when changes are made to Git. But the idea goes further - and it also uses tools to look at the actual production state, and then tells you when the source doesn’t match the real world.
CICD done the GitOps way addresses an insecure pipeline by running a reconciliation operator in the cluster itself. It operates on a configuration git repo, with its own credentials. The operator compares and reconciles the desired state as expressed in the manifest files, stored in the git repo, against the actual state of the cluster.
This means that there’s no credential leakage across the boundaries. Your CI system can operate in a different security ‘zone’ rather than on the target cluster. Also, each pipeline component will only need a single RW credential. Because the cluster credentials never leave the cluster itself, you can now “keep your secrets close” and not scattered across your pipeline in bespoke scripts or unprotected environment variables.
Does GitOps solve all of my security problems?
While GitOps does solve the majority of your security woes, it does shift the burden of security onto your source code repository like Git.
Tips to Better Secure Your Source Code Repository
Here are some tips from Snyk on how to better secure your code repository:
- Add security testing to your PRs
- Statically analyze your repo Snyk
- Never store credentials as code/config
- Tightly control access
- Add a security.md file to your repo
To read more tips on how to better secure your code repository for GitOps-style deployments, see “So, you think your CICD environment is secure?” over on the Synk blog.
Join Weaveworks and Snyk
Together with Snyk, the Weaveworks team will explain and demonstrate how GitOps continuous delivery pipelines combined with good security practices improves the overall security of your development workflow - from Git to production.