Use Layer 4 authorization policies - Alibaba Cloud Service Mesh

The configuration model of authentication and authorization in Ambient Mesh mode is different from that in the original Sidecar mode due to the separation between Layer 4 and Layer 7. This topic describes how to use Layer 4 authorization policies in Service Mesh (ASM) instances of v1.18.

Prerequisites

An ingress gateway and related applications are deployed, and basic features are verified. For more information, see Prerequisites and Step 1 in Getting started.

Limits

The following limits are applicable to authorization policies in ztunnels:
- The action field cannot be set to CUSTOM, which indicates that ztunnels do not support custom authorization services.
- The requestPrincipals and remoteIpBlocks fields are not supported in the source field.
- Only the ports field is supported in the operation field.
When no waypoint proxy is deployed, authorization policies are enforced by ztunnels. In this case, authorization policies must be bound to the specified workloads.
A ztunnel is a Layer 4 proxy. If you configure an authorization policy that contains Layer 7 rules on a ztunnel, only Layer 4 rules take effect.

Example 1: Allow only the gateway and the sleep application to access the productpage service

This example verifies whether ztunnels can correctly execute authorization based on principals. For more information, see Getting started.

After the test is complete, run the following command to remove the authorization policy:

kubectl delete authorizationpolicy productpage-viewer

Example 2: Prohibit access to port 9080 of the productpage service

This example mainly verifies whether ztunnels can correctly execute authorization based on destination ports.

Use the following content to create a productpage-viewer.yaml file:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: productpage-viewer
 namespace: default
spec:
 selector:
   matchLabels:
     app: productpage
 action: DENY
 rules:
 - to:
   - operation:
       ports:
       - "9080"

Use kubectl to connect to the ASM instance based on the information in the kubeconfig file, and then run the following command to create the authorization policy:
```
kubectl apply -f productpage-viewer.yaml
```
Verify whether the authorization policy takes effect.
1. Run the following command to perform an access test:
```
kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Expected output:
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
2. Run the following command to perform an access test:
```
kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Expected output:
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
3. Run the following command to perform an access test:
```
kubectl exec deploy/sleep -- curl -s http://productpage:9080/
```
  Expected output:
```
command terminated with exit code 56
```
4. Run the following command to perform an access test:
```
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Expected output:
```
command terminated with exit code 56
```
  The output indicates that all pods cannot access port 9080 of the productpage service.
  In the first two tests, an upstream connect error or disconnect/reset before headers. reset reason: connection termination% error is reported in the responses to the requests to access the productpage service through the gateway. This error is actually returned by the ingress gateway. If the gateway cannot access the productpage service (the productpage service does not allow the ingress gateway to access its 9080 port), an HTTP 503 error is reported.
  The responses in the last two tests are command terminated with exit code 56, which is returned by the curl command. The curl command directly attempts to establish a connection with the productpage service, but the connection fails to be established. Therefore, no HTTP error is reported, which is different from the error of direct access through the gateway.
Run the following command to remove the authorization policy:
```
kubectl delete authorizationpolicy productpage-viewer
```

Example 3: Prohibit the IP address of the sleep pod to access the productpage service

This example mainly verifies whether ztunnels can correctly execute authorization based on source IP addresses.

Run the following command to query the IP address of the sleep pod:

kubectl get pod -o wide | grep sleep

Expected output:

notsleep-5fb85fb789-z****         1/1     Running   0          48m   10.0.67.92   cn-hangzhou.10.0.67.41   <none>           <none>
sleep-bc9998558-z****             1/1     Running   0          48m   10.0.67.91   cn-hangzhou.10.0.67.42   <none>           <none>

The expected output indicates that the IP address of the sleep pod in the current test environment is 10.0.67.91. The actual pod IP address in each environment may be different.

Use the following content to create a productpage-viewer.yaml file that prohibits the requests from the IP address of the sleep pod from accessing the productpage service.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: productpage-viewer
 namespace: default
spec:
 selector:
   matchLabels:
     app: productpage
 action: DENY
 rules:
 - from:
   - source:
       ipBlocks:
       - ${sleep Pod IP}

Use kubectl to connect to the ASM instance based on the information in the kubeconfig file, and then run the following command to create the authorization policy:
```
kubectl apply -f productpage-viewer.yaml
```
Verify whether the authorization policy takes effect.
1. Run the following command to perform an access test:
```
kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o "<title>.*</title>"
```
  Expected output:
```
<title>Simple Bookstore App</title>
```
2. Run the following command to perform an access test:
```
kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o "<title>.*</title>"
```
  Expected output:
```
<title>Simple Bookstore App</title>
```
3. Run the following command to perform an access test:
```
kubectl exec deploy/sleep -- curl -s http://productpage:9080/
```
  Expected output:
```
command terminated with exit code 56
```
4. Run the following command to perform an access test:
```
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Expected output:
```
<title>Simple Bookstore App</title>
```
  The output indicates that when you deploy only ztunnels and do not deploy a waypoint proxy, you cannot prohibit the sleep pod from accessing the productpage service through the gateway. This is because the remoteIpBlocks field in the authorization policy depends on the X-Forwarded-For header of a request, whereas a ztunnel is a Layer -4 proxy.
Run the following command to remove the authorization policy:
```
kubectl delete authorizationpolicy productpage-viewer
```

Example 4: Prohibit the pods in the istio-system namespace from accessing the productpage service

This example mainly verifies whether ztunnels can correctly execute authorization based on source namespaces. A source namespace refers to the namespace in which a pod initiates a request.

Use the following content to create a productpage-viewer.yaml file that prohibits the pods in the istio-system namespace from accessing the productpage service:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: productpage-viewer
 namespace: default
spec:
 selector:
   matchLabels:
     app: productpage
 action: DENY
 rules:
 - from:
   - source:
       namespaces:
       - istio-system

Use kubectl to connect to the ASM instance based on the information in the kubeconfig file, and then run the following command to create the authorization policy:
```
kubectl apply -f productpage-viewer.yaml
```
Verify whether the authorization policy takes effect.
1. Run the following command to perform an access test:
```
kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Expected output:
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
2. Run the following command to perform an access test:
```
kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Expected output:
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
3. Run the following command to perform an access test:
```
kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Expected output:
```
<title>Simple Bookstore App</title>
```
4. Run the following command to perform an access test:
```
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Expected output:
```
<title>Simple Bookstore App</title>
```
  The ingress gateway is deployed in the istio-system namespace. The output indicates that after the authorization policy is created, the sleep and notsleep applications cannot access the productpage service through the gateway, but they can directly access the productpage service.
Run the following command to remove the authorization policy:
```
kubectl delete authorizationpolicy productpage-viewer
```