Features Provided by OPA

Features Provided by OPA

In this article, we will see what features OPA has. We also talk about how Magalix OPA SaaS automatically integrates and provides cluster status within the same view. Listed below are some of the OPA features, which help us in securing the cluster.

Enforce Policies and Constraint

By defining Constraint, we are setting a specific requirement that has to be met by the author. The constraint is written in Rego (ray-go), the declarative query language used by Open Policy Agent, which lists the data that violates the system’s expected state. When a request goes through the admission controller, it evaluates the request. If one Constraint is not satisfied, the whole request will be rejected.

First, we have to create a Constraint Template that allows for the new Constraint declaration. Let’s look at this example:

 
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8sdenyname
spec:
  crd:
    spec:
      names:
        kind: K8sDenyName
      validation:
        openAPIV3Schema:
          properties:
            invalidName:
              type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sdenynames
        violation[{"msg": msg}] {
          input.review.object.metadata.name == input.parameters.invalidName
          msg := sprintf("The name %v is not allowed", [input.parameters.invalidName])
        }

The above YAML template is used to deny all resources whose name matches the end-user value.

 
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDenyName
metadata:
  name: no-policy-violation-name
spec:
  parameters:
    invalidName: "policy-violation"

The above example where we implement Constraint to deny all the resources with a name policy-violation.

Audit Functionality by OPA

Open Policy Agent also provides Audit functionality by enabling periodic evaluation of all previously accepted resources and produces the report on a resource that violates that functionality. You can see the audit report by using the following command:

 
$ kubectl get constraint-kind constraint-name -o yaml

In our example, it is

 
$ kubectl get K8sDenyName no-policy-violation-name -o yaml

 
status:
  auditTimestamp: "2020-09-06T01:46:13Z"
  byPod:
  - enforced: true
    id: gatekeeper-controller-manager-0
  violations:
  - enforcementAction: deny
    kind: Pod
    message: ‘The name policy-violation is not allowed'
    name: policy-violation
  - enforcementAction: deny
    kind: Deployment
    Message: ‘The name policy-violation is not allowed'
    name: policy-violation

You can see that two resources violate the rule as they have used policy violation as the resource name and the timestamp is also given on which auditing is done. Using OPA, you don’t just enforce policy and constraint with newly created resources, you also check for pre-existing resource misconfiguration.

You can see at most 20 violations in the output. If there are more than 20, then you will have to see the complete list using logs.

You can also see how to enforce pod security policy in Kubernetes with OPA, which will automatically detect if it is valid to deploy the pod at the time of creation.

Here we can see how easy it is to audit resources and check for violations using the Magalix dashboard.

Here is the Magalix dashboard, and you can see a pie chart representing the violation of different policies. Click on values like we have chosen Name Violation, and then you can see all the issues created with an Advisor, as we are having only one.Now you can click on Magalix and see how many entities are violating the policies. You can see two pods have Magalix in their name and violate the policy of not having Magalix as a resource name.

Monitoring with OPA

OPA uses Prometheus for monitoring. It exposes an HTTP endpoint that is used to collect and show metrics for API calls. When the OPA server runs, it automatically enables the Prometheus endpoint. OPA exposes /health endpoint that is used for health checks.

You can also use this configuration file to enable metric collection.

 
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: "opa"
    metrics_path: "/metrics"
    static_configs:
    - targets:
      - "localhost:8181"

You can also use Magalix KubeAdvisor to check for violations, Utilization, and capacity within the same view. As a demonstration purpose, it has only one node connected, you can connect more than one, and you are viewing all of the nodes and their status all in one view.

TL;DR

• OPA is used to secure the cluster
• OPA intercepts API calls and validates these resources at creation, updating, and deletion.
• OPA is used to create policies and constraint which then used for validating the resource if it is violating any of the policy
• OPA also has the Audit functionality, which enables us to check pre-existing resources for misconfiguration.
• OPA can be monitored using Prometheus. It scrapes metrics at port 8181
• OPA use rego, a declarative query language for writing policies and validating resources
• Magalix OPA SAAS offered a unified and declarative way of defining policies and you can audit and see the violation in the UI format.