Dubbo provides a comprehensive mechanism for building a secure microservice communication system (zero-trust system), which includes:
Through this document, you will learn how to use Dubbo’s security mechanisms to build a zero-trust microservice system, achieving identity authentication, transparent link encryption, authorization, auditing, and other capabilities. Since building zero trust is a systematic task and Dubbo is only a part of the data communication layer, you may need a series of infrastructure support, including certificate generation, distribution, and security policy management.
Certificate generation and distribution are not within the scope of this document. We assume you already have a complete infrastructure to solve the certificate management problem. Therefore, we will focus more on explaining Dubbo’s authentication and authorization mechanisms and processes. If you do not have these certificate management facilities, we recommend using a service mesh architecture (see Dubbo Mesh Service Mesh documentation for details). With the certificate management mechanism and security policies of the service mesh control plane like Istio, you can easily implement the authentication and authorization capabilities of the Dubbo cluster.
Additionally, the following defaults to the behavior of Dubbo data plane in Dubbo Proxyless Mesh mode. For scenarios deploying Envoy, since Dubbo is only used as a communication and programming SDK, please refer to the standard Istio documentation for authentication and authorization capabilities in Envoy scenarios.
A complete zero-trust system consists of multiple components:
In the service mesh (Istio) deployment mode, the control plane usually manages security policies, certificates, etc. The control plane interacts with infrastructure such as the Kubernetes API Server and distributes configuration data to data plane components like Dubbo or Envoy. However, as mentioned earlier, we assume the control plane product is ready, so we will not discuss how the control plane issues certificates or defines authentication and authorization policies. We will focus on Dubbo’s responsibilities as the data plane and its interaction process with the control plane.
Below is a complete Dubbo zero-trust architecture diagram:
Dubbo provides two authentication modes:
You can use the Istio control plane to manage certificates, authentication policies, etc. Different authentication policies will affect the authentication behavior of the Dubbo data plane, such as whether to enable mTLS, whether to allow plaintext requests during the migration phase, etc.
In Istio mode, Dubbo’s authentication mechanism achieves automatic integration with the Istio control plane through xDS. The certificates and authentication policy configurations generated by the Istio control plane are automatically delivered to the Dubbo data plane. The Dubbo data plane receives these configurations via the Authentication API and applies them to all subsequent data communication processes, such as enabling new certificates and executing new authentication policies.
If the authentication policy enables Request Authentication, the Dubbo data plane is responsible for reading and filling the JWT token, meaning the token must be attached to the request context before the request is initiated. The prerequisite for using Request Authentication is that Channel Authentication must be enabled; otherwise, Request Authentication will not take effect.
In the Istio deployment architecture, the control plane authentication policy can enable or disable the bidirectional authentication of Channel Authentication. The workflow for bidirectional authentication is as follows:
For details, please refer to the authentication rules supported by Istio. Dubbo fully supports the authentication policies defined by Istio.
https://istio.io/latest/docs/concepts/security/#authentication-policies
Dubbo abstracts an extension mechanism for authorization, but currently, it only supports the Istio system in specific implementations. Therefore, its authorization capabilities are equivalent to those described by Istio. For more details, refer to the Istio Authorization Documentation
Dubbo receives user-configured authorization policies through the xDS data channel with the Istio control plane. When a request reaches a Dubbo instance, the Dubbo SDK uses the built-in authorization policy engine to match the request parameters and user identity with the authorization policies. If the match is successful, access is granted; otherwise, access is denied.
The complete authorization workflow in Dubbo is as follows:
For details, please refer to the authorization rules supported by Istio. Dubbo fully supports the authorization policies defined by Istio.
https://istio.io/latest/docs/concepts/security/#authorization-policies
Dubbo defines a set of authentication APIs. For regular usage scenarios, developers can enable TLS/mTLS communication through these APIs. However, for scenarios where the Istio control plane is deployed, Dubbo will automatically recognize the certificates and authentication policies delivered by the Istio control plane. Therefore, only interaction with the Istio control plane is required, and no special configuration is needed on the Dubbo side.
Regardless of whether the Istio control plane is used, the JWT token for Request Authentication still needs to be programmatically specified on the Dubbo side.
The definition of the authentication API varies slightly for each language implementation. For specific definitions, please refer to the respective SDK documentation:
Visit the following Dubbo Task Examples for hands-on practice with security policies.