Configuration examples and field descriptions for authorization policies-Alibaba Cloud Service Mesh-阿里云帮助中心

An authorization policy enables access control for workloads in a mesh. This topic describes configuration examples and provides field descriptions for authorization policies.

Introduction to authorization policies

Authorization policies support three types of rules: CUSTOM, DENY, and ALLOW. The rules are applied in the following order of priority, from highest to lowest: CUSTOM, DENY, and ALLOW. The basic flow of workload access control is as follows:

Matching rules

Configuration examples

Example 1: ALLOW rule

Allows requests that meet all of the following conditions:

The source `principals` is `cluster.local/ns/default/sa/sleep` or the `namespaces` is `test`.
The request operation is a `GET` method with the path `/info*` or a `POST` method with the path `/data`.

The issuer in the request's JSON Web Token (JWT) is `https://accounts.aliyun.com`.

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.aliyun.com"]

Example 2: DENY rule

Requests are rejected if they meet all of the following conditions:

The request comes from the `dev` namespace.
The request method is `POST`.

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

Example 3: CUSTOM rule

Executes the custom authorization service for requests with a path that matches `/admin*`.

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

Field descriptions

AuthorizationPolicy

An AuthorizationPolicy enables access control for workloads in a mesh.

Field	Type	Required	Description
selector	WorkloadSelector	No	Defines the workloads in the current namespace to which the authorization policy applies. If the authorization policy is in the root namespace (istio-system), the `selector` matches the target workloads in all namespaces. If you do not configure this field, the `selector` matches all workloads.
rules	Rule[]	No	A list of rules to match requests. If any rule matches the current request, the authorization policy is executed for that request. If you do not configure this field, no requests are matched. If you set `action` to `ALLOW` and do not configure this field, the default policy for the target workload is to deny all requests.
action	Action	No	The `action` to take if a request matches a rule in the `rules` list. If you do not configure this field, the default value is `ALLOW`.
provider	ExtensionProvider	No	Specifies the custom authorization service to use when `action` is `CUSTOM`.

WorkloadSelector

A WorkloadSelector determines which workloads the current configuration applies to. The following parameter is required.

Field	Type	Required	Description
matchLabels	map<string, string>	Yes	Configures one or more sets of labels to select the workloads on which the policy takes effect. The search for labels is limited to the namespace where the resource is configured.

Rule

A Rule matches requests based on three dimensions: source, operation, and other conditions.

A request is matched if it meets the following conditions. An empty Rule matches any request.

It meets at least one request source rule.
It meets at least one request operation rule.
It meets all other conditions.

All string types in a Rule support exact match, prefix match, suffix match, and presence match.

Match type	Example configuration	Description
Exact match	abc	Matches only the value `abc`.
Prefix match	abc*	Matches strings that start with `abc`, including `abc` itself.
Suffix match	*abc	Matches strings that end with `abc`, including `abc` itself.
Presence match	*	Matches all non-empty values.

The following table describes the fields of a Rule.

Field	Type	Required	Description
from	From[]	No	Specifies the source of a request. If you do not configure this field, sources of any type are allowed.
to	To[]	No	Specifies the operation of a request. If you do not configure this field, operations of any type are allowed.
when	Condition[]	No	Specifies a list of other conditions for a request. If you do not configure this field, any condition is allowed.

Rule.From

The From field contains a list of source objects.

Field	Type	Required	Description
source	Source	No	Specifies the source of a request.

Rule.From.Source

A Source specifies the identity of a request's source. The fields within a Source object have an AND relationship.

In the following example, the source configuration matches requests where `principals` is `admin` or `dev`, `namespaces` is `prod` or `test`, and the IP address is not `1.2.X.X`.

principals: ["admin", "dev"]
namespaces: ["prod", "test"]
notIpBlocks: ["1.2.X.X"]

