Istio It is a kind of traffic management , Security , Observability , Scalable service grid solutions . that Istio What is the authorization model for ？ How to implement the access control of the workload in the grid ？
Implementation architecture
stay Istio in ,Envoy The agent is “ Authorization engine ”, Because it contains all the policies used to determine whether a request must be denied or allowed . Because the decision is made directly from the agent , therefore Istio Authorization in is very fast . Proxy usage AuthorizationPolicy User defined resources to configure , When you apply it to a cluster , The resource will be provided by Istiod Get and configure the service proxy for the target workload .
AuthorizationPolicy
Scope
AuthorizationPolicy The scope of can be mesh, Namespace and The workload Scope , It depends on the namespace and spec/selector Field .
If AuthorizationPolicy be in istio root Namespace ( Usually istio-system), And there's no selector Field , So the scope of the strategy is mesh Level , That is, the rule will be enforced within the grid scope of all the namespace .
If AuthorizationPolicy In the wrong istio root Namespace , And there's no selector Field , Then the scope of the policy is the namespace level , That is, the rule will work on all workloads in that namespace .
If AuthorizationPolicy In the wrong istio root Namespace , And contains selector Field , Then the scope of the policy is the workload level , That is, the rule will work on the corresponding workload in that namespace .
action
Policy support ALLOW and DENY action .
When ALLOW and DENY When the action is used for the workload at the same time , Will first evaluate DENY Strategy . The assessment is determined by the following rules ：
- If there is anything that matches the request DENY Strategy , Refuse the request .
- If there is no workload specific ALLOW Strategy , The request is allowed .
- If anything ALLOW The policy matches the request , The request is allowed .
- Refuse request .
Rules
AuthorizationPolicy Contains a list of rules , These rules describe matching requests , Then what requests are allowed or rejected based on the operation . The rules consist of three parts ：from,to and when.
- from -- Specify the source of the request . If not set , Any source is allowed .
- to -- Specifies the requested operation . If not set , Any operation is allowed .
- when -- Specify a list of other conditions for the request . If not set , Any condition is allowed .
Example
First, let's start with a typical AuthorizationPolicy Deepen the understanding of the three elements .
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
- source:
namespaces: ["test"]
to:
- operation:
methods: ["GET"]
paths: ["/info*"]
- operation:
methods: ["POST"]
paths: ["/data"]
when:
- key: request.auth.claims[iss]
values: ["https://accounts.google.com"]This example ,httpbin The authorization policy , be located foo Namespace , And there's no selector, So it's a namespace level authorization policy , It works on foo All workloads under the namespace .
The sample action is set to "ALLOW”, The goal is to create permission policies .
In the example ,source yes principals, But it can also be requestPrincipals,namespaces or ipBlocks.
Let's see operation Field ： And methods A valid match to use together is hosts,ports,paths And its exclusion to , for example notHosts.
in the majority of cases , It can be omitted “when” Field , Usually used only in complex situations , But you can use the supported Istio Attribute list to further customize the request matching .
in summary , This policy allows requesters who meet the following conditions :
- The service account is “cluster.local/ns/default/sa/sleep”
- be located test Namespace
You can access a workload that meets the following conditions :
- The access prefix path is “/info” Of Get Method
- The access path is “/data” Of POST Method
When the request has “https://accounts.google.com” The signature is legal JWT token when .
summary
Istio Available for use AuthorizationPolicy Custom resources implement access control between workloads in the service grid . This access control is done by Envoy Sidecar Agents implement at the application level . It provides users with Kubernetes It's very powerful between workloads , Flexible but efficient way to authorize .
