Authorization Policy

Istio Authorization Policy enables access control on workloads in the mesh.

For example, the following authorization policy applies to workloads matched withlabel selector “app: httpbin, version: v1”.

It allows requests from:- service account “cluster.local/ns/default/sa/sleep” or- namespace “test”to access the workload with:- “GET” method at paths of prefix “/info” or,- “POST” method at path “/data”.when the request has a valid JWT token issued by “https://accounts.google.com”.

Any other requests will be rejected.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 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"]

Access control is enabled on a workload if there is any authorization policies selectingthe workload. When access control is enabled, the default behavior is deny (deny-by-default)which means requests to the workload will be rejected if the request is not allowed by any ofthe authorization policies selecting the workload.

Currently AuthorizationPolicy only supports “ALLOW” action. This means thatif multiple authorization policies apply to the same workload, the effect is additive.

Authorization Policy scope (target) is determined by “metadata/namespace” andan optional “selector”.- “metadata/namespace” tells which namespace the policy applies. If set to rootnamespace, the policy applies to all namespaces in a mesh.- workload “selector” can be used to further restrict where a policy applies.

For example,

The following authorization policy applies to workloads containing label“app: httpbin” in namespace bar.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: policy
 namespace: bar
spec:
 selector:
   matchLabels:
     app: httpbin

The following authorization policy applies to all workloads in namespace foo.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: policy
 namespace: foo
spec:

The following authorization policy applies to workloads containing label“version: v1” in all namespaces in the mesh. (Assuming the root namespace isconfigured to “istio-config”).

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: policy
 namespace: istio-config
spec:
 selector:
   matchLabels:
     version: v1

AuthorizationPolicy

AuthorizationPolicy enables access control on workloads.

For example, the following authorization policy denies all requests to workloadsin namespace foo.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: deny-all
 namespace: foo
spec:

The following authorization policy allows all requests to workloads in namespacefoo.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: allow-all
 namespace: foo
spec:
 rules:
 - {}

Condition

Condition specifies additional required attributes.

Operation

Operation specifies the operations of a request.

Rule

Rule allows access from a list of sources to perform a list of operations whenthe condition is matched.

Any string field in the rule supports Exact, Prefix, Suffix and Presence match:- Exact match: “abc” will match on value “abc”.- Prefix match: “abc_” will match on value “abc” and “abcd”.- Suffix match: “_abc” will match on value “abc” and “xabc”.- Presence match: “*” will match when value is not empty.

Rule.From

From includes a list or sources.

Rule.To

To includes a list or operations.

Source

Source specifies the source identities of a request.

istio.type.v1beta1.WorkloadSelector

WorkloadSelector specifies the criteria used to determine if a policy can be appliedto a proxy. The matching criteria includes the metadata associated with a proxy,workload instance info such as labels attached to the pod/VM, or any other infothat the proxy provides to Istio during the initial handshake. If multiple conditions arespecified, all conditions need to match in order for the workload instance to beselected. Currently, only label based selection mechanism is supported.