Field	Type	Required	Description
principals	string[]	No	A list of peer identities. The format for a peer identity is `<TRUST_DOMAIN>/ns/<NAMESPACE>/sa/<SERVICE_ACCOUNT>`. In ASM, `TRUST_DOMAIN` defaults to `cluster.local`. This field requires mutual Transport Layer Security (mTLS) to be enabled. If you do not configure this field, any peer identity is allowed.
notPrincipals	string[]	No	A list of peer identities that are not matched.
requestPrincipals	string[]	No	A list of request identities. This value is generated from the request's JWT. The format for a request identity is `<ISS>/<SUB>`, such as `example.com/sub-1`. This field requires request authentication to be enabled. If you do not configure this field, any request identity is allowed. If you set this field to `*`, the request must carry a JWT. If you do not configure this field, the request is not required to carry a JWT.
notRequestPrincipals	string[]	No	A list of request identities that are not matched.
namespaces	string[]	No	A list of namespaces. This field requires mTLS to be enabled. If you do not configure this field, any namespace is allowed.
notNamespaces	string[]	No	The list of inverse matches for the namespace.
ipBlocks	string[]	No	A list of IP blocks from the source address of the IP packet. Both individual IP addresses (for example, `1.2.X.X`) and CIDR blocks (for example, `1.2.X.X/24`) are supported. If you do not configure this field, any IP address is allowed.
notIpBlocks	string[]	No	Inverse match list for IP blocking.
remoteIpBlocks	string[]	No	A list of IP blocks from the X-Forwarded-For request header or the proxy protocol. Both individual IP addresses (for example, `1.2.X.X`) and CIDR blocks (for example, `1.2.X.X/24`) are supported. If you do not configure this field, any IP address is allowed.
notRemoteIpBlocks	string[]	No	A list of remote IP blocks that are not matched.

Rule.To

The To field contains a list of operation objects.

Field	Type	Required	Description
operation	Operation	No	Specifies the operation of a request.

Operation

An Operation specifies the operation of a request. The fields within an Operation object have an AND relationship. In the following example, the Operation configuration matches requests where the host has the suffix `.example.com`, the request method is `GET` or `HEAD`, and the request path does not start with `/admin`.

hosts: ["*.example.com"]
methods: ["GET", "HEAD"]
notPaths: ["/admin*"]

Field	Type	Required	Description
hosts	string[]	No	A list of hosts from the HTTP request. The match is case-insensitive. If you do not configure this field, any host is allowed. This field applies only to the HTTP protocol.
notHosts	string[]	No	A case-insensitive list of hosts for reverse matching.
ports	string[]	No	A list of connection ports. If you do not configure this field, any port is allowed.
notPorts	string[]	No	A list of ports that are not matched.
methods	string[]	No	A list of HTTP request methods. For gRPC requests, this field is `POST`. If you do not configure this field, any method is allowed. This field applies only to the HTTP protocol.
notMethods	string[]	No	A list of methods that are not matched.
paths	string[]	No	A list of HTTP request paths. For gRPC services, the path format is `/package.service/method`.
notPaths	string[]	No	A list of reverse path matches.

Condition

A Condition specifies other attributes of a request.

Field	Type	Required	Description
key	string	Yes	The name of an Istio attribute. For more information, see the list of supported attributes.
values	string[]	No, but you must configure at least one of them.	A list of allowed attribute values.
notValues	string[]	No, but you must configure at least one of them.	A list of property values to exclude from matching.

AuthorizationPolicy.ExtensionProvider

Field	Type	Required	Description
name	string	No	Specify the name of the custom authorization service. You need to configure it in the ASM console on the Custom Authorization Service page. Different workloads can specify different custom authorization services. For more information, see Custom authorization .

AuthorizationPolicy.Action

An Action specifies the action to take on a request.

Field	Description
ALLOW	The default value. Allows requests that are matched by the rules.
DENY	Denies requests that are matched by the rules.
CUSTOM	Performs a custom authorization service for matched requests. You must first configure the service on the Custom Authorization Service page in the ASM console. The specified custom authorization service determines whether to allow the matched requests. For more information, see Custom Authorization and . When the Custom Authorization Service decides to `ALLOW` a request, it does not guarantee that the request will be granted. If other `ALLOW` or `DENY` rules match the request, the request must also comply with those rules. For information about the order of priority, see Introduction to authorization policies.

上一篇: Request Authentication 下一篇: End-to-end mTLS encryption with ASM