当前位置:网站首页>Analysis of istio access control

Analysis of istio access control

2020-11-08 10:30:04 control

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 .

版权声明
本文为[control]所创,转载请带上原文链接,感谢