Use ASM to implement zero trust security - Alibaba Cloud Service Mesh

Zero trust is a security approach that eliminates implicit trust inside and outside a network perimeter. Service Mesh (ASM) implements zero trust security for cloud-native applications. It integrates identity authentication and authorization features that were previously written in the application code. The features are out-of-the-box. You can easily configure and update identity authentication and authorization policies based on your business needs, and the new policies immediately take effect. This topic describes why you need to use ASM to implement zero trust security and how to use the zero trust system in ASM.

Background information

The microservices architecture delivers various benefits such as scalability, agility, independent scaling, business logic isolation, independent lifecycle management, and easier distributed development. However, the distributed architecture of microservices poses greater security risks. This is because each microservice is an object that may be attacked. Kubernetes is a competent platform to host and orchestrate microservices. By default, microservices in a Kubernetes cluster communicate with each other by using HTTP requests in plaintext. However, the communication is not secure. Network perimeter-based security is not enough. If an internal microservice is intruded, attackers can take this single breach to access any number of services within your entire network. Therefore, communication over an internal network must also be secure. This is why zero trust is important. Zero trust security requires explicit authentication for all requests and applies the principle of least privilege to restrict access to resources.

A major benefit of the service mesh technology is that it protects the application deployment environment without reducing developer productivity. The service mesh technology can be used to enable zero trust security for your microservices, which helps you carry out security operations such as strict identity authentication, context-based authorization, monitoring, and recording for all access requests. You can also apply security control to all the applications that are added to service meshes, for example, all traffic is encrypted, and all traffic to the applications is authenticated by the policy enforcement point (PEP).

In addition to using Kubernetes network policies to control traffic at the network layer, which is Layer 3, ASM also provides peer authentication, request authentication, Istio authorization policies, and Open Policy Agent (OPA)-based fine-grained access control. ASM provides these zero trust security capabilities to help you achieve security goals.

The zero trust security system of ASM includes the following aspects:

Workload identity: This is the foundation of the zero trust security system. ASM provides an easy-to-use method to define the identity of each cloud-native workload. It also provides custom identity definition methods for specific scenarios. The identities are compliant with the Secure Production Identity Framework for Everyone (SPIFFE).
Security certificate: ASM issues certificates and provides certificate lifecycle management and rotation to implement zero trust security. ASM issues TLS X.509 certificates that contain identities and rotates the certificates and private keys. All proxies use the certificates.
Policy execution: Policies are essential to zero trust security. ASM supports Istio Role Based Access Control (RBAC) policies and OPA-based fine-grained authorization policies.
Observability and analysis: ASM allows you to observe the logs and metrics of policy execution, based on which you can analyze the effectiveness of each policy.

Why use ASM to implement zero trust security?

Compared with the traditional method of adding security mechanisms to the application code, ASM has the following benefits:

The lifecycles of sidecar proxies are independent of applications. Therefore, you can manage sidecar proxies with ease.
You can configure and update policies based on your business needs and the new policies take effect immediately. This way, you do not need to re-deploy applications.
The centralized control architecture of ASM allows the network security team of an enterprise to build, manage, and deploy security policies that are applicable throughout the enterprise. This ensures the security of all the business applications. The deployed security policies immediately take effect without requiring extra efforts of developers.
ASM provides capabilities, such as the JSON Web Token (JWT) feature, to authenticate user credentials in requests.
ASM allows you to deploy identity authentication and authorization systems as services in ASM instances. Like other services in ASM instances, these security systems also benefit from the security measures provided by ASM instances, such as in-transit encryption, identity authentication, PEP, and authentication and authorization of user credentials.

ASM allows you to use a single control plane to implement strict identity and access management, Transport Layer Security (TLS) encryption, identity authentication and authorization, and audit logging. ASM provides these features out of the box. Developers, system administrators, and network security teams can protect their microservice-oriented applications with ease.

