<img src="https://ws.zoominfo.com/pixel/JHVDdRXH2uangmUMQBZd" width="1" height="1" style="display: none;">

Securing Your Deploy Time Environment with PaC

Kubernetes Kubernetes Governance Policy as Code
Securing Your Deploy Time Environment with PaC
Kubernetes Kubernetes Governance Policy as Code

You work hard to ensure the code you develop and deploy is free of issues related to compliance. The last thing you and the team need is another set of boundaries. How do more rules translate to new and more innovative problem solving? At first glance, they won’t! However, in today’s world of automation, Open Policy Agent (OPA) allows peace of mind for the entire team while promoting Policy-as-code (PaC).

Open Policy Agent Keeps Kubernetes Clean

To control what happens within our Kubernetes clusters, an admission controller is used to enforce specific policies. Without such a control in place, many of the advanced features we seek out in our Kubernetes cluster would be highly underutilized. Virtually any aspect of the container can be controlled to modify the makeup of the cluster.

In a sense, you could call them the safety bumpers we use to keep us on the rails no matter what the velocity. Instead of having to keep each individual new policy in mind, we can rely on tools meant to specifically help us along the way. Beyond enforcement of rules for image structure upon entering the cluster, relying on OPA allows for mutating incoming objects. Effectively putting a lot of the dirty-work on automation in a controlled manner.

This use of OPA as an admission controller keeps things on-track without injecting more steps in your workflow. Most teams can appreciate the importance of not having more steps added to getting their code to production. If containers and Kubernetes are meant to help orchestrate development and infrastructure, think of OPA as the conductor.


Magalix Governance Whitepaper

 

Learn why Kubernetes Governance is crucial to scaling business operations with Magalix latest whitepaper.

“Shift-Left Cloud-Native Security with a DevOps Mindset”.

Download Now

 


OPA and Gatekeeper Work in Tandem

Looking deeper into the usage of OPA we see its main function as an admission controller is to assist in laying the foundation of a service’s infrastructure. There are a number of situations where this could be useful. If implemented correctly, it could easily standardize an environment

to whatever constraints needed with considerably less effort.

At the top of the list is the ease of configuration and organization that the admission controller brings to the table. Requirements are set at the controller level that must be met to successfully run in the environment. This could be ensuring items are named using a standardized naming convention, preventing conflicts, or being specific as to where container images are obtained.

A new addition that works in tandem with OPA is Gatekeeper. Gatekeeper promises to add an even greater layer of integration when used in conjunction with OPA as an admission controller. It injects an additional layer of policy libraries in the form of constraints defined in templates written in Rego.

Auditing functionality allows for those policies to extend to any replicated portion of infrastructure on a predefined timetable. Doing so helps enforce configurations set forth in not just existing, but new policies as well. Keeping this in mind, you can see where the usefulness of this type of real time policy management comes in handy in your Kubernetes cluster.

Extending OPA Gatekeeper is quickly finding itself injected into development cycles. Forward-thinking companies like Magalix are taking the foundation of this admission controller and simplifying it to provide useful interfaces, pre-configured policy, and an overall feeling of security.

In our example, we just want to show one possible example using the base components needed. For those who want to hit the ground running with a much more robust solution, have a look at KubeGuard. If OPA Gatekeeper is the conductor, KubeGuard is making it even easier by putting up guardrails.

OPA Gatekeeper in Action

In our scenario, it was made known in the last DevSecOps meeting that nothing should be accessing resources within the production cluster over standard http. All traffic should be secured with TLS in order to ensure compliance with the latest requirements for the company’s payment system.

Along with code in development, additional files are checked in that represent the Gatekeeper constraint information. By storing this alongside or in an external repository, DevOps engineers are able to include them as part of the CI/CD process. Much in the same way application code is managed, this Policy-as-Code approach ensures a historical view of changes, promotes peer review, and allows tasks to translate to actual code commits.

A portion of our fictitious application uses NGINX to respond to API requests that come from the web frontend. While it is all within the same domain, it is now non-compliant with the new set of rules. The policy is approved by DevOps and a scripted process is used to implement it with OPA Gatekeeper.

 
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8shttpsonly
  annotations:
    description: Requires Ingress resources to be HTTPS only; TLS configuration should
      be set and `kubernetes.io/ingress.allow-http` annotation equals false.
spec:
  crd:
    spec:
      names:
        kind: K8sHttpsOnly
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8shttpsonly
        violation[{"msg": msg}] {
          input.review.object.kind == "Ingress"
          re_match("^(extensions|networking.k8s.io)/", input.review.object.apiVersion)
          ingress := input.review.object
          not https_complete(ingress)
          msg := sprintf("Ingress should be https. tls configuration and allow-http=false annotation are required for %v", [ingress.metadata.name])
        }
        https_complete(ingress) = true {
          ingress.spec["tls"]
          count(ingress.spec.tls) > 0
          ingress.metadata.annotations["kubernetes.io/ingress.allow-http"] == "false"
        }

We then activate the below constraint using additional scripting via automation configured by DevOps.

 
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sHttpsOnly
metadata:
  name: ingress-https-only
spec:
  match:
    kinds:
      - apiGroups: ["extensions", "networking.k8s.io"]
        kinds: ["Ingress"]

At this point, we have not re-deployed the offending service. It is already running within the cluster. What we are doing is implementing a method to manage policies within Kubernetes in the same automated fashion we use to deploy compiled code.

The policy constraint is now violated for containers that were previously serving over port 80. A status message is relayed and the compliance issue is resolved by disallowing functionality over the unsecured protocol.

Policy-as-Code Secures More than Just Ports

In this example, not only was the code for our software part of a CI/CD process, so were the necessary files used to implement constraints via OPA Gatekeeper. Keeping a structured repository for these resources resulted in the ability for the team to move quickly on new policies.

This is an innate ability of taking a Policy-as-code approach. Over time, manually implementing policy changes at the scale needed in a production environment will take its toll. This is especially true if some sort of automation is not put into play. Thanks to many of the ways OPA Gatekeeper operates, much of this can be planned, discussed, and implemented in a way that helps us know exactly what to expect.

The people at Magalix recognize how much easier it is to manage and maintain Kubernetes clusters when implementing these methods. By doing much of the heavy lifting, they open the ability to jump in and utilize these features with less of a learning curve. Products like the aforementioned KubeGuard and KubeAdvisor work well together to make a cohesive system

Comments and Responses

Related Articles

Product In-Depth: Enforce Policies and Standards from a Single Console

Magalix provides a single management interface to control, enforce and visualize the state of compliance for all of your clusters.

Read more
Product In-Depth: Centralized Policy Management

achieving DevSecOps isn’t as difficult as you may have been led to believe. Interested in learning more about how to start resolving violations in minutes

Read more
Product In Depth: Detailed Violation Analysis

Security, compliance, and governance are not just one-time events that happen every so often. Managing a compliant environment is a 24x7 operation.

Read more