Overview of 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 base 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 microservice 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 to 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, 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 or define a non-Kubernetes workload such as a VM by using WorkloadEntry, 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>.

Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management. On the Mesh Management page, click the ASM instance that you want to configure. On the details page of the ASM instance, choose Mesh Security Center > Workload Identity in the left-side navigation pane.

Workloads and their identities in a Kubernetes cluster on the data plane
WorkloadEntry-defined VMs and their identities

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. The following steps show you how to configure peer authentication:

Deploy the Bookinfo application. For more information, see Get started.
Run the following command to access the details service over HTTP from the productpage pod that is in the same namespace as the details service. In this example, the namespace is default.
```
kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'
```
The expected status code is status 200, which indicates that the access is successful. This is because both plaintext traffic and TLS traffic are allowed by default.
Configure peer authentication in the default namespace.
1. Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management. On the Mesh Management page, click the ASM instance that you want to configure. On the details page of the ASM instance, choose Mesh Security Center > PeerAuthentication in the left-side navigation pane. On the page that appears, click Create mTLS Mode. Then, set the namespace-level mTLS mode of the details workload to strict and click Create.
2. Run the following command to access the details service over HTTP from the productpage pod that is in the same namespace as the details service. In this example, the namespace is default.
```
kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'
```
  Expected output:
```
000
command terminated with exit code 56
```
  The error code 56 is returned, which indicates failure to get network data. The result meets expectations. Because the mTLS mode of the details workload is set to strict, every request to access the details workload requires TLS certificate authentication.
To allow the access request, set mTLS Mode (Namespace-wide) to PERMISSIVE - Enable Plaintext TLS or mTLS that supports plaintext traffic or traffic authenticated by using mTLS. After the operation, the peer authentication mode is changed from strict to permissive. The following YAML file provides an example of how to set the peer authentication mode:
```
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: details-strict
  namespace: default
spec:
  mtls:
    mode: PERMISSIVE
  selector:
    matchLabels:
      app: details
```

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. The following steps show you how to configure request authentication:

Deploy the Bookinfo application. For more information, see Get started.
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. On the Mesh Management page, click the ASM instance that you want to configure. On the details page of the ASM instance, choose Mesh Security Center > RequestAuthentication in the left-side navigation pane.
2. On the page that appears, click Create to create a JWT rule for the details workload.
  - issuer: the issuer of the JWT. In this example, this parameter is set to testing@secure.istio.io.
  - jwks: The JSON Web Key Set that is needed to verify the JWT. For the value, click jwks.json.
3. Click Create.

Run the following command to access the details service over HTTP from the productpage pod that is in the same namespace as the details service. In this example, the namespace is default. Replace the TOKEN value with the actual value.

export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7ig****YGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcy****NCU4KRnemRIMHVOfuvHsU60_Gh****zgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg

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

Expected output:

If an invalid token is used, the status code 401 is returned.

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

401

If no token is used, the request authentication policy is not invoked. Therefore, the status code 200 is returned for requests that have no JWT tokens.

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

200

Authorization policies

ASM allows you to configure authorization policies to authorize microservice interactions.

Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management. On the Mesh Management page, click the ASM instance that you want to configure. On the details page of the ASM instance, choose Mesh Security Center > AuthorizationPolicy in the left-side navigation pane.

Create an authorization policy.

Method 1: On the page that appears, click Create. On the Create page, set the parameters and click Create.

Method 2: On the page that appears, click Create from YAML. The following YAML file provides an example:

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

Parameter	Description
`selector`	Specifies the workload to which the policy applies.
`action`	Specifies whether to allow or deny requests. If you do not specify this parameter, requests are allowed by default. We recommend that you specify this parameter. In addition, audit and custom actions are supported.
`rules`	Specifies when the action is triggered.
`rules.from`	Specifies the source of requests.
`rules.to`	Specifies the request operation.
`when`	Specifies other conditions that need to be met to apply the rule.

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=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'
```
Expected output:
```
403
```
The status code 403 is returned, which indicates that the authorization policy takes effect. A request must have a JWT token to be allowed.

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.