Policies are a critical foundation to successfully build and operate Kubernetes based applications. Rather than making assumptions on how workloads and applications components should work, we can define policies that will govern and enforce the way those workloads and applications components must work.
Kubernetes has multiple native policies that help platform and ops teams govern and control aspects such as: scheduling and placement of Pods, resource consumption and management, network access control policies, scaling (up/down & vertical) of pods, pod and container security, role based access control (RBAC) policies, cluster audit policy and more. Those Kubernetes native policies, with the right amount of effort, serve as the building blocks to comply with regulatory compliance policies such as PCI, HIPAA and alike, as well as internal organization policies.
Are the native Kubernetes policies sufficient to govern and enforce granular enough policies? The answer is NO, and there is a “but” part to that answer.
Finer grained policy enforcement can be achieved by leveraging the extensibility built into Kubernetes such as admission controllers. Security is one area where the existing Kubernetes native policies (RBAC and PodSecurityPolicy) were found to be incomplete and projects like Open Policy Agent (OPA) Gatekeeper leveraged Kubernetes modular design to fill in those gaps.
Let’s take a deeper look at that and see how and if OPA can do justice with your Kubernetes cluster operations, policy needs and requirements.
Open Policy Agent aka OPA
OPA is a domain agnostic, general-purpose, open-source and free policy engine, supporting the practice of policy and security as code.
It gives the ability to decouple and offload policy decision making from policy enforcement.
The general promise land for OPA is to shift the decision-making process to a dedicated engine that enables administrators and operation teams to have more control over the characteristics of how services provisioned and interact at runtime. It can also be used to unify policy enforcement across a wide range of technologies.
For example, the domain specific implementation of OPA engine policy enforcement point for Kubernetes, is OPA Gatekeeper that runs a Kubernetes Admission Controller webhook. Here is what this looks like:
- User creates a new Kubernetes object,
- OPA Gatekeeper, as a validating admission controller, receives the request directly from the API server,
- The validation request contains an admitted object.
- OPA Gatekeeper will Allow or Deny admission based on the policy decision made in accordance to the configured policies.
Are you drinking the OPA Kool Aid?
The underlying OPA engine is a functional programming language called Rego.
It is flexible enough to express and author fine-grained policies that act on JSON documents.
Example: OPA Gatekeeper Constraint Template that checks for Privilege Escalation
Another pure Rego example, shows how policy denies objects that include container images referring to registries that are not allowed:
The main advantage of OPA Gatekeeper as policy controller for Kubernetes can be captured around the following:
- Open & Free
- Has a community driven library of solid functionality primarily around pod security policies (not to be confused with PodSecurityPolicy which is a Kubernetes Native policy construct)
- Seamless integration with Kubernetes RBAC by leveraging Native Kubernetes CRDs
- Extensions, in the form of OPA Constraint Framework are parameterized
- Improved audit capabilities for your Kubernetes resources, allowing administrators to intercept any policy violations
The dark (and incomplete) side of OPA Gatekeeper
- The concept of open source & free have in general a well known hidden tax rate. OPA specifically has a higher tax rate because Rego programming language has a very steep learning curve and requires dedicated platform and/or ops team members to invest time and cycles to learn, maintain, develop content and operate OPA Gatekeeper.
- Rego is a functional programming language and it is often seen as a non- intuitive one compared to other languages such as Go or Python. A nice example to wrap your head around, which we surfaced a while ago can be found here
- While the concept of compliance-as- code is powerful in terms of shifting security left - it remains extremely challenging to coordinate and collaborate between engineering teams, cluster operators, security teams that are more used to fancy dashboards than git repositories.
- Admission Controllers are useful and powerful for creating guardrails and enforcing policies on admitted Kubernetes resources, however it’s NOT a one-stop-shop. For example - if your governance policy, in this case PCI, says “Alert when user X, exec into any Pod in namespace card_holder_data” - OPA Gatekeeper is not even aware of such events.
Another example is around checks that attempt to triage orphaned resources - Persistent Volumes or secrets - where OPA Gatekeeper and admission time are the wrong vehicle to implement such hygiene checks.
Embedded OPA Experience & Alcide Security Platform
The Alcide Kubernetes Security Platform dramatically expands the use cases covered by OPA Gatekeeper. You can run, operate and manage Alcide Advisor’s Admission Control policies through a cloud service that unifies policy management, and enables all relevant stakeholders- Engineering, DevOps and Security - to collaborate and author policies as well as view, remediate, share, and export reports of the findings from one or many clusters.
Alcide Security Platform also enables you to apply policies through the early stage of the CD pipeline by analyzing the cluster remotely (via APIs) while consuming and applying the very same policies used in production clusters, on those dev/test clusters. It enables teams to fail fast and remediate fast in dev and test environments - before changes are delivered to the staging or production clusters. Users of the Platform can create and define their own policies as well as OPA’s policies shared by the community.
For example, let’s look at this specific “Container Capabilities” test, that checks that the containers’ securityContext configuration is aligned with the OPA policy:
Source: Alcide Advisor
OPA policy checks and constraints align with more than 120 security tests conducted by the Alcide Advisor and are ingested to a consolidated, single-pane dashboard. This provides the user with a graphical view of alerts and trends for security and compliance checks.
For more information on Alcide and how you can leverage OPA capabilities contact us at firstname.lastname@example.org.