Enforce authorization policies
After you have added your application to the ambient mesh, you can secure application access using Layer 4 authorization policies.
This feature lets you control access to and from a service based on the client workload identities that are automatically issued to all workloads in the mesh.
Enforce Layer 4 authorization policy
Let’s create an authorization policy that restricts which services can communicate with the productpage
service. The policy is applied to pods with the app: productpage
label, and it allows calls only from the the service account cluster.local/ns/default/sa/bookinfo-gateway-istio
. (This is the service account that is used by the Bookinfo gateway you deployed in the previous step.)
$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: productpage-viewer
namespace: default
spec:
selector:
matchLabels:
app: productpage
action: ALLOW
rules:
- from:
- source:
principals:
- cluster.local/ns/default/sa/bookinfo-gateway-istio
EOF
If you open the Bookinfo application in your browser (http://localhost:8080/productpage
), you will see the product page, just as before. However, if you try to access the productpage
service from a different service account, you should see an error.
Let’s try accessing Bookinfo application from a sleep
pod:
$ kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.22/samples/sleep/sleep.yaml
Since the sleep
pod is using a different service account, it will not have access the productpage
service:
$ kubectl exec deploy/sleep -- curl -s "http://productpage:9080/productpage"
command terminated with exit code 56
Enforce Layer 7 authorization policy
To enforce Layer 7 policies, you first need a waypoint proxy for the namespace. This proxy will handle all Layer 7 traffic entering the namespace.
$ istioctl x waypoint apply --enroll-namespace --wait
waypoint default/waypoint applied
namespace default labeled with "istio.io/use-waypoint: waypoint"
You can view the waypoint proxy and make sure it has the Programmed=True
status:
$ kubectl get gtw waypoint
NAME CLASS ADDRESS PROGRAMMED AGE
waypoint istio-waypoint 10.96.58.95 True 42s
Adding a L7 authorization policy will explicitly allow the sleep
service to send GET
requests to the productpage
service, but perform no other operations:
$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: productpage-viewer
namespace: default
spec:
targetRefs:
- kind: Service
group: ""
name: productpage
action: ALLOW
rules:
- from:
- source:
principals:
- cluster.local/ns/default/sa/sleep
to:
- operation:
methods: ["GET"]
EOF
Note the targetRefs
field is used to specify the target service for the authorization policy of a waypoint proxy. The rules section is similar as before, but this time we added the to
section to specify the operation that is allowed.
Confirm the new waypoint proxy is enforcing the updated authorization policy:
$ # This fails with an RBAC error because we're not using a GET operation
$ kubectl exec deploy/sleep -- curl -s "http://productpage:9080/productpage" -X DELETE
RBAC: access denied
$ # This fails with an RBAC error because the identity of the reviews-v1 service is not allowed
$ kubectl exec deploy/reviews-v1 -- curl -s http://productpage:9080/productpage
RBAC: access denied
$ # This works as we're explicitly allowing GET requests from the sleep pod
$ kubectl exec deploy/sleep -- curl -s http://productpage:9080/productpage | grep -o "<title>.*</title>"
<title>Simple Bookstore App</title>
Next steps
With the waypoint proxy in place, you can now enforce Layer 7 policies in the namespace. In addition to authorization policies, we can use the waypoint proxy to split traffic between services. This is useful when doing canary deployments or A/B testing.