ASM helps realize zero trust

Microservices provide many values, including scalability, agility, independent scaling, isolation of business logic, independent lifecycle management, and easier distributed development. However, these distributed microservices also increase security challenges, and each microservice is a target of attack. Kubernetes provides an excellent platform for hosting and orchestrating your microservices. However, all interactions between microservices are insecure by default. They communicate over plain text HTTP, but this is not sufficient for security requirements. It is not enough to rely only on the network border to ensure security, because once a certain internal service is compromised, the border security means are like the Maginot Line of Defense, and the attacker can use the machine as a springboard to attack the intranet. Therefore, internal calls must also be secure, and this is where zero trust comes in.

Zero trust was proposed by Forrester analyst John Kindervag, which means that there is no implicit trust at all, whether inside or outside the network boundary. In other words, require explicit authentication everywhere, and use the principle of least privilege to limit access to resources.

An important value proposition of service mesh technology is how effectively it can secure an application's production environment without compromising developer productivity. Through the service grid technology, the microservice architecture adopts the zero-trust network security method to provide the necessary foundation, so as to achieve security goals such as strong authentication of all access, context-based authorization, and record monitoring. Using these mesh capabilities, you can provide security controls to all applications that belong to the mesh, such as all traffic is encrypted, all traffic to the application is authenticated by a Policy Enforcement Point (PEP), etc.

The "Kubernetes Hardening Guidance" issued by the US National Security Agency (NSA) in August 2021 also mentioned that administrators should consider using a service mesh to strengthen the security of Kubernetes clusters.

Alibaba Cloud Service Mesh ASM (https://www.aliyun.com/product/servicemesh) has become one of the important carriers for implementing the cloud-native zero-trust system. It offloads authentication and authorization from the application code to the service mesh, opening Out-of-the-box, dynamically configurable, and easier to update policies with immediate effect. On top of using Kubernetes Network Policy to implement three-tier network security control, the service grid ASM provides policy control based on OPA (Open Policy Agent) including peer identity and request identity authentication capabilities, Istio authorization policies, and more refined management ability. These zero-trust security capabilities provided by Alibaba Cloud Service Grid ASM help users achieve the above security goals.

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

• 1) The foundation of zero trust - workload identity, how to provide a unified identity for cloud-native workloads; ASM products provide easy-to-use identity definitions for each workload under the service grid, and provide customization mechanisms according to specific scenarios It is used to expand the identity construction system and is compatible with the community SPIFFE standard;
• 2) The carrier of zero trust - security certificates, ASM products provide how to issue certificates and manage the life cycle and rotation of certificates, and establish identities through X509 TLS certificates, which are used by each agent. And provide certificate and private key rotation;
• 3) Zero trust engine - policy execution, policy-based trust engine is the key core of building zero trust, ASM products not only support Istio RBAC authorization strategy, but also provide more fine-grained authorization strategy based on OPA;
• 4) Zero trust insights - visualization and analysis, ASM products provide observable mechanisms for monitoring logs and indicators of policy execution, to judge the execution of each policy, etc.;

Why Use a Service Mesh for Zero Trust?

Compared to the traditional approach of building these security mechanisms directly in application code, a service mesh architecture offers several security benefits:
• The lifecycle of sidecar proxies is kept independent from the application, so these sidecar proxies can be managed more easily.
• Allowing dynamic configuration, it becomes easier to update policies, and updates take effect immediately without redeploying the application.
• The centralized control architecture of the service mesh enables an enterprise's security team to build, manage, and deploy security policies that apply across the enterprise, making business applications built by application developers secure by default. They can immediately use these security policies with no extra work.
• The service mesh provides the ability to authenticate end-user credentials attached to requests as JWT.
• Additionally, using a service mesh architecture, authentication and authorization systems can be deployed as services in the mesh. In this way, like other services in the grid, these security systems receive security guarantees from the grid itself, including encryption in transit, identification, policy enforcement points, authentication and authorization of end-user credentials, and so on.

With Alibaba Cloud Service Mesh ASM, a single control plane can be used to implement strong identity and access management, transparent TLS and encryption, authentication and authorization, and audit logging. Alibaba Cloud Service Mesh ASM provides these capabilities out of the box, and the simplicity of installing and managing it allows developers, system administrators, and security teams to properly secure their microservice applications.

Zero Trust System in ASM

A service mesh can reduce the attack surface in a cloud-native environment and provide the basic framework required for a zero-trust application network. Manage service-to-service security through ASM to ensure end-to-end encryption, service-level authentication, and fine-grained authorization policies for the service grid.

Under the service grid system, it can support:

• Implement two-way TLS authentication between services or TLS authentication for the server side, and support life cycle management such as automatic rotation of certificates. Communications within the mesh are authenticated and encrypted.
• Enable fine-grained authorization based on identity, as well as authorization based on other dimension parameters. The foundation of role-based access control (RBAC), which supports the "least privilege" stance, that is, only authorized services can communicate with each other according to ALLOW/DENY rules.

