--- WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE 'https://github.com/istio/api' REPO source_repo: https://github.com/istio/api title: Authorization Policy description: Configuration for access control on workloads. location: https://istio.io/docs/reference/config/security/authorization-policy.html layout: protoc-gen-docs generator: protoc-gen-docs schema: istio.security.v1beta1.AuthorizationPolicy weight: 20 aliases: [/docs/reference/config/authorization/authorization-policy] number_of_entries: 9 ---
Istio Authorization Policy enables access control on workloads in the mesh.
Authorization policy supports CUSTOM, DENY and ALLOW actions for access control. When CUSTOM, DENY and ALLOW actions are used for a workload at the same time, the CUSTOM action is evaluated first, then the DENY action, and finally the ALLOW action. The evaluation is determined by the following rules:
Istio Authorization Policy also supports the AUDIT action to decide whether to log requests. AUDIT policies do not affect whether requests are allowed or denied to the workload. Requests will be allowed or denied based solely on CUSTOM, DENY and ALLOW actions.
A request will be internally marked that it should be audited if there is an AUDIT policy on the workload that matches the request. A separate plugin must be configured and enabled to actually fulfill the audit decision and complete the audit behavior. The request will not be audited if there are no such supporting plugins enabled. Currently, the only supported plugin is the Stackdriver plugin.
Here is an example of Istio Authorization Policy:
It sets the action
to “ALLOW” to create an allow policy. The default action is “ALLOW”
but it is useful to be explicit in the policy.
It allows requests from:
to access the workload with:
when the request has a valid JWT token issued by “https://accounts.google.com”.
Any other requests will be denied.
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"]
The following is another example that sets action
to “DENY” to create a deny policy.
It denies requests from the “dev” namespace to the “POST” method on all workloads
in the “foo” namespace.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
action: DENY
rules:
- from:
- source:
namespaces: ["dev"]
to:
- operation:
methods: ["POST"]
The following authorization policy sets the action
to “AUDIT”. It will audit any GET requests to the path with the
prefix “/user/profile”.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
namespace: ns1
name: anyname
spec:
selector:
matchLabels:
app: myapi
action: AUDIT
rules:
- to:
- operation:
methods: ["GET"]
paths: ["/user/profile/*"]
Authorization Policy scope (target) is determined by “metadata/namespace” and an optional “selector”.
For example,
The following authorization policy applies to all workloads in namespace foo. It allows nothing and effectively denies all requests to workloads in namespace foo.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-nothing
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:
- {}
The following authorization policy applies to workloads containing label “app: httpbin” in namespace bar. It allows nothing and effectively denies all requests to the selected workloads.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-nothing
namespace: bar
spec:
selector:
matchLabels:
app: httpbin
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-system”).
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-nothing
namespace: istio-system
spec:
selector:
matchLabels:
version: v1
AuthorizationPolicy enables access control on workloads.
Rule matches requests from a list of sources that perform a list of operations subject to a list of conditions. A match occurs when at least one source, one operation and all conditions matches the request. An empty rule is always matched.
Any string field in the rule supports Exact, Prefix, Suffix and Presence match:
Source specifies the source identities of a request. Fields in the source are ANDed together.
For example, the following source matches if the principal is “admin” or “dev” and the namespace is “prod” or “test” and the ip is not “1.2.3.4”.
principals: ["admin", "dev"]
namespaces: ["prod", "test"]
notIpBlocks: ["1.2.3.4"]
Operation specifies the operations of a request. Fields in the operation are ANDed together.
For example, the following operation matches if the host has suffix “.example.com” and the method is “GET” or “HEAD” and the path doesn’t have prefix “/admin”.
hosts: ["*.example.com"]
methods: ["GET", "HEAD"]
notPaths: ["/admin*"]
Condition specifies additional required attributes.
From includes a list or sources.
To includes a list or operations.
Action specifies the operation to take.
Name | Description |
---|---|
ALLOW |
Allow a request only if it matches the rules. This is the default type. |
DENY |
Deny a request if it matches any of the rules. |
AUDIT |
Audit a request if it matches any of the rules. |
CUSTOM |
The CUSTOM action allows an extension to handle the user request if the matching rules evaluate to true. The extension is evaluated independently and before the native ALLOW and DENY actions. When used together, A request is allowed if and only if all the actions return allow, in other words, the extension cannot bypass the authorization decision made by ALLOW and DENY action. Extension behavior is defined by the named providers declared in MeshConfig. The authorization policy refers to the extension by specifying the name of the provider. One example use case of the extension is to integrate with a custom external authorization system to delegate the authorization decision to it. Note: The CUSTOM action is currently an alpha feature and is subject to breaking changes in later versions. The following authorization policy applies to an ingress gateway and delegates the authorization check to a named extension “my-custom-authz” if the request path has prefix “/admin/”.
|