Use HTTP to implement custom authorization and improve service access security - Alibaba Cloud Service Mesh

For fine-grained access control over services that communicate using HTTP, you can use a custom authorization service. This feature lets you customize authorization mechanisms based on specific business requirements. You can add an authentication process to inter-service communication to ensure that only authenticated and authorized requests can access service resources. This improves the security of communication between services. This topic uses the sleep and httpbin applications as examples to demonstrate how to connect to a custom authorization service over HTTP.

Prerequisites

You have added a cluster to an ASM instance.

Step 1: Deploy the custom authorization service

You can deploy a custom authorization service in an ACK cluster. The service must comply with the Istio custom authorization service interface specification. It supports the HTTP and gRPC protocols and implements custom authorization logic. The example service in this topic requires that requests include the x-ext-authz: allow request header to pass authentication.

Note

This topic provides an example of a custom authorization service. You can also use the code from this example to create your own service. For more information, see Custom Authorization.

Connect to the cluster using kubectl and create an ext-authz.yaml file that contains the following content.

For more information about how to connect to the cluster using kubectl, see Obtain the KubeConfig file of a cluster and use kubectl to connect to the cluster.

Click to expand ext-authz.yaml

# Copyright Istio Authors
#
#   Licensed under the Apache License, Version 2.0 (the "License");
#   you may not use this file except in compliance with the License.
#   You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#   Unless required by applicable law or agreed to in writing, software
#   distributed under the License is distributed on an "AS IS" BASIS,
#   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#   See the License for the specific language governing permissions and
#   limitations under the License.

# Example configurations for deploying ext-authz server separately in the mesh.

apiVersion: v1
kind: Service
metadata:
  name: ext-authz
  labels:
    app: ext-authz
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 8000
  - name: grpc
    port: 9000
    targetPort: 9000
  selector:
    app: ext-authz
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ext-authz
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ext-authz
  template:
    metadata:
      labels:
        app: ext-authz
    spec:
      containers:
      - image: istio/ext-authz:0.6
        imagePullPolicy: IfNotPresent
        name: ext-authz
        ports:
        - containerPort: 8000
        - containerPort: 9000
---

Run the following command to deploy the custom authorization service in the cluster.
```
kubectl apply -f ext-authz.yaml
```

Run the following command to check the pod deployment status.

kubectl get pod

Expected output:

NAME                         READY   STATUS    RESTARTS   AGE
ext-authz-6b5db88f86-2m7c6   2/2     Running   0          79m

Run the following command to verify that the application is working as expected.

kubectl logs "$(kubectl get pod -l app=ext-authz -n default -o jsonpath={.items..metadata.name})" -n default -c ext-authz

Expected output:

2023/12/20 08:15:39 Starting gRPC server at [::]:9000
2023/12/20 08:15:39 Starting HTTP server at [::]:8000

The output indicates that the application is working correctly and the custom authorization service is successfully deployed.

Obtain the HTTP port of the ext-authz authorization service.
1. Log on to the ACK console. In the navigation pane on the left, choose Clusters.
2. On the Clusters page, click the name of the target cluster. In the navigation pane on the left, choose Network > Services.
3. On the Services page, click ext-authz.
  In the Endpoint section, the HTTP port is 8000. The HTTP address of this service is ext-authz.default.svc.cluster.local:8000.

Step 2: Deploy the sample applications

Create a httpbin.yaml file that contains the following content.

Click to expand httpbin.yaml

# Copyright Istio Authors
#
#   Licensed under the Apache License, Version 2.0 (the "License");
#   you may not use this file except in compliance with the License.
#   You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#   Unless required by applicable law or agreed to in writing, software
#   distributed under the License is distributed on an "AS IS" BASIS,
#   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#   See the License for the specific language governing permissions and
#   limitations under the License.

##################################################################################################
# httpbin service
##################################################################################################
apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
    service: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      serviceAccountName: httpbin
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80

Run the following command to deploy the httpbin application in the cluster.
```
kubectl apply -f httpbin.yaml
```

Create a sleep.yaml file that contains the following content.

Click to expand sleep.yaml

# Copyright Istio Authors
#
#   Licensed under the Apache License, Version 2.0 (the "License");
#   you may not use this file except in compliance with the License.
#   You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#   Unless required by applicable law or agreed to in writing, software
#   distributed under the License is distributed on an "AS IS" BASIS,
#   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#   See the License for the specific language governing permissions and
#   limitations under the License.

##################################################################################################
# Sleep service
##################################################################################################
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
---

Run the following command to deploy the sleep application in the cluster.
```
kubectl apply -f sleep.yaml
```
Enable Waypoint for the httpbin Service. For more information, see Configure a Layer 7 authorization policy.

Step 3: Connect to the custom authorization service over HTTP

Declare the service deployed in Step 1 in Service Mesh to enable Service Mesh to use the service for authentication.

Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose Mesh Security Center > Custom Authorization Service. On the page that appears, click Define Custom Authorization Service.

On the Register Custom Authorization Service page, click the Custom authorization service (HTTP or gRPC protocol) implemented based on envoy.ext_authz tab, configure the parameters, and then click Create.

Type	Configuration item	Description
Required parameters	Protocol	The protocol of the custom authorization application. In this topic, select HTTP.
	Name	The name of the custom authorization service. In this topic, set this to `test4http`.
	Service Address	Enter the endpoint of the custom authorization application in the format `<Application Name>.<Namespace>.svc.<Cluster Domain>`. You must enter a fully qualified domain name (FQDN). In this topic, set this to `ext-authz.default.svc.cluster.local`.
	Port(1 - 65535)	Enter the service port of the custom authorization application. In this topic, set this to `8000`.
	Timeout(second)	If the authorization application does not return a response within this period, the authorization service is considered unavailable. In this topic, set this to `10` seconds.
