Sometimes you need a general-purpose policy engine that unifies policy enforcement across the stack. That policy engine can give you a centralized decision-making entity for systems that involve multiple NetScalers or multiple distributed devices. Open Policy Agent (OPA) enables you to specify policy as code and simple APIs so you can offload policy decision-making from your software. It helps you decouple policy decision-making from policy enforcement and can act as a centralized decision making entity for the system. You can use OPA to enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more.
Citrix provides an implementation of the Kubernetes Ingress Controller to manage and route traffic into your Kubernetes cluster using Netscaler CPX, VPX, or MPX. In this blog post, we’ll look at using OPA for cloud-native apps with Citrix Ingress Controller.
OPA Use Cases
OPA, which uses Rego as its policy language, generates policy decisions by evaluating the query input against policies and data. OPA and Rego are domain-agnostic so you can describe almost any kind of invariant in your policies. For example:
- Which users can access which resources
- Which subnets egress traffic is allowed to
- Which clusters a workload must be deployed to
- Which registries binaries can be downloaded from
- Which OS capabilities a container can execute with
- Which times of day the system can be accessed at
Policy decisions are not limited to simple yes/no or allow/deny answers. Like query inputs, policies can also generate arbitrary structured data as output, which means any complex decision-making can be done through OPA.
OPA Support with NetScaler
You can support OPA integration on NetScaler through an HTTP callout. What is an HTTP callout? It’s an HTTP or HTTPS request that the NetScaler appliance generates and sends to an external application when certain criteria are met. The information retrieved from the server can be analyzed and an appropriate action can be performed based on the requirement.
The diagram above provides an overview of how an HTTP callout is used with NetScaler. The HTTP callout agent is the server that responds to an HTTP callout request, and the OPA server can act as HTTP callout agent.
- Client request.
- HTTP callout request to the HTTP callout agent, to get a decision.
- Response from HTTP callout agent.
- Based on the response from the HTTP callout agent, the request is forwarded to the service if the client is allowed to access the service.
- Based on the response from the HTTP callout agent, the response is sent to client if the client is not allowed to access the service.
You can have a centralized HTTP callout agent in the form of an OPA server.
OPA Support Using Citrix Ingress Controller
The diagram above provides an overview of OPA support with Citrix Ingress Controller.
- Create the required Kubernetes objects, which should include a custom resource definition (CRD) to perform the HTTP callout to the OPA server.
- The Citrix Ingress Controller configures the NetScaler based on the Kubernetes objects created.
- The user requests the resource. The user will be authenticated if authentication CRDs are created.
- The HTTP callout goes to the OPA server in JSON format, carrying the authorization parameters.
- The authorization decision comes from the OPA server and is based on rules defined in Rego.
- The client receives a response based on the authorization decision.
Here, OPA isolates policy decision-making from policy enforcement, and NetScaler handles policy enforcement based on the decision from OPA server. OPA can act as a centralized decision-making entity for a system involving multiple NetScalers or devices that are distributed. The administrator only has to make updates to the OPA server for decision-specific changes, reducing the administrative work that comes with making changes to each NetScaler or device.
For more examples and information about OPA support using Citrix Ingress Controller, check out our OPA with Citrix Ingress Controller product documentation. If there are features you’d like to see in Citrix Ingress Controller, let us know below.
