Authorization Policy
Istio Authorization Policy enables access control on workloads in the mesh.
For example, the following authorization policy applies to workloads matched with label 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 selecting the 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 of the authorization policies selecting the workload.
Currently AuthorizationPolicy only supports “ALLOW” action. This means that if multiple authorization policies apply to the same workload, the effect is additive.
Authorization Policy scope (target) is determined by “metadata/namespace” and an optional “selector”. - “metadata/namespace” tells which namespace the policy applies. If set to root namespace, 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 is configured 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 workloads in 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 namespace foo.
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 when the 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 applied to 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 info that the proxy provides to Istio during the initial handshake. If multiple conditions are specified, all conditions need to match in order for the workload instance to be selected. Currently, only label based selection mechanism is supported.