You might be excited about GitOps, but if you’re an enterprise in regulated industries, you’ll have specific Security, Compliance, and Governance constraints. This blog looks back at this topic covered during the inaugural GitOps Days 2020 events.
Kenichi Shibata, Cloud Solution Architect, delivered a talk on Security, Compliance and Governance for Your Enterprise Use-Case, which focused on how cluster governance is a particular challenge when adopting Kubernetes in the enterprise, and how GitOps is the key to building robust governance policies for your clusters.
Kenichi describes a possible use case for a company that is running Kubernetes in production and wants to bring their cluster baseline pod security standard within compliance. Challenges from stakeholders could include CIS compliance, conformance to a governance model, and auditing and attribution for every change.
For a good mental model to tackle these challenges, Kenichi suggests a divide-and-conquer approach.
You can audit the Build Layer using GitOps because GitOps helps you have declarative cluster creation. By using a cluster reconciler (like Flux) you can take cluster definitions (yaml) and apply them to a Kubernetes cluster. The Kuberetes cluster can then use a declarative fleet manager (cluster api, Weave Kubernetes Platform, etc) to create clusters.
This gives you a very clear audit trail of what changed, who changed it, why it was changed, and how it was changed in order to meet your compliance requirements.
In order to address compliance requirements, Kenichi’s suggests:
- Understanding the compliance in your context is key (NIST, CIS, PCI, GDPR) and what compliance is required for you (is it all of NIST or a part of it)?
- Codifying the standard via Compliance as Code (via OPA or others)
- Approving blueprints: any deviation from the compliance needs to be picked up and approved
- Reporting compliance - how do you know you applied that code?
- Review and maintenance
When you’re writing a set of policies to use as blueprints, you need to be able to measure them using a variety of measures:
- Open Policy Agent (OPA) using Modules
- PodSecurity Policies
- Network Policies
- Pull Request Review
- CI Required Checks
- Resource QUote, Limit Ranges
- Other Admission Controllers
Kenichi lays out what the above might look like in a GitHub Actions workflow with Open Policy Agent using Conftest and Gatekeeper. A main point here being that policies are first tested in Conftest, and then they are accepted and compiled to ONCE before Gatekeeper ensures compliance is always intact with alerts and notifications.
How you verify governance will depend on what your internal standards and policies are, what your architectural or engineering teams are saying, and what your board is saying. You should be thinking about the following:
- Reporting against internal standards and policies
- Incident management
- If everything is operated through Git you need to link Git and integrate GitOps into your internal processes
- Shifting security all the way left to the planning and design of your system, and building security in as a consideration every step along the way to production are critical.
- Ensuring an Enterprise Grade GitOps Fleet is based on the three foundational pillars of Audit, Compliance, and Governance.
- Before you even begin your journey, make governance and compliance a primary consideration.
- Blueprints and baselines can really help you achieve enterprise grade Kubernetes security in a shorter period of time.
For more talks, check out the GitOps + Compliance & Governance Playlist.
To learn more about how to move the needle with GitOps in your organization, contact us.