This blog address: https://security.blog.csdn.net/article/details/130152887
1. Certification service
1.1, JWT-based authentication
Under the microservice architecture, each service is stateless. Since the server needs to store the login status of the client, the traditional session authentication method is no longer applicable in microservices. The ideal implementation should be stateless login, and the process is usually as follows:
1. The client requests a certain service, and the server performs login authentication for the user.
2. After the authentication is passed, the server encrypts the user login information and forms a token, and finally returns to the client as the login credential.
3. After step 2, the client must carry the authentication token every time it requests.
4. The server decrypts the token and judges whether it is valid. If it is valid, the authentication passes, otherwise it returns a failure message.
Stateless login can be achieved through JWT. JWT is a JSON-style lightweight authentication and authorization specification, which is the token mentioned in the above process. It is mainly used in distributed scenarios. It should be noted that JWT tokens will contain Sensitive user information, in order to prevent bypass, JWT token adopts signature mechanism. In addition, encryption protocols are required for transmission.
1.2. Istio-based authentication
The basic knowledge of Istio can refer to a blog post written before: https://security.blog.csdn.net/article/details/128449214
Istio has two main types of authentication: transport authentication and request-level authentication
1. Transmission authentication
Transport authentication is an authentication type of Istio, which is mainly used for service-to-service authentication in the microservice application architecture, so that the connected client can be verified. For this type of authentication, Istio provides a mutual TLS solution, which provides the following functions:
1. Ensure service-to-service communication security.
2. Provide a key management system to automatically generate, distribute and rotate keys and certificates.
3. Provide each service with an identity that represents its role, enabling cross-cluster interoperability.
Specifically, we can specify authentication requirements for services in Istio by using transport authentication policies. For example, a namespace-level TLS authentication policy can specify that all access between Pods in a certain namespace should use TLS encryption, and a Pod-level TLS authentication policy can specify TLS encryption is required when a specific Pod is accessed.
2. Request-level authentication
Request-level authentication is an authentication type of Istio. It is mainly used to authenticate end users. The main difference from transmission authentication is that request-level authentication is mainly used to verify the credentials carried by users when requesting services, rather than service-to-service authentication. .
Request-level authentication is mainly implemented through the JWT mechanism. Compared with the traditional session authentication method, the biggest difference is that the authentication information is stored on the client side. Since the authentication information is no longer stored on the server side, it is very suitable for stateless microservice scenarios and achieves the purpose of easy expansion.
Istio's JWT authentication mainly relies on JWKS. JWKS is a set of keys that contain public keys used to verify JWT. In actual application scenarios, O&M personnel implement request-level authentication by deploying JWT authentication policies for services.
The core configuration of the JWT authentication strategy is shown below:
// issuer：代表发布JWT的发行者
issuer: https://example.com
// jwksUri：JWKS获取的地址，本地或远程均可，用于验证JWT的签名
jwksUri: https://example.com/.well-known/jwks.json
// triggerRules：triggerRules为使用JWT验证请求的规则触发列表，如果满足匹配规则就进行JWT验证
triggerRules:
- excludedPaths:
// 对于任何带有/status/前缀的请求路径，除了/status/version以外，都需要JWT认证
- exact: /status/version
includedPaths:
- prefix: /status/
After the deployment of the JWT authentication policy is completed, when there is a new external request for a certain service, the request-level authentication will verify the token (Token) carried in the request according to the content of the policy. If it matches the content of the policy, the authentication failure will be returned, otherwise the authentication will be successful.
2. Istio-based access control
2.1. Istio Authorization
The Istio authorization process can be summarized as follows:
The Administrator uses the yaml file to specify the Istio authorization policy and deploys it to the core components of Istiod. Istiod monitors the change of the authorization policy through the API Server component. If there is a change, it obtains the new policy. Istiod sends the authorization policy to the sidecar agent of the service. , each sidecar proxy contains an authorization engine that authorizes requests when the engine is running.
as the picture shows:
Here is an example of an Istio authorization policy:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin-policy
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
to:
- operation:
methods: ["GET"]
paths: ["/info*"]
when:
- key: request.auth.claims[iss]
values: ["https://foo.com"]
The meaning of this authorization policy is: filter out app:httpbinthe pods that contain this label in the foo namespace, match the requests sent to these pods, and if the match is successful, release the current request.
The matching rules are as follows: the Service Account of the pod that initiates the request must be cluster.local/ns/default/sa/sleep, the request uses the HTTP protocol, the specific method type of the request is GET, the URL of the request is /info*, and the request must contain a https://foo.comvalid JWT Token issued by .
From this example, we can see that an authorization policy mainly includes the following parts:
name : the name of the authorization policy, which is only used to identify the authorization policy itself, and will not affect the matching and execution of rules; namespace
: the namespace where the current policy object is located, you can use this field to configure authorization policies with different scopes;
selector : use label to Select which pods the current authorization policy applies to. Note that the pod on the server is set here, because eventually these rules will be converted into Envoy rules and executed by the Envoy Porxy on the server; action
: can be ALLOW (default value) or DENY;
rules : matching rules, if the matching is successful, then The corresponding action will be executed;
2.2. Matching algorithm of authorization policy
For a certain request, the corresponding authorization strategy will be executed according to a certain matching algorithm:
1. If any DENY authorization policy matches the current request, the current request will be rejected;
2. For the current pod, if there is no ALLOW authorization policy, the current request will be allowed;
3. If any ALLOW authorization policy matches the current request, then Release the current request;
4. Reject the current request;
That is to say, if both ALLOW and DENY policies act on the same pod, the DENY policy will be executed first, and other ALLOW rules will be ignored.