Kong Gateway Policy Authoring
Policy authoring with Kong Gateway defines which HTTP APIs are permitted in and out of a service running with a Kong Gateway. The Kong 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 Kong Gateway does not have. The service enforces decisions appropriately.
Pre-installed Policies
Several policies are automatically applied when the Kong Gateway System is installed. In the Styra DAS UI, click on the App and Ingress folders from your Kong 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 Policy
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 format of the JSON that is provided to each of your policies as input. The following shows a sample input provided by Kong Gateway for ingress policy. This sample includes HTTP method, requested path, source address and headers with destination address.
{
"headers":{
"accept":"*/*",
"host":"192.168.49.2:31961",
"user-agent":"curl/7.68.0"
},
"method":"GET",
"path":"/finance/salary/bob",
"remote_address":"172.17.0.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, all requests are allowed and you can create policies to deny rules.
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
rule.
# allow GET requests to the root path
allow {
input.method == "GET"
input.path == "/"
}
# deny POST requests to the root path
deny {
input.method == "POST"
input.path == "/"
}
The decision mapping for Kong Gateway Systems relies on the presence of well-known field to correctly parse the results. The decision mapper expects and allowed field in the result*.
{
"result": {
"allowed": false // boolean value to determine if decision was Allowed or Denied
// an absence of this value will mark the decision as Unknown
}
}