How to use the zero trust system in ASM?

ASM reduces the attack surface in the cloud-native environment and provides a basic framework for building a zero trust application network. ASM adopts end-to-end encryption, service-level identity authentication, and fine-grained authorization policies to secure service-to-service communication.

ASM supports the following security measures:

Mutual TLS (mTLS) authentication or server-side TLS authentication is performed in a service interaction. Certificate lifecycle management such as automatic certificate rotation is supported. All communication sessions in ASM require identity authentication and are encrypted.
Identity-based authorization is enabled. Other authorization dimensions are also used. RBAC is used together with the principle of least privilege. Only authorized services can communicate with each other by following ALLOW or DENY rules.

ASM provides the following zero-trust security capabilities: workload identity, peer authentication, request authentication, authorization policies, and OPA policies.

Workload identity

An ASM instance assigns a unique identifier to each microservice that runs in the ASM instance. The microservice uses the identifier to communicate with other microservices in the same ASM instance. The identifier can be used in two-way authentication to allow or deny access to a service. The identifier can also be used in authorization policies.

When you use ASM to manage workloads that run in Kubernetes clusters, ASM assigns a service identity to each workload based on the service token of the workload.

Service identities in ASM comply with SPIFFE and are in the following format: spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>.

You can log on to the ASM console to view the workload identities of the services that reside in Kubernetes clusters in ASM.

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 > Workload Identity.
In the upper part of the Workload Identity page, select the ID of the desired cluster from the Data Plane drop-down list and select the desired namespace from the Namespace drop-down list to view the workload identities of the services that reside in the Kubernetes cluster in ASM.

Peer authentication

ASM provides two types of authentication: peer authentication and request authentication. Peer authentication can be performed by using mutual TLS authentication when two microservices interact with each other.

If sidecar proxies are injected into both the client and server, mTLS encryption is enabled for communications among services in ASM.
If only the client is injected with a sidecar proxy, the client enables mTLS encryption for communications based on the configurations of the server.
If only the server is injected with a sidecar proxy, the default mTLS mode is permissive, which indicates that the server can accept both plaintext and encrypted traffic. If you configure peer authentication for the server and set the mTLS mode to strict in this case, requests fail.

Request authentication

ASM provides two types of authentication: peer authentication and request authentication. ASM allows users and systems to interact with microservices by using request authentication. Generally, JWTs are used to authenticate requests.

You can create a request authentication policy for a microservice to implement JWT-based authentication for requests that come to the microservice. If a request contains a JWT, the request authentication policy is used to check whether the JWT is valid. The microservice can be accessed only if the JWT is valid. If a request does not contain a JWT, the request is not checked, and the microservice can be accessed by the request as expected.

Note

You can use an authorization policy and a request authentication policy to specify that the microservice can be accessed only if the requests contain a valid JWT. In this case, the requests that contain an invalid JWT or do not contain a JWT cannot access the microservice.

Deploy the Bookinfo application that receives the request. For more information, see Deploy an application in an ASM instance.

Deploy the sleep application that initiates the request.

Use kubectl to connect to the Container Service for Kubernetes (ACK) cluster based on the information in the kubeconfig file, and then create a sleep.yaml file.

Show the sleep.yaml file

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:
```
kubectl apply -f sleep.yaml -n default 
```

Create a request authentication policy that requires JWT authentication for all the requests to access the details service.
1. Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
2. On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose Mesh Security Center > RequestAuthentication. On the page that appears, click Create.
3. On the Create page, set the parameters shown in the following figure, define a JWT rule for the details workload, and then click Create.
  The following section describes some of the parameters:
  - issuer: the issuer of the JWT. In this example, this parameter is set to testing@asm.istio.io.
  - audiences: the audiences of the JWT. This parameter specifies the services that can use the JWT to access the desired service. In this example, no audience is specified, which indicates that all services can use the JWT to access the desired service.
  - jwks: the JWT request information. In this example, this parameter is set to the content shown in the following code block. For more information, see jwks.json.
