Closed cocotyty closed 2 years ago
In data plane: mTLS Agent can be combine into polaris-sidecar, as a sub module to provide certification to envoy
In control plane: we can add a server to provide CA certification ability, named "polaris-authority" ?
In data plane: mTLS Agent can be combine into polaris-sidecar, as a sub module to provide certification to envoy
In control plane: we can add a server to provide CA certification ability, named "polaris-authority" ?
Agree!
I have another suggestion, both authority and authentication are belong to security catalog, such as spring-security, istio-citadel.
So, server name maybe "polaris-security", provide two methanism, authority and authenication, to resolve application security issues.
I have another suggestion, both authority and authentication are belong to security catalog, such as spring-security, istio-citadel.
So, server name maybe "polaris-security", provide two methanism, authority and authenication, to resolve application security issues.
Yeap , And the authorization part maybe need another design document, maybe we can start the polaris-security project with the authentication part first.
数据面证书是否可以支持用户自己签发?
LGTM
What is the feature you want to add? Mutual TLS or mTLS, as the name suggests, establishes a secure connection between the client and the server after they both validate each other’s authenticity.
Why do you want to add this feature?
The introduction of the mTLS mechanism would be a great refinement for PolarisMesh.
It would help applications in polarismesh to defend against man-in-the-middle attacks and enterprises to build a zero-trust network infrastructure.
Our goal is to introduce the mTLS mechanism for PolarisMesh with a simple, reliable, scalable, and out-of-the-box experience.
How to implement this feature?
Design
The architecture is shown in the diagram below.
We introduce two new components to polaris, mTLS Agent and CA Server ( polaris-security ).
The mTLS Agent has three functions:
mTLS Agent and Envoy
The mTLS Agent is in a separate container of the pod.
The Envoy and the mTLS Agent share an emptydir volume.
While the agent starts , it will listen on a UNIX domain socket file and serves the envoy’s SDS API.
The Envoy will request certificates and keys via this SDS API.
mTLS Agent and CA Server
When the mtls agent starts, it will begin the following proccess:
The CA server needs a mechanism to verify the identity of the agent to decide whether to sign the certificate.
We all know that the service account token is automatically loaded to the container by Kubernetes.It’s a JWT and can be validated by Kubernetes APIServer.
So mTLS Agent can use the Kubernetes service account token as the credential.
While the CA Server receives CSR, it will validate the token by using the Kubernetes TokenReview API.
Hijacking inbound traffic
We need hijacking all inbound traffic to enable the mTLS.
We can do it by changing the istio-iptables arguments:
We need to add some additional envoy configurations.
Modify outbound traffic configuration
We need to config all outbound cluster's
transport_socket_matches
property.Here is an exapmle:
Compatibility & Migration
Pods with and without mTLS Agent need different envoy configurations. We can use a different node id format to recognize them.
For example :
Polaris Controller should add a metadata label indicating whether it’s mTLS enabled.
For example:
So that Envoy can only use mTLS to transfer data to endpoints that support mTLS.
WHAT WE SHOULD DO NEXT