From ccf7e68471e2f193666a23aec1ee372258404295 Mon Sep 17 00:00:00 2001 From: Yangmin Zhu Date: Fri, 27 Mar 2020 13:58:46 -0700 Subject: [PATCH] remove v1alpha1 RBAC page (#6989) --- .../en/blog/2018/istio-authorization/index.md | 4 +- .../config/security/conditions/index.md | 5 +- .../constraints-and-properties/index.md | 62 ------------------- 3 files changed, 3 insertions(+), 68 deletions(-) delete mode 100644 content/en/docs/reference/config/security/constraints-and-properties/index.md diff --git a/content/en/blog/2018/istio-authorization/index.md b/content/en/blog/2018/istio-authorization/index.md index 49d5f9e2c2..c5ac023270 100644 --- a/content/en/blog/2018/istio-authorization/index.md +++ b/content/en/blog/2018/istio-authorization/index.md @@ -18,7 +18,7 @@ provides micro-segmentation for services in an Istio mesh. It features: * High performance, as it is enforced natively on Envoy. * Role-based semantics, which makes it easy to use. * High flexibility as it allows users to define conditions using -[combinations of attributes](/docs/reference/config/security/constraints-and-properties/). +[combinations of attributes](/docs/reference/config/security/conditions/). In this blog post, you'll learn about the main authorization features and how to use them in different situations. @@ -49,7 +49,7 @@ frontend service. duplicate configurations in multiple places and later forget to update some of them when you need to make changes. On the other hand, Istio's authorization system is not a traditional RBAC system. It also allows users to define **conditions** using -[combinations of attributes](/docs/reference/config/security/constraints-and-properties/). This gives Istio +[combinations of attributes](/docs/reference/config/security/conditions/). This gives Istio flexibility to express complex access control policies. In fact, **the "RBAC + conditions” model that Istio authorization adopts, has all the benefits an RBAC system has, and supports the level of flexibility that normally an ABAC system provides.** You'll see some [examples](#examples) below. diff --git a/content/en/docs/reference/config/security/conditions/index.md b/content/en/docs/reference/config/security/conditions/index.md index e953dfafdd..88cdb5a5ec 100644 --- a/content/en/docs/reference/config/security/conditions/index.md +++ b/content/en/docs/reference/config/security/conditions/index.md @@ -4,15 +4,12 @@ description: Describes the supported conditions in authorization policies. weight: 30 aliases: - /docs/reference/config/security/conditions/ + - /docs/reference/config/security/constraints-and-properties/ --- This page describes the supported keys and value formats you can use as conditions in the `when` field of an [authorization policy rule](/docs/reference/config/security/authorization-policy/#Rule). -{{< warning >}} -Unsupported keys and values are silently ignored. -{{< /warning >}} - For more information, refer to the [authorization concept page](/docs/concepts/security/#authorization). ## Supported Conditions diff --git a/content/en/docs/reference/config/security/constraints-and-properties/index.md b/content/en/docs/reference/config/security/constraints-and-properties/index.md deleted file mode 100644 index 18e75dc92d..0000000000 --- a/content/en/docs/reference/config/security/constraints-and-properties/index.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: RBAC Constraints and Properties (deprecated) -description: Describes the supported constraints and properties. -weight: 50 -aliases: - - /docs/reference/config/security/constraints-and-properties/ ---- - -{{< 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 -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 -a `kind:` value of `ServiceRole` and `ServiceRoleBinding` to specify detailed access control requirements. - -Specifically, you can use constraints to specify extra conditions in the access rule field of a service -role. You can use properties to specify extra conditions in the subject field of a service role binding. -Istio supports all keys listed on this page for the HTTP protocol but supports only some for the plain TCP protocol. - -{{< warning >}} -Unsupported keys and values will be ignored silently. -{{< /warning >}} - -For more information, refer to the [authorization concept page](/docs/concepts/security/#authorization). - -## Supported constraints - -The following table lists the currently supported keys for the `constraints` field: - -| Name | Description | Supported for TCP services | Key Example | Values Example | -|------|-------------|----------------------------|-------------|----------------| -| `destination.ip` | Destination workload instance IP address, supports single IP or CIDR | YES | `destination.ip` | `["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] | YES | `destination.port` | `["80", "443"]` | -| `destination.labels` | A map of key-value pairs attached to the server instance | YES | `destination.labels[version]` | `["v1", "v2"]` | -| `destination.namespace` | Destination workload instance namespace | YES | `destination.namespace` | `["default"]` | -| `destination.user` | The identity of the destination workload | YES | `destination.user` | `["bookinfo-productpage"]` | -| `experimental.envoy.filters.*` | Experimental metadata matching for filters, values wrapped in `[]` are matched as a list | YES | `experimental.envoy.filters.network.mysql_proxy[db.table]` | `["[update]"]` | -| `request.headers` | HTTP request headers, The actual header name is surrounded by brackets | NO | `request.headers[X-Custom-Token]` | `["abc123"]` | - -{{< warning >}} -Note that 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 >}} - -## Supported properties - -The following table lists the currently supported keys for the `properties` field: - -| Name | Description | Supported for TCP services | Key Example | Value Example | -|------|-------------|----------------------------|-------------|---------------| -| `source.ip` | Source workload instance IP address, supports single IP or CIDR | YES | `source.ip` | `"10.1.2.3"` | -| `source.namespace` | Source workload instance namespace | YES | `source.namespace` | `"default"` | -| `source.principal` | The identity of the source workload | YES | `source.principal` | `"cluster.local/ns/default/sa/productpage"` | -| `request.headers` | HTTP request headers. The actual header name is surrounded by brackets | NO | `request.headers[User-Agent]` | `"Mozilla/*"` | -| `request.auth.principal` | The authenticated principal of the request. | NO | `request.auth.principal` | `"accounts.my-svc.com/104958560606"` | -| `request.auth.audiences` | The intended audience(s) for this authentication information | NO | `request.auth.audiences` | `"my-svc.com"` | -| `request.auth.presenter` | The authorized presenter of the credential | NO | `request.auth.presenter` | `"123456789012.my-svc.com"` | -| `request.auth.claims` | Claims from the origin JWT. The actual claim name is surrounded by brackets | NO | `request.auth.claims[iss]` | `"*@foo.com"` |