```
{ "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}
```

Use a JWT tool to encode JWT request information into a JWT string.

{ "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

Expected JWT string after encoding:

eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg

Verify that the request authentication policy takes effect as expected.

Run the following command to access the details service by using the encoded JWT string:

export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg
kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}\n'

The value 200 is returned, which indicates that the details service is accessed as expected.

Run the following command to use an invalid JWT to access the details service:

kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer badtoken" -s -w '%{http_code}\n'

The value 403 is returned, which indicates that the details service fails to be accessed.

Run the following command to send a request that does not contain a JWT token to access the details service:
```
kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'
```
The value 200 is returned, which indicates that the details service is accessed as expected.
The preceding results indicate that a request can access the details service if the request contains a valid JWT or does not contain a JWT, and a request that contains an invalid JWT cannot access the details service. This indicates that the request authentication policy takes effect.

Authorization policies

You can create an authorization policy for a microservice to specify that only requests that meet specified requirements can access the microservice. For example, you can specify the port, IP address, and source of valid requests. For this example, use an authorization policy to specify that a request can access the destination service only if the request contains a JWT that is issued by the specified issuer.

Deploy the Bookinfo application that receives the request. For more information, see Deploy an application in an ASM instance.

Deploy the sleep application that initiates the request.

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

Show the sleep.yaml file

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
---

Use kubectl to connect to the ACK cluster based on the information in the kubeconfig file, and then run the following command to deploy the sleep service:
```
kubectl apply -f sleep.yaml -n default 
```

Create an authorization policy.
1. Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
2. On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose Mesh Security Center > AuthorizationPolicy. On the page that appears, click Create from YAML.

On the Create page, select default from the Namespace drop-down list, copy the following YAML code into the code editor, and then click Create.

For more information about the fields in the YAML code, see Authorization Policy.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            requestPrincipals:
              - testing@secure.istio.io/testing@secure.istio.io
  selector:
    matchLabels:
      app: details

Run the following command to send a request that does not contain a JWT to access the details service:
```
 kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'
```
Expected output:
```
403
```
The request that does not contain a JWT fails to access the details service, which indicates that the authorization policy takes effect as expected. The authorization policy specifies that requests can access the destination service only if the requests contain JWTs that are issued by testing@secure.istio.io.

OPA policies

OPA is a general-purpose policy engine that enables fine-grained access control for your applications. You can deploy OPA as a standalone service along with microservices. To protect an application, make sure that each request to a microservice of the application is authorized before the request is processed. The microservice makes an API call to OPA to check whether the request is authorized. For more information, visit OPA.

ASM integrates with OPA. You can use OPA to define access control policies to implement fine-grained access control on your applications. You can also dynamically update these policies. For more information, see Dynamically update OPA policies in ASM.

Summary and examples

In summary, ASM provides the following security-enhancing components:

Infrastructure that offers full lifecycle management of certificates, which simplifies certificate issuing and CA certificate rotation.
Managed control plane APIs that distribute identity authentication policies, authorization policies, and security naming information to Envoy proxies.
Sidecar proxies that use PEP to ensure the security of ASM instances.
Envoy extensions that allow telemetry data collection and auditing.

Each workload has a TLS X.509 certificate that contains an identity. Each sidecar proxy uses this certificate. ASM provides the certificates and periodically rotates the certificates and private keys. If a private key is stolen, ASM replaces it with a new private key immediately. This reduces the attack surface.

Examples

Authorization policies are added to the ingress gateway to implement IP-based access control or access control based on custom external authorization.
An Internet finance customer wants to implement access control on cross-region multi-language applications. ASM provides the customer authorization policies to protect applications from external networks. ASM also audits egress traffic by using the egress gateway. The egress traffic audit and authorization policies control the access of applications to third-party services.