Cloud-Native Operation and Maintenance Technology: Enhance Application Security in ASM with the “Zero-Trust Concept” and OPA

By Lishan

Distributed microservice applications have a higher complexity for deployment and management and expand its security attack area. In the traditional three-layer architecture, security protection is mainly in north-south traffic, while in the microservices model, east-west traffic protection will encounter greater challenges. With traditional bound protection, if an application is attacked due to security flaws, there is a lack of security control mechanism used to prevent internal threats from horizontal movement. Zero-trust was first proposed by Forrester around 2010. Zero-trust security assumes everything is a threat. If you do not trust anyone, any device, or any application inside and outside the network, you need to reconstruct the trust foundation of the access control based on authentication and authorization and guide the security architecture from network centralization to identity centralization. Instead of trusting the traditional network bound protection, zero-trust replaces it with micro-bound protection.

Microservices communicate with each other using HTTP requests in plaintext. However, the communication is not secure. If an internal microservice is intruded, border security measures are all for nothing, much like the Maginot Line. Attackers can take the machine on which the intruded microservice runs as a stepping stone to attack the internal network. Zero-trust is a security system that requires explicit authentication for all requests and applies the principle of least privilege to restrict access to resources. This topic shows you how to use resources, such as workload identities, peer authentication policies, and request authentication policies, to build a zero-trust security system and improve application security in Alibaba Cloud Service Mesh (ASM).

Background Information

Microservices deliver various benefits, such as scalability, agility, independent scaling, business logic isolation, independent lifecycle management, and easier distributed development. However, a large number of distributed microservices increase security risks because each microservice is an object that may be attacked. If an internal microservice is intruded, attackers can take the machine on which the intruded microservice runs as a stepping stone to attack the internal network.

ASM reduces the attack surface in the cloud-native environment and provides a basic framework for building a zero-trust application network. ASM also provides peer authentication policies, request authentication policies, Istio authorization policies, and Open Policy Agent (OPA)-based fine-grained access control policies. ASM allows you to implement end-to-end service encryption, service-level identity authentication, and fine-grained authorization policies. This ensures service-to-service security and achieves security objectives (such as strong identity authentication) for all requests and context-based authorization.

The zero-trust security system of ASM provides the following benefits compared with traditional security systems' built-in application code:

The lifecycle of the policies attached to ASM sidecar proxies is independent of applications. This helps you manage the sidecar proxies with ease.
ASM supports a dynamic configuration of policies, which makes it easier to update policies. Updated policies immediately take effect without requiring you to redeploy applications.
ASM provides capabilities, such as JSON Web Token (JWT), to authenticate user credentials in requests.
The centralized control architecture of ASM allows the security team of an enterprise to build, manage, and deploy security policies that are applicable throughout the enterprise. This ensures the security of business applications built by application developers. The deployed security policies immediately take effect without requiring extra effort.
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 encrypted transmission, identity authentication, policy enforcement point (PEP), and authentication and authorization of user credentials.

Two Detailed Examples Show How to Implement Fine-Grained Permission Control through ASM

Use a Peer Authentication Policy to Implement mTLS Encryption

When two microservices communicate with each other, you can use a peer authentication policy to implement mutual Transport Layer Security (mTLS) encryption for communication between the two microservices.

1. Deploy an application in an ASM instance.

2. Run the following command to access the details service by sending an HTTP request in plaintext:

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:

The details service can be accessed using TLS-secured HTTP requests or HTTP requests in plaintext by default. Access the pods of the productpage service by sending an HTTP request in plaintext. If a value of 200 is returned, the service is accessed as expected.

3. Implement mTLS encryption for the communication with the details service:

Log on to the ASM console
Choose Service Mesh > Mesh Management on the left-side navigation pane
On the Mesh Management page, find the ASM instance you want to configure. Click the name of the ASM instance or click Manage in the Actions column
On the details page of the ASM instance, choose Zero Trust Security > PeerAuthentication on the left-side navigation pane. On the PeerAuthentication page, click Create mTLS Mode
On the Create mTLS Mode page, set the parameters described in the following table and click Create

Parameter	Description
Namespace	The name of the namespace to which the peer authentication policy belongs
Name	The name of the peer authentication policy
mTLS Mode (Namespace-wide)	The mTLS mode: Select STRICT - Strictly Enforce mTLS from the drop-down list
Workload Label Selection	Specifies whether to enable workload label selection. Turn on Workload Label Selection, click Add Matching Label, and add a label with the name of the app and the value of the details

