Authorization Policy

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:

1. If there are any CUSTOM policies that match the request, evaluate and deny the request if the evaluation result is deny.
2. If there are any DENY policies that match the request, deny the request.
3. If there are no ALLOW policies for the workload, allow the request.
4. If any of the ALLOW policies match the request, allow the request.
5. Deny the request.

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:

• 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 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"]

apiVersion: security.istio.io/v1
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"]

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        namespaces: ["dev"]
    to:
    - operation:
        methods: ["POST"]

The following is another example that sets action to DENY to create a deny policy. It denies all the requests with POST method on port 8080 on all workloads in the foo namespace.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: DENY
  rules:
  - to:
    - operation:
        methods: ["POST"]
        ports: ["8080"]

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: DENY
  rules:
  - to:
    - operation:
        methods: ["POST"]
        ports: ["8080"]

When this rule is applied to TCP traffic, the method field (as will all HTTP based attributes) cannot be processed. For a DENY rule, missing attributes are treated as matches. This means all TCP traffic on port 8080 would be denied in the example above. If we were to remove the ports match, all TCP traffic would be denied. As a result, it is recommended to always scope DENY policies to a specific port, especially when using HTTP attributes Authorization Policy for TCP Ports.

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/*"]

apiVersion: security.istio.io/v1
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.

• “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 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:
  {}

apiVersion: security.istio.io/v1
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:
 - {}

apiVersion: security.istio.io/v1
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

apiVersion: security.istio.io/v1
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

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: allow-nothing
 namespace: istio-system
spec:
 selector:
   matchLabels:
     version: v1

The following example shows you how to set up an authorization policy using an experimental annotation istio.io/dry-run to dry-run the policy without actually enforcing it.

The dry-run annotation allows you to better understand the effect of an authorization policy before applying it to the production traffic. This helps to reduce the risk of breaking the production traffic caused by an incorrect authorization policy. For more information, see dry-run tasks.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: dry-run-example
  annotations:
    "istio.io/dry-run": "true"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: dry-run-example
  annotations:
    "istio.io/dry-run": "true"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

AuthorizationPolicy

AuthorizationPolicy enables access control on workloads.

Rule

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:

• 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.

Source

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 “203.0.113.4”.

principals: ["admin", "dev"]
namespaces: ["prod", "test"]
notIpBlocks: ["203.0.113.4"]

Operation

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

Condition specifies additional required attributes.

AuthorizationPolicy.ExtensionProvider

Rule.From

From includes a list of sources.

Rule.To

To includes a list of operations.

AuthorizationPolicy.Action

Action specifies the operation to take.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: ext-authz
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  action: CUSTOM
  provider:
    name: “my-custom-authz”
  rules:
  - to:
    - operation:
        paths: [“/admin/*”]