Dubbo Service Mesh security provides strong identities, powerful policies, transparent TLS encryption, and authentication tooling to protect your services and data. It follows the same security model as Istio, but is optimized for the Dubbo protocol and sidecarless architecture.
The security architecture of Dubbo Service Mesh has two core components:
These components work together to provide security for your service mesh.
In Dubbo Service Mesh, every workload has an identity that represents its origin. Identities are based on the SPIFFE standard and use SPIFFE URIs of the form: spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>.
A Dubbo identity consists of:
cluster.local.For example, a workload running with ServiceAccount bookinfo-productpage in the default namespace has the identity:
spiffe://cluster.local/ns/default/sa/bookinfo-productpage
Dubbo Service Mesh supports trust domain aliases, allowing a mesh to trust workloads from multiple trust domains. This is useful in multi-cluster or multi-tenant scenarios. Using TrustDomainAliases in MeshConfig, the control plane expands identities across trust domains automatically.
Dubbo Service Mesh uses the SPIFFE standard to manage workload identities and certificates. Each workload automatically obtains a SPIFFE identity and can request an X.509 certificate for mutual TLS authentication.
The Dubbo control plane includes a certificate authority (CA) that issues certificates for workloads. Workloads communicate with the control plane through the Dubbo Agent to request certificates and rotate them periodically.
Workload certificates are stored in the following locations inside the container:
./etc/certs/cert-chain.pem or ./var/run/secrets/workload-spiffe-uds/credentials/cert-chain.pem./etc/certs/key.pem or ./var/run/secrets/workload-spiffe-uds/credentials/key.pem./etc/certs/root-cert.pem or ./var/run/secrets/workload-spiffe-uds/credentials/root-cert.pemCertificates can be delivered to workloads via SDS (Secret Discovery Service) or mounted files.
Dubbo Service Mesh supports peer authentication (PeerAuthentication) for service-to-service authentication.
Mutual TLS is the primary mechanism for service-to-service authentication in Dubbo Service Mesh. It provides:
In permissive mode, a service accepts both plaintext and mTLS traffic. This is useful for gradually migrating to mTLS while still supporting legacy workloads.
Secure naming ensures that only workloads with the correct ServiceAccount can access a given service. Dubbo uses SPIFFE identities to validate service identities and guarantee that only authorized services can communicate with each other.
The authentication architecture in Dubbo Service Mesh consists of:
dubbod manages authentication policies and certificates.Authentication policies specify authentication requirements at mesh, namespace, or workload scope. Dubbo supports the PeerAuthentication policy to define service-to-service authentication requirements.
Authentication policies are stored as Kubernetes CRDs in the API server. The Dubbo control plane watches these resources and pushes policy changes to the data plane.
PeerAuthentication policies can use the selector field to target specific workloads. If no selector is specified, the policy applies to the entire namespace or mesh.
PeerAuthentication policies configure service-to-service authentication. They support the following mTLS modes:
The following example configures a PeerAuthentication policy that enforces STRICT mTLS for all services in the default namespace:
apiVersion: security.dubbo.apache.org/v1
kind: PeerAuthentication
metadata:
name: default
namespace: default
spec:
mtls:
mode: STRICT
When you update authentication policies, the Dubbo control plane automatically pushes the new policies to the data plane. Policy changes take effect immediately without restarting workloads.
After understanding the basic concepts above, you can: