Alibaba Cloud Service Mesh (ASM) Helps Achieve Zero Trust and Enhance Application Service Security

By Xining Wang and Qifang

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. Kubernetes provides an excellent platform for managing and orchestrating your microservices. However, all interactions between microservices are not secure enough by default. They communicate over plain text HTTP, which is not enough to meet security requirements. It is not enough to rely on the network boundary to ensure security. Once an internal service is compromised, the boundary security method is easily broken through, which can be used as the springboard to attack the internal network. Therefore, internal calls must be secure, which is where zero trust comes into play.

Zero trust (proposed by Forrester analyst John Kindervag) means there is no implicit trust, whether inside or outside the network boundary. In other words, explicit authentication is required everywhere, and the principle of least privilege is used to control access to resources.

An important value of service mesh technology is that it can effectively protect the application's production environment without reducing developers' productivity. Through service mesh technology, it provides the necessary foundation for the microservice architecture to adopt a zero trust network security method to achieve the security goals of strong authentication, context-based authorization, record monitoring, etc. These mesh features can provide security control capabilities for all applications that belong to the mesh. For example, all traffic is encrypted, and all traffic to the application is verified by the policy enforcement point (PEP).

Alibaba Cloud Service Mesh has become one of the important carriers of landing cloud-native zero trust systems. It offloads authentication and authorization from application codes to the service mesh, which is out-of-the-box and dynamically configurable and makes the update strategy easier with immediate effect. In addition to using Kubernetes Network Policy to implement three-tier network security control, ASM provides peer identity authentication and request identity authentication, Istio authorization policies, and more refined OPA-based policy control capabilities. These zero trust security capabilities provided by ASM help users achieve the preceding security goals.

The theoretical system for building ASM capabilities includes the following aspects:

Zero Trust Foundation – Workload Identity: How can you provide a unified identity for cloud-native workloads? ASM provides a simple and easy-to-use identity definition for each workload under the service mesh and provides a customized mechanism for extending the identity construction system according to specific scenarios. Meanwhile, they are compatible with the community SPIFFE standard.
Zero Trust Carrier – Security Certificate: ASM provides mechanisms such as how to issue certificates and manage the lifecycle and rotation of certificates. Identity is established through X509 TLS certificates, which are used by each agent. Certificate and private key rotation are also provided.
Zero Trust Engine – Policy Execution: The policy-based trust engine is the key to building zero trust. In addition to supporting Istio RBAC authorization policies, ASM provides fine-grained authorization policies based on OPA.
Zero Trust Insight – Visualization and Analysis: ASM provides observable mechanisms for monitoring the logs and indicators of policy execution to judge the implementation of each policy.

Why Do We Use Service Mesh to Achieve Zero Trust?

Compared with the traditional method of building security mechanisms directly in application code, the service mesh architecture has the following security benefits:

The lifecycle by sidecar proxy is independent of applications, which makes it easier to manage the Sidecar proxies.
ASM supports dynamic configuration, which makes it easier to update policies with immediate effect and without the need to redeploy applications.
The centralized control architecture of ASM allows the security team of an enterprise to build, manage, and deploy security policies that apply throughout the enterprise. This ensures the security of business applications built by application developers by default. The security policies immediately take effect without extra effort.
ASM provides capabilities, such as JSON Web Token (JWT), to authenticate user credentials in requests.
In addition, service mesh architecture allows the authentication and authorization system to be deployed in the mesh as services. Like other services in the mesh, these security systems also benefit from the security measures, such as encryption in the transmission, identity authentication, policy enforcement point (PEP), and authentication and authorization of user credentials.

With ASM, you can use a single control panel to implement powerful identity and access management, transparent TLS and encryption, authentication and authorization, and audit log entry. ASM provides these features out of the box. The simplicity of installment and management allows developers, system administrators, and security teams to protect their microservice programs properly.

Zero Trust System in ASM

ASM reduces the attacks in the cloud-native environment and provides a basic framework for building a zero trust application network. Through ASM management service to service security, it ensures service mesh end-to-end encryption, service-level identity authentication, and fine-grained authorization policies.

Under the service mesh system, it can:

Implement two-way TLS authentication or server-oriented TLS authentication between services and support lifecycle management such as automatic certificate rotation. Communications within the mesh are authenticated and encrypted.
Enable fine-grained identity-based authorization and other dimension parameters-based ones. Based on RBAC, the minimum privilege is supported; only authorized services can communicate with each other according to ALLOW/DENY rules.

Currently, ASM provides the following basic zero trust security capabilities:

1. Workload Identity

The service mesh assigns a unique identifier to each service when the program is running in the service mesh environment. This identifier is used when connecting to other microservices in the service mesh. The service identifier can be used for two-way service authentication to verify whether to allow access between services. It can also be used in authorization policies.

When using ASM to manage workloads running on Kubernetes or define virtual machine workloads based on WorkloadEntry, ASM provides a service identity for each workload. This identity is implemented based on the workload's service account token.

Service identities in ASM comply with the SPIFFE standard and have the following format:

spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>

In the ASM console, open the corresponding ASM instance. In the left-side navigation pane, you can view the following workload identity under zero trust security.

Workloads under the Kubernetes cluster in the data plane and their identity definitions:

Define virtual machine workloads and their identities based on WorkloadEntry:

2. Peer Authentication

Authentication refers to identity. What is this service? Who is this end user? Can I believe they are the same as what they say?