Optional parameters	Skip authentication while authorization service is unavailable	Specifies whether to allow requests when the authorization service is unavailable. If you enable this option, requests are allowed when the service is unavailable. In this topic, this option is disabled.
	Error code returned by asm proxy while Auth-Service is not available	This option is available only when Skip authentication while authorization service is unavailable is disabled. If you enable this option, you must specify an error code. When the authorization service is unavailable, this error code is returned to the client. In this topic, this option is disabled.
	Carry origin header within auth request [includeRequestHeadersInCheck]	If you enable this option, you must specify the header keys to include. Matching headers are added to the request sent to the custom authorization service. In this topic, the configuration is shown in Figure 1. Include headers in authorization requests. Note This parameter can be set only when Protocol is set to HTTP.
	Add a header in the authentication request (if a header with the same name already exists, the original value will be overwritten) [includeAdditionalHeadersInCheck]	If you enable this option, you must specify the header keys and values to add to the authorization request. If a header with the same key already exists in the request, its value is overwritten. In this topic, this option is disabled. If you enable this option, you must specify the header keys and values to add to the authorization request. If a header already exists in the request, its value is overwritten. In this topic, this option is disabled. Note This parameter can be set only when Protocol is set to HTTP.
	Overwrite Header when authentication passes (overwrite Header in the request to the target service by using Header in the authentication request Response) [headersToUpstreamOnAllow]	If you enable this option, you must specify the header keys to overwrite. When custom authorization succeeds, matching headers from the response of the authorization service overwrite the headers in the request sent to the destination service. In this topic, the configuration is shown in Figure 2. Overwrite headers on successful authorization. Note This parameter can be set only when Protocol is set to HTTP.
	Overwrite Header when authentication fails (overwrite Header in Response using Header in authentication request Response) [headersToDownstreamOnDeny]	If you enable this option, you must specify the header keys to overwrite. When custom authorization fails, matching headers from the response of the authorization service overwrite the headers in the response sent back to the calling service. In this topic, the configuration is shown in Figure 3. Overwrite headers on failed authorization. Note This parameter can be set only when Protocol is set to HTTP.
	Carry origin request body within auth request	If you enable this option, you must specify the maximum length of the request body to include. If you also enable Allow send incomplete message to Auth-Service(HTTP 413 will be returned if request body size beyond limitation and this option is disabled) and the request body exceeds the specified maximum length, the body is truncated to that length before being sent to the authorization service.

Step 4: Define an authorization policy for services in the mesh

Create an authorization policy to configure the request operations that require authentication.

Create the httpbin-ext-authz.yaml file.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin-ext-authz
  namespace: default
spec:
  action: CUSTOM
  provider:
    name: httpextauth-test4http
  rules:
  - to:
    - operation:
        paths:
        - /headers
  targetRefs:
  - kind: Service
    name: httpbin

Deploy the authorization policy.
```
kubectl apply -f httpbin-ext-authz.yaml
```

Step 5: Verify the custom authorization between services

Run the following command to access httpbin.default:8000/ip.
```
kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- curl "http://httpbin.default:8000/ip" -s -o /dev/null -w "%{http_code}\n"
```
The command returns 200. This indicates that authentication is not triggered. The request is not subject to the policy because the access path is /ip and not /headers as defined in the authorization policy.

Run the following command to access httpbin.default:8000/headers with the x-ext-authz: deny request header.

kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -ndefault -- curl "http://httpbin.default:8000/headers" -H "x-ext-authz: deny" -s -i

Expected output:

HTTP/1.1 403 Forbidden
x-ext-authz-check-result: denied
content-length: 76
content-type: text/plain; charset=utf-8
date: Wed, 20 Dec 2023 09:53:28 GMT
server: envoy
x-envoy-upstream-service-time: 10

denied by ext_authz for not found header `x-ext-authz: allow` in the request

The output shows that authentication was triggered but failed. The response includes the newly defined x-ext-authz-check-result: denied header. The request is subject to the policy because the access path is /headers, as defined in the authorization policy.

Run the following command to access httpbin.default:8000/headers with the x-ext-authz: allow request header.

kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- curl "http://httpbin.default:8000/headers" -H "x-ext-authz: allow" -s

Expected output:

{
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.default:8000",
    "User-Agent": "curl/8.5.0",
    "X-Envoy-Attempt-Count": "1",
    "X-Ext-Authz": "allow",
    "X-Ext-Authz-Check-Result": "allowed",
    "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/default/sa/httpbin;Hash=c3e5364e87add0f4f69e6b0d029f5961b404c8f209bf9004b3d21a82cf67****;Subject=\"\";URI=spiffe://cluster.local/ns/default/sa/sleep"
  }
}

The output shows that authentication was triggered and passed. The response includes the newly defined "X-Ext-Authz-Check-Result": "allowed" header. The request is subject to the policy because the access path is /headers, as defined in the authorization policy.

Related operations

For information about how to develop a custom authorization service based on the HTTP protocol, see Develop a custom authorization service based on the HTTP protocol.
For information about how to develop a custom authorization service based on the gRPC protocol, see Develop a custom authorization service based on the gRPC protocol.
For fine-grained access control over services that communicate using gRPC, see Connect to a custom authorization service over gRPC.
To control authorization for services outside the mesh, see Control authorization for services in the mesh to access external websites and Control authorization for services in the mesh to access external databases.
You can enable the mesh audit feature to record or trace the daily operations of different users. You can also configure audit alerts for mesh resource operations. This sends alert notifications to alert contacts when important resources change. For more information, see Use KubeAPI operation audit and Configure audit alerts for mesh resource operations.