istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

update authz concept page for the new v1beta1 policy (#5165) 

* update authz doc

* address comments.

* use master

* address more comments

* implicit enablement

* comments

* link to ref page

* fix lint

* address more comments

* Update content/en/docs/ops/common-problems/security-issues/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* Update content/en/docs/reference/config/authorization/conditions/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* Update content/en/docs/reference/config/authorization/conditions/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* Update content/en/docs/reference/config/authorization/conditions/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* Update content/en/docs/reference/config/authorization/constraints-and-properties/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* Update content/en/docs/concepts/security/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* Update content/en/docs/concepts/security/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* Update content/en/docs/concepts/security/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* Update content/en/docs/concepts/security/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* Update content/en/docs/concepts/security/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* Update content/en/docs/concepts/security/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* Update content/en/docs/concepts/security/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* Update content/en/docs/concepts/security/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* Update content/en/docs/concepts/security/index.md

Co-Authored-By: Martin Taillefer <geeknoid@users.noreply.github.com>

* more fix
This commit is contained in:
Yangmin Zhu 2019-11-09 06:02:52 -08:00 committed by Istio Automation
parent ad5a46c621
commit 9a57887706
6 changed files with 1297 additions and 270 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1052
content/en/docs/concepts/security/authz.svg
View File

File diff suppressed because one or more lines are too long
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 78 KiB

After

Width:  |  Height:  |  Size: 79 KiB

465
content/en/docs/concepts/security/index.md
View File

@ -598,14 +598,12 @@ peers:
## Authorization ## Authorization
Istio's authorization feature - also known as Role-based Access Control (RBAC) Istio's authorization feature provides mesh-level, namespace-level, and workload-level
- provides namespace-level, service-level, and method-level access control for access control on workloads in an Istio Mesh. It provides:
services in an Istio Mesh. It features:
- **Role-Based semantics**, which are simple and easy to use. - **Workload-to-workload and end-user-to-workload authorization**.
- **Service-to-service and end-user-to-service authorization**. - **A Simple API**, it includes a single [`AuthorizationPolicy` CRD](/docs/reference/config/authorization/authorization-policy/), which is easy to use and maintain.
- **Flexibility through custom properties support**, for example conditions, - **Flexible semantics**, operators can define custom conditions on Istio attributes.
in roles and role-bindings.
- **High performance**, as Istio authorization is enforced natively on Envoy. - **High performance**, as Istio authorization is enforced natively on Envoy.
- **High compatibility**, supports HTTP, HTTPS and HTTP2 natively, as well as any plain TCP protocols. - **High compatibility**, supports HTTP, HTTPS and HTTP2 natively, as well as any plain TCP protocols.
@ -617,346 +615,283 @@ services in an Istio Mesh. It features:
>}} >}}
The above diagram shows the basic Istio authorization architecture. Operators The above diagram shows the basic Istio authorization architecture. Operators
specify Istio authorization policies using `.yaml` files. Once deployed, Istio specify Istio authorization policies using `.yaml` files.
saves the policies in the `Istio Config Store`.
Pilot watches for changes to Istio authorization policies. It fetches the
updated authorization policies if it sees any changes. Pilot distributes Istio
authorization policies to the Envoy proxies that are colocated with the
service instances.
Each Envoy proxy runs an authorization engine that authorizes requests at Each Envoy proxy runs an authorization engine that authorizes requests at
runtime. When a request comes to the proxy, the authorization engine evaluates runtime. When a request comes to the proxy, the authorization engine evaluates
the request context against the current authorization policies, and returns the the request context against the current authorization policies, and returns the
authorization result, `ALLOW` or `DENY`. authorization result, `ALLOW` or `DENY`.
### Enabling authorization ### Implicit enablement
You enable Istio Authorization using a `ClusterRbacConfig` object. The `ClusterRbacConfig` There is no need to explicitly enable Istio's authorization feature, you just apply
object is a cluster-scoped singleton with a fixed name value of `default`. You can the `AuthorizationPolicy` on **workloads** to enforce access control.
only use one `ClusterRbacConfig` instance in the mesh. Like other Istio configuration
objects, `ClusterRbacConfig` is defined as a
Kubernetes `CustomResourceDefinition`
[(CRD)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) object.
In the `ClusterRbacConfig` object, the operator can specify a `mode` value, which can If no `AuthorizationPolicy` applies to a workload, no access control will be enforced,
be: In other words, all requests will be allowed.
- **`OFF`**: Istio authorization is disabled. If any `AuthorizationPolicy` applies to a workload, access to that workload is
- **`ON`**: Istio authorization is enabled for all services in the mesh. denied by default, unless explicitly allowed by a rule declared in the policy.
- **`ON_WITH_INCLUSION`**: Istio authorization is enabled only for services and
namespaces specified in the `inclusion` field.
- **`ON_WITH_EXCLUSION`**: Istio authorization is enabled for all services in
the mesh except the services and namespaces specified in the `exclusion`
field.
In the following example, Istio authorization is enabled for the `default` Currently `AuthorizationPolicy` only supports `ALLOW` action. This means that if
namespace. multiple authorization policies apply to the same workload, the effect is additive.
{{< text yaml >}}
apiVersion: "rbac.istio.io/v1alpha1"
kind: ClusterRbacConfig
metadata:
name: default
spec:
mode: 'ON_WITH_INCLUSION'
inclusion:
namespaces: ["default"]
{{< /text >}}
### Authorization policy ### Authorization policy
To configure an Istio authorization policy, you specify a `ServiceRole` and To configure an Istio authorization policy, you create an
`ServiceRoleBinding`. Like other Istio configuration objects, they are [`AuthorizationPolicy` resource](/docs/reference/config/authorization/authorization-policy/).
defined as
Kubernetes `CustomResourceDefinition` [(CRD)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) objects.
- **`ServiceRole`** defines a group of permissions to access services. An authorization policy includes a selector and a list of rules. The selector
- **`ServiceRoleBinding`** grants a `ServiceRole` to particular subjects, such specifies the **target** that the policy applies to, while the rules specify **who**
as a user, a group, or a service. is allowed to do **what** under which **conditions**. Specifically:
The combination of `ServiceRole` and `ServiceRoleBinding` specifies: **who** is - **target** refers to the `selector` section in the `AuthorizationPolicy`.
allowed to do **what** under **which conditions**. Specifically: - **who** refers to the `from` section in the `rule` of the `AuthorizationPolicy`.
- **what** refers to the `to` section in the `rule` of the `AuthorizationPolicy`.
- **conditions** refers to the `when` section in the `rule` of the `AuthorizationPolicy`.
- **who** refers to the `subjects` section in `ServiceRoleBinding`.
- **what** refers to the `permissions` section in `ServiceRole`.
- **which conditions** refers to the `conditions` section you can specify with
the [Istio attributes](/docs/reference/config/policy-and-telemetry/attribute-vocabulary/)
in either `ServiceRole` or `ServiceRoleBinding`.
#### `ServiceRole`
A `ServiceRole` specification includes a list of `rules`, AKA permissions.
Each rule has the following standard fields: Each rule has the following standard fields:
- **`services`**: A list of service names. You can set the value to `*` to - **`from`**: A list of sources.
include all services in the specified namespace. - **`to`**: A list of operations.
- **`when`**: A list of custom conditions.
- **`methods`**: A list of HTTP methods. You can set the value to `*` to include all The following example shows an `AuthorizationPolicy` that allows two sources
HTTP methods. This field should not be set for TCP and gRPC services. (service account `cluster.local/ns/default/sa/sleep` and namespace `dev`) to access the
workloads with labels `app: httpbin` and `version: v1` in namespace foo when the request
- **`paths`**: HTTP paths or gRPC methods. The gRPC methods must be in the is sent with a valid JWT token.
form of `/packageName.serviceName/methodName` and are case sensitive.
A `ServiceRole` specification only applies to the namespace specified in the
`metadata` section. A rule requires the `services` field and the other fields are optional.
If you do not specify a field or if you set its value to `*`, Istio applies the field to all instances.
The example below shows a simple role: `service-admin`, which has full access
to all services in the `default` namespace.
{{< text yaml >}} {{< text yaml >}}
apiVersion: "rbac.istio.io/v1alpha1" apiVersion: security.istio.io/v1beta1
kind: ServiceRole kind: AuthorizationPolicy
metadata: metadata:
name: service-admin name: httpbin
namespace: default namespace: foo
spec: spec:
rules: selector:
- services: ["*"] matchLabels:
app: httpbin
version: v1
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
- source:
namespaces: ["dev"]
to:
- operation:
methods: ["GET"]
when:
- key: request.auth.claims[iss]
values: ["https://accounts.google.com"]
{{< /text >}} {{< /text >}}
Here is another role: `products-viewer`, which has read, `"GET"` and `"HEAD"`, #### Policy Target
access to the service `products.default.svc.cluster.local` in the `default`
namespace. Policy scope (target) is determined by `metadata/namespace` and an optional `selector`.
The `metadata/namespace` tells which namespace the policy applies to. If set to the
root namespace, the policy applies to all namespaces in a mesh. The value of
root namespace is configurable, and the default is `istio-system`. If set to a
normal namespace, the policy will only apply to the specified namespace.
A workload `selector` can be used to further restrict where a policy applies.
The `selector` uses pod labels to select the target workload. The workload
selector contains a list of `{key: value}` pairs, where the `key` is the name of the label.
If not set, the authorization policy will be applied to all workloads in the same namespace
as the authorization policy.
The following example policy `allow-read` allows `"GET"` and `"HEAD"` access to
the workload with label `app: products` in the `default` namespace.
{{< text yaml >}} {{< text yaml >}}
apiVersion: "rbac.istio.io/v1alpha1" apiVersion: security.istio.io/v1beta1
kind: ServiceRole kind: AuthorizationPolicy
metadata: metadata:
name: products-viewer name: allow-read
namespace: default namespace: default
spec: spec:
selector:
matchLabels:
app: products
rules: rules:
- services: ["products.default.svc.cluster.local"] - to:
methods: ["GET", "HEAD"] - operation:
methods: ["GET", "HEAD"]
{{< /text >}} {{< /text >}}
In addition, we support prefix matching and suffix matching for all the fields #### Value matching
in a rule. For example, you can define a `tester` role with the following
permissions in the `default` namespace:
- Full access to all services with prefix `"test-*"`, for example: Exact match, prefix match, suffix match, and presence match are supported for most
`test-bookstore`, `test-performance`, `test-api.default.svc.cluster.local`. of the field with a few exceptions (e.g., the `key` field under the `when` section,
- Read (`"GET"`) access to all paths with `"*/reviews"` suffix, for example: the `ipBlocks` under the `source` section and the `ports` field under the `to` section only support exact match).
`/books/reviews`, `/events/booksale/reviews`, `/reviews` in service
`bookstore.default.svc.cluster.local`. - **Exact match**. i.e., exact string match.
- **Prefix match**. A string with an ending `"*"`. For example, `"test.abc.*"` matches `"test.abc.com"`, `"test.abc.com.cn"`, `"test.abc.org"`, etc.
- **Suffix match**. A string with a starting `"*"`. For example, `"*.abc.com"` matches `"eng.abc.com"`, `"test.eng.abc.com"`, etc.
- **Presence match**. `*` is used to specify anything but not empty. You can specify a field must be present using the format `fieldname: ["*"]`.
This means that the field can match any value, but it cannot be empty. Note that it is different from leaving a field unspecified, which means anything including empty.
The following example policy allows access at paths with prefix `"/test/"` or suffix `"/info"`.
{{< text yaml >}} {{< text yaml >}}
apiVersion: "rbac.istio.io/v1alpha1" apiVersion: security.istio.io/v1beta1
kind: ServiceRole kind: AuthorizationPolicy
metadata: metadata:
name: tester name: tester
namespace: default namespace: default
spec: spec:
selector:
matchLabels:
app: products
rules: rules:
- services: ["test-*"] - to:
methods: ["*"] - operation:
- services: ["bookstore.default.svc.cluster.local"] paths: ["/test/*", "*/info"]
paths: ["*/reviews"]
methods: ["GET"]
{{< /text >}} {{< /text >}}
In a `ServiceRole`, the combination of `namespace` + `services` + `paths` + #### Allow-all and deny-all
`methods` defines **how a service or services are accessed**. In some
situations, you may need to specify additional conditions for your rules. For
example, a rule may only apply to a certain **version** of a service, or only
apply to services with a specific **label**, like `"foo"`. You can easily
specify these conditions using `constraints`.
For example, the following `ServiceRole` definition adds a constraint that The example below shows a simple policy `allow-all` which allows full access to all
`request.headers[version]` is either `"v1"` or `"v2"` extending the previous workloads in the `default` namespace.
`products-viewer` role. The supported `key` values of a constraint are listed
in the [constraints and properties page](/docs/reference/config/authorization/constraints-and-properties/).
In the case that the attribute is a `map`, for example `request.headers`, the
`key` is an entry in the map, for example `request.headers[version]`.
{{< text yaml >}} {{< text yaml >}}
apiVersion: "rbac.istio.io/v1alpha1" apiVersion: security.istio.io/v1beta1
kind: ServiceRole kind: AuthorizationPolicy
metadata: metadata:
name: products-viewer-version name: allow-all
namespace: default namespace: default
spec: spec:
rules: rules:
- services: ["products.default.svc.cluster.local"] - {}
methods: ["GET", "HEAD"]
constraints:
- key: request.headers[version]
values: ["v1", "v2"]
{{< /text >}} {{< /text >}}
#### `ServiceRoleBinding` The example below shows a simple policy `deny-all` which denies access to all workloads
in the `admin` namespace.
A `ServiceRoleBinding` specification includes two parts:
- **`roleRef`** refers to a `ServiceRole` resource in the same namespace.
- A list of **`subjects`** that are assigned to the role.
You can either explicitly specify a *subject* with a `user` or with a set of
`properties`. A *property* in a `ServiceRoleBinding` *subject* is similar to
a *constraint* in a `ServiceRole` specification. A *property* also lets you use
conditions to specify a set of accounts assigned to this role. It contains a
`key` and its allowed *values*. The supported `key` values of a constraint
are listed in the
[constraints and properties page](/docs/reference/config/authorization/constraints-and-properties/).
The following example shows a `ServiceRoleBinding` named
`test-binding-products`, which binds two subjects to the `ServiceRole` named
`"product-viewer"` and has the following `subjects`
- A service account representing service **a**, `"service-account-a"`.
- A service account representing the Ingress service
`"istio-ingress-service-account"` **and** where the JWT `email` claim is
`"a@foo.com"`.
{{< text yaml >}} {{< text yaml >}}
apiVersion: "rbac.istio.io/v1alpha1" apiVersion: security.istio.io/v1beta1
kind: ServiceRoleBinding kind: AuthorizationPolicy
metadata: metadata:
name: test-binding-products name: deny-all
namespace: default namespace: admin
spec: spec:
subjects: {}
- user: "service-account-a"
- user: "istio-ingress-service-account"
properties:
request.auth.claims[email]: "a@foo.com"
roleRef:
kind: ServiceRole
name: "products-viewer"
{{< /text >}} {{< /text >}}
In case you want to make a service publicly accessible, you can set the #### Custom conditions
`subject` to `user: "*"`. This value assigns the `ServiceRole` to **all (both authenticated and
unauthenticated)** users and services, for example: You can also use the `when` section to specify additional conditions. For example, the following
`AuthorizationPolicy` definition includes a condition that `request.headers[version]` is either `"v1"` or `"v2"`.
In this case, the key is `request.headers[version]`, which is an entry in the Istio attribute `request.headers`,
which is a map.
{{< text yaml >}} {{< text yaml >}}
apiVersion: "rbac.istio.io/v1alpha1" apiVersion: security.istio.io/v1beta1
kind: ServiceRoleBinding kind: AuthorizationPolicy
metadata: metadata:
name: binding-products-allusers name: httpbin
namespace: default namespace: foo
spec: spec:
subjects: selector:
- user: "*" matchLabels:
roleRef: app: httpbin
kind: ServiceRole version: v1
name: "products-viewer" rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
to:
- operation:
methods: ["GET"]
when:
- key: request.headers[version]
values: ["v1", "v2"]
{{< /text >}} {{< /text >}}
To assign the `ServiceRole` to only **authenticated** users and services, use `source.principal: "*"` The supported `key` values of a condition are listed in the
instead, for example: [conditions page](/docs/reference/config/authorization/conditions/).
#### Authenticated and unauthenticated identity
If you want to make a workload publicly accessible, you need to leave the
`source` section empty. This allows sources from **all (both authenticated and
unauthenticated)** users and workloads, for example:
{{< text yaml >}} {{< text yaml >}}
apiVersion: "rbac.istio.io/v1alpha1" apiVersion: security.istio.io/v1beta1
kind: ServiceRoleBinding kind: AuthorizationPolicy
metadata: metadata:
name: binding-products-all-authenticated-users name: httpbin
namespace: default namespace: foo
spec: spec:
subjects: selector:
- properties: matchLabels:
source.principal: "*" app: httpbin
roleRef: version: v1
kind: ServiceRole rules:
name: "products-viewer" - to:
- operation:
methods: ["GET", "POST"]
{{< /text >}}
To allow only **authenticated** users, set `principal` to `"*"` instead, for example:
{{< text yaml >}}
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
version: v1
rules:
- from:
- source:
principals: ["*"]
to:
- operation:
methods: ["GET", "POST"]
{{< /text >}} {{< /text >}}
### Using Istio authorization on plain TCP protocols ### Using Istio authorization on plain TCP protocols
The examples in [Service role](#servicerole) and [Service role binding](#servicerolebinding) show the Istio authorization supports workloads using any plain TCP protocols, such as MongoDB. In this case,
typical way to use Istio authorization on services using the HTTP protocol. In those examples, all fields you configure the authorization policy in the same way you did for the HTTP workloads.
in a service role and service role binding are supported. The difference is that certain fields and conditions are only applicable to HTTP workloads.
Istio authorization supports services using any plain TCP protocols, such as MongoDB. In this case,
you configure the service roles and service role bindings in the same way you did for the HTTP service.
The difference is that certain fields, constraints and properties are only applicable to HTTP services.
These fields include: These fields include:
- The `paths` and `methods` fields in the service role configuration object. - The `request_principals` field in the source section of the authorization policy object
- The `group` field in the service role binding configuration object. - The `hosts`, `methods` and `paths` fields in the operation section of the authorization policy object
The supported constraints and properties are listed in the [constraints and properties page]( The supported conditions are listed in the [conditions page](/docs/reference/config/authorization/conditions/).
/docs/reference/config/authorization/constraints-and-properties/).
If you use any HTTP only fields for a TCP service, Istio ignores the service role or service role If you use any HTTP only fields for a TCP workload, Istio will ignore HTTP only fields in the
binding custom resources and the policies set within completely. authorization policy.
Assuming you have a MongoDB service on port 27017, the following example configures a service role and Assuming you have a MongoDB service on port 27017, the following example configures an authorization
a service role binding to only allow the `bookinfo-ratings-v2` in the Istio mesh to access the policy to only allow the `bookinfo-ratings-v2` service in the Istio mesh to access the MongoDB workload.
MongoDB service.
{{< text yaml >}} {{< text yaml >}}
apiVersion: "rbac.istio.io/v1alpha1" apiVersion: "security.istio.io/v1beta1"
kind: ServiceRole kind: AuthorizationPolicy
metadata: metadata:
name: mongodb-viewer name: mongodb-policy
namespace: default namespace: default
spec: spec:
rules: selector:
- services: ["mongodb.default.svc.cluster.local"] matchLabels:
constraints: app: mongodb
- key: "destination.port" rules:
values: ["27017"] - from:
--- - source:
apiVersion: "rbac.istio.io/v1alpha1" principals: ["cluster.local/ns/default/sa/bookinfo-ratings-v2"]
kind: ServiceRoleBinding to:
metadata: - operation:
name: bind-mongodb-viewer ports: ["27017"]
namespace: default
spec:
subjects:
- user: "cluster.local/ns/default/sa/bookinfo-ratings-v2"
roleRef:
kind: ServiceRole
name: "mongodb-viewer"
{{< /text >}}
### Authorization permissive mode
The authorization permissive mode is an experimental feature in Istio's 1.1 release. Its interface can change in future releases.
The authorization permissive mode allows you to verify authorization policies
before applying them in a production environment.
You can enable the authorization permissive mode on a global authorization
configuration and on individual policies. If you set the permissive mode on a global
authorization configuration, all policies switch to the permissive mode regardless
of their own set mode. If you set the global authorization mode to
`ENFORCED`, the enforcement mode set by the individual policies takes effect.
If you do not set a mode, both the global authorization configuration and the individual
policies are set to the `ENFORCED` mode by default.
To enable the permissive mode globally, set the value of the `enforcement_mode:` key in the global Istio RBAC authorization configuration to `PERMISSIVE` as shown in the following example.
{{< text yaml >}}
apiVersion: "rbac.istio.io/v1alpha1"
kind: ClusterRbacConfig
metadata:
name: default
spec:
mode: 'ON_WITH_INCLUSION'
inclusion:
namespaces: ["default"]
enforcement_mode: PERMISSIVE
{{< /text >}}
To enable the permissive mode for a specific policy, set the value of the `mode:` key to `PERMISSIVE` in the policy configuration file as shown in the following example.
{{< text yaml >}}
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
name: bind-details-reviews
namespace: default
spec:
subjects:
- user: "cluster.local/ns/default/sa/bookinfo-productpage"
roleRef:
kind: ServiceRole
name: "details-reviews-viewer"
mode: PERMISSIVE
{{< /text >}} {{< /text >}}
### Using other authorization mechanisms ### Using other authorization mechanisms

4
content/en/docs/ops/common-problems/security-issues/index.md
View File

@ -85,8 +85,8 @@ If authorization checks are enabled for a service and yet requests to the
service aren't being blocked, then authorization was likely not enabled service aren't being blocked, then authorization was likely not enabled
successfully. To verify, follow these steps: successfully. To verify, follow these steps:
1. Check the [enable authorization docs](/docs/concepts/security/#enabling-authorization) 1. Check the [authorization concept documentation](/docs/concepts/security/#authorization)
to correctly enable Istio authorization. to correctly apply Istio authorization.
1. Avoid enabling authorization for Istio Control Planes Components, including 1. Avoid enabling authorization for Istio Control Planes Components, including
Mixer, Pilot and Ingress. The Istio authorization features are designed for Mixer, Pilot and Ingress. The Istio authorization features are designed for

36
content/en/docs/reference/config/authorization/conditions/index.md Normal file
View File

@ -0,0 +1,36 @@
---
title: Conditions
description: Describes the supported conditions in authorization policies.
weight: 10
---
This page describes the supported keys and value formats you can use as conditions
in the `when` field of [authorization policy resources](/docs/reference/config/authorization/authorization-policy/).
{{< warning >}}
Unsupported keys and values are silently ignored.
{{< /warning >}}
For more information, refer to the [authorization concept page](/docs/concepts/security/#authorization).
## Supported Conditions
| Name | Description | Supported Protocols | Example |
|------|-------------|--------------------|---------|
| `request.headers` | HTTP request headers. The actual header name is surrounded by brackets | HTTP only | `key: request.headers[User-Agent]`<br/>`values: ["Mozilla/*"]` |
| `source.ip` | Source workload instance IP address, supports single IP or CIDR | HTTP and TCP | `key: source.ip`<br/>`values: ["10.1.2.3"]` |
| `source.namespace` | Source workload instance namespace | HTTP and TCP | `key: source.namespace`<br/>`values: ["default"]` |
| `source.principal` | The identity of the source workload | HTTP and TCP | `key: source.principal`<br/>`values: ["cluster.local/ns/default/sa/productpage"]` |
| `request.auth.principal` | The authenticated principal of the request. | HTTP only | `key: request.auth.principal`<br/>`values: ["accounts.my-svc.com/104958560606"]` |
| `request.auth.audiences` | The intended audience(s) for this authentication information | HTTP only | `key: request.auth.audiences`<br/>`values: ["my-svc.com"]` |
| `request.auth.presenter` | The authorized presenter of the credential | HTTP only | `key: request.auth.presenter`<br/>`values: ["123456789012.my-svc.com"]` |
| `request.auth.claims` | Claims from the origin JWT. The actual claim name is surrounded by brackets | HTTP only | `key: request.auth.claims[iss]`<br/>`values: ["*@foo.com"]` |
| `destination.ip` | Destination workload instance IP address, supports single IP or CIDR | HTTP and TCP | `key: destination.ip`<br/>`values: ["10.1.2.3", "10.2.0.0/16"]` |
| `destination.port` | The recipient port on the server IP address, must be in the range [0, 65535] | HTTP and TCP | `key: destination.port`<br/>`values: ["80", "443"]` |
| `connection.sni` | The server name indication | HTTP and TCP | `key: connection.sni`<br/>`values: ["www.example.com"]` |
| `experimental.envoy.filters.*` | Experimental metadata matching for filters, values wrapped in `[]` are matched as a list | HTTP and TCP | `key: experimental.envoy.filters.network.mysql_proxy[db.table]`<br/>`values: ["[update]"]` |
{{< warning >}}
No backward compatibility is guaranteed for the `experimental.*` keys. They may be removed
at any time, and customers are advised to use them at their own risk.
{{< /warning >}}

8
content/en/docs/reference/config/authorization/constraints-and-properties/index.md
View File

@ -1,9 +1,15 @@
--- ---
title: Constraints and Properties title: Constraints and Properties (deprecated)
description: Describes the supported constraints and properties. description: Describes the supported constraints and properties.
weight: 10 weight: 10
--- ---
{{< warning >}}
The constraints and properties in the RBAC policy are deprecated by the conditions in
the `AuthorizationPolicy`. Please use the conditions in `AuthorizationPolicy` resources,
this page is for reference only and will be removed in the future.
{{< /warning >}}
This section contains the supported keys and value formats you can use as constraints and properties This section contains the supported keys and value formats you can use as constraints and properties
in the service roles and service role bindings configuration objects. in the service roles and service role bindings configuration objects.
Constraints and properties are extra conditions you can add as fields in configuration objects with Constraints and properties are extra conditions you can add as fields in configuration objects with

2
content/zh/docs/ops/common-problems/security-issues/index.md
View File

@ -85,7 +85,7 @@ If authorization checks are enabled for a service and yet requests to the
service aren't being blocked, then authorization was likely not enabled service aren't being blocked, then authorization was likely not enabled
successfully. To verify, follow these steps: successfully. To verify, follow these steps:
1. Check the [enable authorization docs](/docs/concepts/security/#enabling-authorization) 1. Check the [authorization docs](/docs/concepts/security/#authorization)
to correctly enable Istio authorization. to correctly enable Istio authorization.
1. Avoid enabling authorization for Istio Control Planes Components, including 1. Avoid enabling authorization for Istio Control Planes Components, including