Run the following command to access the details service by sending an HTTP request in plaintext again:

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 preceding results indicate that the details service fails to be accessed using an HTTP request in plaintext. After you create a peer authentication policy for a service, the service can only be accessed if the corresponding requests are authenticated by the TLS certificate. Otherwise, the service cannot be accessed.

Use a Request Authentication Policy to Implement JWT-Based Authentication

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 only be accessed 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 only be accessed if the requests contain a valid JWT. In this case, requests that contain an invalid JWT or do not contain a JWT cannot access the microservice.

1. Deploy an application in an ASM instance

2. Log on to the ASM console

3. Choose Service Mesh > Mesh Management on the left-side navigation pane

4. On the Mesh Management page, find the ASM instance that you want to configure

5. Click the name of the ASM instance or click Manage in the Actions column

6. On the details page of the ASM instance, choose Zero Trust Security > RequestAuthentication on the left-side navigation pane. On the RequestAuthentication page, click Create.

7. On the Create page, set the parameters described in the following table and click Create.

Parameter	Description
Namespace	The name of the namespace to which the request authentication policy belongs. In this example, select default.
Name	The name of the request authentication policy.
Matching Label	The label that is used to specify the service to which the request authentication policy applies. In this example, specify the details of the service. Click Add Matching Label and add a label with the name of the app and the value of the details
JWT Rule Set	The JWT rules. Click Add next to JWT Rule Set and set the following parameters: • issuer: The issuer of the JWT. In this example, set this parameter to testing@secure.istio.io. • audiences: The audiences of the JWT. This parameter specifies the services that can use the JWT to access the destination service. If you do not set this parameter, all services can access the destination service. • jwks: The JWT request information. In this example, set this parameter to the following content: `null`

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

null

Expected JWT string after encoding:

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

9. Verify that the request authentication policy takes effect as expected.

Send a request that contains the encoded JWT to access the details service

export
TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_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:

A value of 200 is returned, which indicates the details service is accessed as expected.

Send a request that contains an invalid JWT 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 --header "Authorization: Bearer badtoken" -s -w '%{http_code}\n'

Expected output:

A value of 403 is returned, which indicates the details service fails to be accessed.

Send a request that does not contain a JWT 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:

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

10. 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 as expected.

Use an Authorization Policy to Authenticate the Sources of Requests

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. In this example, use an authorization policy to specify that a request can only access the destination service if the request contains a JWT issued by the specified issuer.

1. Deploy an application in an ASM instance

2. Log on to the ASM console

3. Choose Service Mesh > Mesh Management on the left-side navigation pane

4. On the Mesh Management page, find the ASM instance you want to configure. Click the name of the ASM instance or click Manage in the Actions column

5. On the details page of the ASM instance, choose Zero Trust Security > AuthorizationPolicy on the left-side navigation pane. On the AuthorizationPolicy page, click Create

6. On the Create page, set the parameters that are described in the following table and click Create

Parameter	Description
Namespace	The name of the namespace to which the authorization policy belongs. In this example, select default.
Name	The name of the authorization policy
Policies	The policy. In this example, select RULES.
Workload Label Selection	Specifies whether to enable workload label selection. Turn on Workload Label Selection, click Add Matching Label, and then add a label with the name of the app and the value of details.
Action	The action on requests that meet specified requirements. In this example, select ALLOW.
Request Source	Specifies whether to authenticate the sources of requests. Turn on Request Source, click Add Request Source to List, and then click Add Request Source. Then, select requestPrincipals from the Request Source Domain drop-down list and set the Value parameter to testing@secure.istio.io/testing@secure.istio.io.

7. 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=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:

The request that does not contain a JWT fails to access the details service, which indicates the authorization policy takes effect as expected. The authorization policy restricts that a request can only access the details service if the request contains a JWT issued by testing@secure.istio.io.

Summary

This series focuses on the inner workings of CloudOps, DevOps, SecOps, AIOps, and FinOps and how it relates to End-to-End Cloud-Native Application Management, which enables efficient, secure, and transparent container management. Learn more by visiting the landing page and be sure to check the other articles in this series!

Community

Cloud-Native Operation and Maintenance Technology: Enhance Application Security in ASM with the “Zero-Trust Concept” and OPA

Background Information

Two Detailed Examples Show How to Implement Fine-Grained Permission Control through ASM

Use a Peer Authentication Policy to Implement mTLS Encryption

Use a Request Authentication Policy to Implement JWT-Based Authentication

Use an Authorization Policy to Authenticate the Sources of Requests

Summary

Read previous post:

Read next post:

Alibaba Cloud Community

You may also like

Comments

Alibaba Cloud Community

Related Products

Microservices Engine (MSE)

Security Solution

Security Overview

HTTPDNS