Gloo Edge Gateway Policy Authoring

Policy authoring with Gloo Edge Gateway defines which HTTP APIs are permitted in and out of a service running with a Gloo Edge Gateway. The Gloo Edge Gateway enforces policies and never sees a rejected API request. Additionally, you can explicitly write a policy that your service calls into to provide additional information that Gloo Edge Gateway does not have. The service enforces decisions appropriately.

Pre-installed Policies

Several policies are automatically applied when the Gloo Edge Gateway System is installed. In the Styra DAS UI, click on the App and Ingress folders from your Gloo Edge Gateway System to see the policies.

• App: Custom policy that you can use if your application needs additional policy decisions from OPA.
• Ingress: Policy that either allows or denies incoming traffic.

Write Ingress and Egress Policies

When authoring policies, use OPA's policy language, Rego.

The following resources provide an introduction to Rego:

• OPA Documentation: Introduction to OPA or Rego Documentation
• Free Video Training: Styra Academy

When writing Rego policies, you need to know the JSON format provided to each of your policies as input. The following shows a sample input provided by Gloo Edge for Ingress policies. This sample includes source, destination, request, and additional metadata.

{
    "attributes": {
        "destination": {},
        "metadata_context": {},
        "request": {
            "http": {
                "headers": {
                    ":authority": "gateway-proxy.gloo-system.svc.cluster.local:80",
                    ":method": "GET",
                    ":path": "/finance/salary/charlie",
                    "accept": "*/*",
                    "authorization": "Basic Ym9iOnBhc3N3b3Jk",
                    "user-agent": "curl/7.74.0-DEV",
                    "x-envoy-internal": "true",
                    "x-forwarded-for": "172.17.0.1",
                    "x-forwarded-proto": "https",
                    "x-request-id": "905393fa-03ca-4bd5-939c-1bc4b26eccaa"
                },
                "host": "gateway-proxy.gloo-system.svc.cluster.local:80",
                "id": "`2924924403999187583`",
                "method": "GET",
                "path": "/finance/salary/charlie",
                "protocol": "HTTP/1.1"
            }
        }
    }
}

When writing policies, the allow or deny rules are written to describe the conditions under which a request is allowed or denied. By default, requests are all allowed, so you must write policy to deny them.

For example, if you want to allow all GET requests and deny all POST requests to the root path, then write the following allow and deny rules.

# allow GET requests to the root path
allow {
    input.attributes.request.http.method == "GET"
    input.attributes.request.http.path == "/"
}

# deny POST requests to the root path
deny {
    input.attributes.request.http.method == "POST"
    input.attributes.request.http.path == "/"
}

Write App Rules for OPA-aware Applications

In addition to the ingress policies, the Gloo Edge Gateway System supports application policies. The structure of these policies is customizable according to the application's requirements. By default, the module policy.app contains allow and deny rules similar to Ingress and Egress policies, but you can remove those and write any Rego that you'd like.

An application can directly query the OPA embedded in the data plane sidecar, usually listening at localhost:8181, for application-specific authorization decisions. The default data document for application policies is data.application.main. This exercises the allow or deny rule created in policy.app module.

Gloo Edge Architecture for OPA-aware Applications

The App-specific main rule can be queried as shown in the following example:

curl -XPOST localhost:8181/v1/data/application/main \
  -d '{
        "input": {
          "method": "GET",
          "path": [
            "finance",
            "salary",
            "bob"
          ],
          "user": "bob"
        }
    }'

{
    "decision_id":"d9abc874-d27b-4ee4-9542-c044871484c9",
    "result": {
        "allowed": true,
        "code": 200,
        "status_code": 200,
        "outcome": {
            "allowed": true,
            "code": 200,
            "status_code": 200,
            "policy_type": "app",
            "system_type": "gloo"
        }
    }
}

The decision mappings for Gloo Edge Gateway Systems rely on the presence of well-known fields to correctly parse the results. The decision mapper expects an outcome structure in the result with two required fields: allowed and policy_type.

{
  "outcome": {
    "allowed": false,     // boolean value to determine if decision was Allowed or Denied
                          // an absence of this value will mark the decision as Unknown
    "policy_type": "app"  // classifies the decision as an app decision
                          // useful for filtering decisions by type in the Decisions UI
  }
}