ASM provides two types of authentication:

Peer Authentication: When two microservices interact with each other, enable or disable two-way TLS for peer authentication.
Request Authentication: It allows end users and systems to interact with microservices using request authentication. This operation is usually performed using JWT.

Follow the Getting Started guide to install and deploy the bookinfo example.

First, when trying to access the details service using pure-HTTP from a productpage pod in the same namespace (for example, default in this example), the request should be returned in the status 200 by default because both TLS and plain text traffic can be accepted by 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'

Next, define peer authentication under the namespace default.

In the ASM console, open the corresponding ASM instance. In the left-side navigation pane, you can view the following peer authentication under zero-trust security. On the right-side page, click Create Two-way mTLS Mode* to define the mTLS mode as STRICT for workload details.

Use pure-HTTP with productpage pod 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'
000
command terminated with exit code 56

The exit code 56 indicates that the network data failed to be received. This is as expected. Workload details define the mTLS mode as STRICT, so TLS certificate authentication is required in each request.

To allow normal access, you can change from STRICT to PERMISSIVE through the peer authentication defined above. The corresponding YAML definition is listed below:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: details-strict
  namespace: default
spec:
  mtls:
    mode: PERMISSIVE
  selector:
    matchLabels:
      app: details

3. Request Authentication

First, we will create a request authentication policy to enforce JWT authentication for inbound requests from the details service. In the ASM console, open the corresponding ASM instance. In the left-side navigation pane, you can view the following request authentication under zero-trust security. On the right page, click the Create button to define JWT rules for workload details.

The issuer value is set to testing@secure.istio.io,

The value of jwks is taken from the https://raw.githubusercontent.com/istio/istio/release-1.9/security/tools/jwt/samples/jwks.json:

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

Then, when you try to use pure-HTTP in the productpage pod to access the details service, you can see that the returned result is 200.

Set the TOKEN value of the variable to:

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

If an invalid token is passed, we should see a "401: Unauthorized" response:

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

However, if we don't pass tokens at all, RequestAuthentication doesn't invoke the policy. Requests that do not use JWT tokens also return 200.

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

Therefore, in addition to this authentication policy, we need an authorization policy that requires JWT for all requests. The next section describes how to define authorization policies in ASM.

4. Authorization Policies

ASM provides authorization policies. You can use AuthorizationPolicy resources to activate the authorization mechanism between microservices and use the following content to establish an appropriate traffic authorization policy mechanism:

Select the selector field for workload tags to specify the policy target.
The action field specifies whether the request is ALLOW or DENY. If you do not specify an operation, the operation is set to ALLOW by default. We recommend always specifying an operation. (The authorization policy also supports AUDIT and CUSTOM operations.)
Rules specify when the operation is triggered.
The from field in rules specifies the source of the request.
The to field in rules specifies the requested operation.
The when field specifies other conditions that need to be met to apply the rule.

The corresponding YAML definition is listed below:

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

Again, if you do not use JWT Token to send requests, you should now see 403 - Forbidden. This is the case when AuthorizationPolicy takes effect. All frontend requests must have a JWT Token.

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

5. OPA Policies

OPA is a graduated project of the Cloud Native Computing Foundation (CNCF). As a policy engine, OPA can be used to implement fine-grained access control on your applications. You can deploy OPA as a standalone service along with microservices. If you want to protect an application, make sure each request for a microservice is authorized before the request is processed. The microservice makes an API call to OPA to decide whether the request is authorized.

ASM integrates with the OPA plugin. You can use OPA to define access control policies to implement fine-grained access control on your applications. It supports dynamic OPA policy updates.

Please refer to this link for details.

Summary and Cases

In summary, ASM offers the following components to enhance security:

Provide a managed certificate infrastructure with the complete certificate lifecycle management, addressing the complexity of certificate issuance and CA rotation
Managed control plane API for distributing authentication policies, authorization policies, and security naming information to Envoy agents
The Sidecar agent helps ensure the security of the mesh by providing PEP.
Envoy agent extension allows telemetry data collection and auditing.

Each workload establishes an identity through an X509 TLS certificate, which is used by each Sidecar agent. ASM provides and periodically rotates the certificate and private key. If a particular private key is stolen, service mesh will replace it with a new private key to reduce the attacks.

References

1. Use authorization policies to implement IP-based RAM on the ingress gateway (please see this link) or RAM based on custom external authorization. The following figure shows the implementation of ASM-based gateway authorization policies for a cloud product.

2. An internet finance customer uses the authorization policy provided by ASM to isolate outbound regions and application regions in terms of access control for cross-cluster multi-language applications. At the same time, it can be combined with the egress gateway to audit the mesh traffic. With the authorization policy, it can also control the access permissions of applications to third-party services.

Community

Alibaba Cloud Service Mesh (ASM) Helps Achieve Zero Trust and Enhance Application Service Security

Why Do We Use Service Mesh to Achieve Zero Trust?

Zero Trust System in ASM

1. Workload Identity

2. Peer Authentication

3. Request Authentication

4. Authorization Policies

5. OPA Policies

Summary and Cases

References

Read previous post:

Read next post:

Alibaba Cloud Native

You may also like

Comments

Dikky Ryan Pratama May 30, 2023 at 2:53 am

Alibaba Cloud Native

Related Products

Container Service for Kubernetes

Microservices Engine (MSE)

Security Solution

Security Overview