Adding Policy as Code to GitOps Pipelines
Previously we introduced the benefits of policy as code, and how it works. In this blog, we continue where we left off and dive deeper into how policy as code can be embedded into GitOps pipelines.
Overview
Earlier this year, Weaveworks and Magalix, joined forces. Magalix is in the business of policy as code, including policy creation, management, and enforcement. Since then, we have announced the General Availability of Weave GitOps 2022.03 to automate trusted application delivery and secure infrastructure operations on-premise, in the cloud and at the edge. The latest release embeds policy as code capabilities within Weave GitOps.
In an earlier blog, we introduced the benefits of policy as code, and how it works. In this blog, we continue where we left off and dive deeper into how policy as code can be embedded into GitOps pipelines.
GitOps and Security
GitOps, by its nature, provides an auditable, secure, and regulatory compliant method to manage deployments. In the GitOps framework, Git is at the heart of software delivery pipelines. Every piece of software pushed to the Git repository triggers a series of automated events, leading to tested, vetted and approved code being deployed into production. Git provides an immutable audit trail, giving visibility on who did what and when to your cluster to ensure compliance and stability. Because all actions are performed through Git, the number of users that require direct access to your Kubernetes clusters is greatly reduced. This significantly reduces the potential attack surface for your environments.
Created for a cloud-native world, GitOps makes developers more productive while improving application stability, security, and compliance – and it does all this without the need for developers to learn new tools.
Policy-Based Governance with the Self-Service Platform Model
According to the State of DevOps Report 2021, about 65% of highly-evolved DevOps (high mid-level evolution) use self-service platforms compared to 40% of the lower (low-mid) teams. The GitOps model is the best approach for successfully deploying and maintaining a Kubernetes platform that benefits both developer and ops teams.
Improving security and compliance are some of the many benefits of the self-service model. The platform team can enforce policies on resources and actions across the pipeline. For example, there can be a list of approved container images or a container registry, and certain security checks could be required on every commit before they can be deployed into production.
These capabilities provide security guardrails and compliance in a way that is not possible manually. So how can platform teams provide these guardrails? Through policy-based governance, embedding security, compliance, and operational policies into GitOps pipelines using policy as code. This is what we call Trusted Delivery.
Policy as Code in GitOps Pipelines
In the GitOps pipeline, security and compliance guardrails are applied at:
- Git Repo - GitHub Action
- CI System - CircleCI Docker executor
- Kubernetes - Admission controller
- Runtime - Policy agent
Figure: Trusted Delivery: Policy-based Governance across GitOps Pipelines
Git Repository: Infrastructure as Code Scanning
This is where the developer receives commit-time feedback. With the codified policies enforced with the policy engine agent, we scan the infrastructure as code (IaC) templates before they get committed to the repository and auto-remediate, where possible, any violations.
Terraform is a popular open-source declarative IaC framework used to define resources in public cloud resources and the registry is made up of over 3k modules. To give you a sense of why it’s important to scan IaC templates for vulnerabilities, nearly 50% of the modules within the Terraform Registry are misconfigured. Validating these templates before committing them to the Git repository, keeps those misconfiguration vulnerabilities out of your environments.
CI System: Misconfiguration Guardrails
At this stage, the developer will receive build-time feedback. The build will fail if any policy violations are detected. This may appear to be an unnecessary extra set of checks, however build steps may modify or generate extra manifests, which will be checked for violations.
Kubernetes Clusters: Deploy-Time Feedback
The policy agent admission controller will prevent any deployment, manual or automatic, from being introduced to a Kubernetes cluster if the deployment artifact violates any policies. The developer will receive immediate deploy-time feedback explaining why the deployment was blocked.
Potential security risks that can arise when you deploy an application into production include over-privileged containers, insecure RBAC policies, or insecure networking configurations
Config Repo: Run-Time Security and Compliance Audit
GitOps already protects against any unauthorized modifications. The continuous reconciliation of the desired state, stored in Git, with the actual state, running in Kubernetes will automatically revert any manual changes, accidental or malicious.
What about your existing Kubernetes clusters and applications that are not yet under the protective shield of Trusted Delivery with GitOps? The policy agent provides continuous run-time detection and reporting of policy violations which can be used as part of a compliance audit.
Trusted Delivery with Weave GitOps
Trusted Delivery - available now with Weave GitOps - is a solution that provides you with commit time, build time, deploy time, and run-time checks so that you can develop one policy, and apply it anywhere in your software development lifecycle.
Weave GitOps includes policy as code checks to ensure that misconfigurations are automatically detected, notified and the deployment halted. The policy engine is built on Open Policy Agent (OPA) and includes a curated library of over a hundred policies covering: security, resilience and coding standards.
Download a free version today or book a demo to see how Weave GitOps enables you to manage a fleet of clusters, securely and confidently.
