OPA with Rego rules in config maps
Enforce Open Policy Agent (OPA) policies for more fine-grained access control.By default, the Gloo Platform external auth service is enabled to use an OPA module. You can create your Rego rules as Kubernetes config maps in the cluster. Then, you use an external auth policy to tell the Gloo external auth service to load these rules via the OPA module. This approach can be convenient for quick testing or small OPA use cases.
Other OPA options:
- You can still load Rego rules with a Kubernetes config map to the Gloo external auth service even when you use other OPA server methods.
- Bring your own OPA server for extended OPA capabilities such as bundling.
- Instead of bringing your own server, you can deploy an OPA server as a sidecar to the Gloo external auth service.
If you import or export resources across workspaces, your policies might not apply. For more information, see Import and export policies.
Before you begin
- Complete the multicluster getting started guide to set up the following testing environment.
- Three clusters along with environment variables for the clusters and their Kubernetes contexts.
- The Gloo Platform CLI,
meshctl
, along with other CLI tools such askubectl
andistioctl
. - The Gloo management server in the management cluster, and the Gloo agents in the workload clusters.
- Istio installed in the workload clusters.
- A simple Gloo workspace setup.
- Install Bookinfo and other sample apps.
- Make sure that the external auth service is installed and running. If not, install the external auth service in your single or multicluster environment.
kubectl get pods -A -l app=ext-auth-service --context ${REMOTE_CONTEXT1}
Configure an external auth policy with OPA
Create the external auth policy with OPA.
-
Create an OPA Rego policy file.
Review the following table to understand this configuration.cat <<EOF > policy.rego package test default allow = false allow { startswith(input.http_request.path, "/ratings/2") input.http_request.method == "GET" } allow { input.http_request.path == "/ratings/3" any({input.http_request.method == "GET", input.http_request.method == "DELETE" }) } EOF
Setting Description default allow = false
Denies all requests by default. allow {...}
Allows requests that match two conditions as follows. 1) The path starts with /ratings/2
AND the HTTP method isGET
; or, 2) the path is exactly/ratings/3
AND the HTTP method is eitherGET
orDELETE
. -
Store the OPA policy in a Kubernetes config map in the workload cluster that you want to create the external auth policy in.
kubectl -n bookinfo create configmap allow-get-users --from-file=policy.rego --context ${REMOTE_CONTEXT1}
-
Create an external auth server to use for your policy.
kubectl apply --context ${REMOTE_CONTEXT1} -f - <<EOF apiVersion: admin.gloo.solo.io/v2 kind: ExtAuthServer metadata: name: ext-auth-server namespace: bookinfo spec: destinationServer: port: number: 8083 ref: cluster: $REMOTE_CLUSTER1 name: ext-auth-service namespace: gloo-mesh-addons EOF
-
Create an external auth policy that uses the OPA config map.
When you create the policy with a destination selector, only Kubernetes services can be specified in the
applyToDestination
section. Gloo virtual destinations or Gloo external services are not supported.kubectl apply --context ${REMOTE_CONTEXT1} -f - <<EOF apiVersion: security.policy.gloo.solo.io/v2 kind: ExtAuthPolicy metadata: name: ratings-opa namespace: bookinfo spec: applyToDestinations: - selector: labels: app: ratings config: server: name: ext-auth-server namespace: bookinfo cluster: $REMOTE_CLUSTER1 glooAuth: configs: - opaAuth: modules: - name: allow-get-users namespace: bookinfo query: "data.test.allow == true" EOF
Review the following table to understand this configuration. For more information, see the API reference.
Setting | Description |
---|---|
applyToDestinations |
Configure which destinations to apply the policy to, by using labels. Destinations can be a Kubernetes service, VirtualDestination, or ExternalService. If you do not specify any destinations or routes, the policy applies to all destinations in the workspace by default. If you do not specify any destinations but you do specify a route, the policy applies to the route but to no destinations. |
server |
The external auth server to use for the policy. |
opaAuth |
Configure the OPA authentication details. |
modules |
Refer to the name and namespace of the config map that has the OPA policy. Then, Gloo can use the OPA policy to use to resolve the query . This example uses the config map that you previously created. |
query |
The query that determines the authentication decision. The result of this query must be either a boolean or an array with a boolean as the first element. A value of true means that the request is authorized. Any other value or error means that the request is denied. In this example, data.test.allow is set to true . data is the section in the config map. test.allow are part of the OPA policy that you previously created. Access is allowed only if the response meets the allow conditions in the policy. |
Verify the external auth API key policy
-
Send a request to the
ratings
app along a path that is not allowed by the OPA policy, such as/ratings/1
. Now, the request is blocked with a 403 response.Create a temporary curl pod in the
bookinfo
namespace, so that you can test the app setup. You can also use this method in Kubernetes 1.23 or later, but an ephemeral container might be simpler, as shown in the other tab.- Create the curl pod.
kubectl run -it -n bookinfo --context $REMOTE_CONTEXT1 curl \ --image=curlimages/curl:7.73.0 --rm -- sh
- Send a request to the ratings app.
curl http://ratings:9080/ratings/1 -v
Use the
kubectl debug
command to create an ephemeral curl container in the deployment. This way, the curl container inherits any permissions from the app that you want to test. If you don't run Kubernetes 1.23 or later, you can deploy a separate curl pod or manually add the curl container as shown in the other tab.kubectl --context ${REMOTE_CONTEXT1} -n bookinfo debug -i pods/$(kubectl get pod --context ${REMOTE_CONTEXT1} -l app=reviews -A -o jsonpath='{.items[0].metadata.name}') --image=curlimages/curl -- curl -v http://ratings:9080/ratings/1
If the output has an error about
EphemeralContainers
, see Ephemeral containers don’t work when testing Bookinfo. - Create the curl pod.
-
Send the request again, this time along a path that is allowed by the OPA policy, such as
GET /ratings/2
.Create a temporary curl pod in the
bookinfo
namespace, so that you can test the app setup. You can also use this method in Kubernetes 1.23 or later, but an ephemeral container might be simpler, as shown in the other tab.- Send a request to the ratings app.
curl -v -X GET http://ratings:9080/ratings/2
- Exit the temporary pod. The pod deletes itself.
exit
Use the
kubectl debug
command to create an ephemeral curl container in the deployment. This way, the curl container inherits any permissions from the app that you want to test. If you don't run Kubernetes 1.23 or later, you can deploy a separate curl pod or manually add the curl container as shown in the other tab.kubectl --context ${REMOTE_CONTEXT1} -n bookinfo debug -i pods/$(kubectl get pod --context ${REMOTE_CONTEXT1} -l app=reviews -A -o jsonpath='{.items[0].metadata.name}') --image=curlimages/curl -- curl -v -X GET http://ratings:9080/ratings/2
You can reach the ratings app again!
{"id":1,"ratings":{"Reviewer1":5,"Reviewer2":4}}
- Send a request to the ratings app.
-
Optional: Clean up the resources that you created.
kubectl -n bookinfo delete ConfigMap allow-get-users kubectl -n bookinfo delete ExtAuthPolicy ratings-opa kubectl -n bookinfo delete ExtAuthServer ext-auth-server