Currently, Alibaba Cloud Service Grid ASM provides the following basic zero-trust security capabilities:

1. Workload Identity

When an application runs in a service mesh environment, the service mesh provides each service with a unique identity. This identity will be used when connecting to other microservices running in the service mesh. The service ID can be used for two-way authentication of services to verify whether access between services is allowed, and the service ID can also be used in authorization policies.

When using service mesh ASM to manage workloads running on Kubernetes or to 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 are SPIFFE compliant and have the following format:
spiffe:///ns//sa/

On the service grid ASM console, open the corresponding ASM instance, and you can see the following workload identity under zero trust security in the left navigation bar.

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

Define the virtual machine workload and its identity definition based on WorkloadEntry:

2. Peer Authentication

Authentication refers to identity: who is this service? Who is this end user? Can I believe they are who they say they are?
ASM products provide two types of authentication:
- Peer Authentication - Whether to enable or disable mutual TLS for peer authentication when two microservices interact with each other.
- Request Authentication - Allows end users and systems to interact with microservices using request authentication. This is usually done using JSON Web Tokens (JWT).

Follow the getting started guide (https://help.aliyun.com/document_detail/149552.html) to install and deploy the bookinfo example.

First, when trying to access the details service using plain HTTP from the productpage pod in the same namespace (e.g. default in this example), the request should return successfully with status 200 by default.

Next, peer authentication is defined under the namespace default.
On the service grid ASM console, open the corresponding ASM instance, and you can see the following peer-to-peer identity authentication under zero trust security in the left navigation bar. On the right page, click the "New Bidirectional mTLS Mode" button, and define the mTLS mode as STRICT for the workload details.

Exit code 56 indicates failure to receive network data. This is as expected. The workload details defines the mTLS mode as STRICT, which requires TLS certificate authentication in each request.

In order to allow normal access, peer authentication as defined above can be modified from STRICT to PERMISSIVE.

3. Request authentication

First, we'll create a request authentication policy to enforce JWT authentication on inbound requests to the details service. On the service grid ASM console, open the corresponding ASM instance, and in the left navigation bar, you can see the request identity authentication under zero trust security as follows. On the right page, click the "New" button to define jwt rules for workload details.

Next, when trying to use the productpage pod to access the details service using pure HTTP, you can see that the return result is 200.

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

However, if we don't pass a token at all, RequestAuthentication doesn't call the strategy. Requests that do not use JWT Token also return 200.

So, in addition to this authentication strategy, we need an authorization strategy that requires a JWT for all requests. The next section will describe how to define authorization policies in ASM products.

4. Authorization Policy

ASM products provide authorization policies, which can use the AuthorizationPolicy resource to activate the authorization mechanism between microservices, and use the following content to establish an appropriate traffic authorization policy mechanism:
• The selector field of the workload label specifies the policy target;
• The action field specifies whether it is an ALLOW or DENY request. If you do not specify an action, the action defaults to ALLOW. For clarity, we recommend that you always specify the action. (Authorization policies also support AUDIT and CUSTOM operations);
• rules specify when actions are triggered:
• The from field in rules specifies the source of the request;
• The to field in rules specifies the requested action;
• when field specifies other conditions that need to be met in order to apply the rule;

Send the request again without using the JWT Token, you should now see 403 - Forbidden. This is when AuthorizationPolicy takes effect, and all front-end requests must have a JWT Token.

5. OPA strategy

An incubating project hosted by CNCF, Open Policy Agent (OPA) is a policy engine that can be used to implement fine-grained access control for your applications. OPA, as a general-purpose policy engine, can be deployed as an independent service together with microservices. To secure applications, every request to a microservice must be authorized before it can be processed. To check authorization, the microservice makes an API call to OPA to determine if the request is authorized.

The service grid ASM integrates the Open Policy Agent (OPA) plug-in, defines access control policies through OPA, enables your application to implement fine-grained access control, and supports dynamic update of OPA policies.
For details, please refer to https://help.aliyun.com/document_detail/277428.html

Summary and Reference Cases
In summary, service mesh ASM provides the following components for enhanced security:

• Provides a managed certificate infrastructure with complete certificate lifecycle management, addressing the complexities of certificate issuance and CA rotation;
• Managed control plane API for distributing authentication policies, authorization policies and secure naming information to Envoy proxies;
• Sidecar proxies help secure the mesh by providing a Policy Enforcement Point (PEP);
• Envoy proxy extensions allow telemetry data collection and auditing;

Each workload establishes its identity through an X509 TLS certificate, which is used by each sidecar proxy. Service mesh ASM provides and periodically rotates certificates and private keys. If a particular private key is compromised, the service mesh will quickly replace it with a new one, greatly reducing the attack surface