mirror of https://github.com/istio/istio.io.git
rbac: update concept and reference for RBAC tcp. (#2612)
This commit is contained in:
Yangmin Zhu
Martin Taillefer
parent
701a9879a5
commit
5cb7c13a8e
|
|
@ -517,6 +517,7 @@ services in an Istio Mesh. It features:
|
|||
- **Flexibility through custom properties support**, for example conditions,
|
||||
in roles and role-bindings.
|
||||
- **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.
|
||||
|
||||
### Authorization architecture
|
||||
|
||||
|
|
@ -654,9 +655,8 @@ Each rule has the following standard fields:
|
|||
form of `/packageName.serviceName/methodName` and are case sensitive.
|
||||
|
||||
A `ServiceRole` specification only applies to the namespace specified in the
|
||||
`metadata` section. The `services` and `methods` fields are required in a
|
||||
rule. `paths` is optional. If a rule is not specified or if it is set to `*`,
|
||||
it applies to any instance.
|
||||
`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.
|
||||
|
|
@ -670,7 +670,6 @@ metadata:
|
|||
spec:
|
||||
rules:
|
||||
- services: ["*"]
|
||||
methods: ["*"]
|
||||
{{< /text >}}
|
||||
|
||||
Here is another role: `products-viewer`, which has read, `"GET"` and `"HEAD"`,
|
||||
|
|
@ -820,6 +819,56 @@ spec:
|
|||
name: "products-viewer"
|
||||
{{< /text >}}
|
||||
|
||||
### Using Istio authorization on plain TCP protocols
|
||||
|
||||
The examples in [Service role](#servicerole) and [Service role binding](#servicerolebinding) show the
|
||||
typical way to use Istio authorization on services using the HTTP protocol. In those examples, all fields
|
||||
in a service role and service role binding are supported.
|
||||
|
||||
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:
|
||||
|
||||
- The `paths` and `methods` fields in the service role configuration object.
|
||||
- The `group` field in the service role binding configuration object.
|
||||
|
||||
The supported constraints and properties are listed in the [constraints and properties page](
|
||||
/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
|
||||
binding custom resources and the policies set within completely.
|
||||
|
||||
Assuming you have a MongoDB service on port 27017, the following example configures a service role and
|
||||
a service role binding to only allow the `bookinfo-ratings-v2` in the Istio mesh to access the
|
||||
MongoDB service.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "rbac.istio.io/v1alpha1"
|
||||
kind: ServiceRole
|
||||
metadata:
|
||||
name: mongodb-viewer
|
||||
namespace: default
|
||||
spec:
|
||||
rules:
|
||||
- services: ["mongodb.default.svc.cluster.local"]
|
||||
constraints:
|
||||
- key: "destination.port"
|
||||
values: ["27017"]
|
||||
---
|
||||
apiVersion: "rbac.istio.io/v1alpha1"
|
||||
kind: ServiceRoleBinding
|
||||
metadata:
|
||||
name: bind-mongodb-viewer
|
||||
namespace: default
|
||||
spec:
|
||||
subjects:
|
||||
- user: "cluster.local/ns/default/sa/bookinfo-ratings-v2"
|
||||
roleRef:
|
||||
kind: ServiceRole
|
||||
name: "mongodb-viewer"
|
||||
{{< /text >}}
|
||||
|
||||
### Using other authorization mechanisms
|
||||
|
||||
While we strongly recommend using the Istio authorization mechanisms,
|
||||
|
|
|
|||
|
|
@ -4,35 +4,44 @@ description: Describes the supported constraints and properties.
|
|||
weight: 10
|
||||
---
|
||||
|
||||
This page lists the supported keys that could be used in `Constraints` and `Properties`.
|
||||
`Constraints` are used to specify additional custom conditions in a `ServiceRole`, `Properties` are used to specify
|
||||
additional custom conditions in a `ServiceRoleBinding`. For more information, please refer to [authorization concept page](/docs/concepts/security/#authorization).
|
||||
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.
|
||||
|
||||
## Constraints
|
||||
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.
|
||||
|
||||
The following table lists the currently supported keys in Constraints:
|
||||
> {{< warning_icon >}} Unsupported keys and values will be ignored silently.
|
||||
|
||||
| Name | Description | Key Example | Values Example |
|
||||
|------|-------------|-------------|----------------|
|
||||
| `destination.ip` | Destination workload instance IP address, supports single IP or CIDR | `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] | `destination.port` | `["80", "443"]` |
|
||||
| `destination.labels` | A map of key-value pairs attached to the server instance | `destination.labels[version]` | `["v1", "v2"]` |
|
||||
| `destination.name` | Destination workload instance name | `destination.name` | `["productpage*", "*-test"]` |
|
||||
| `destination.namespace` | Destination workload instance namespace | `destination.namespace` | `["default"]` |
|
||||
| `destination.user` | The identity of the destination workload | `destination.user` | `["bookinfo-productpage"]` |
|
||||
| `request.headers` | HTTP request headers, The actual header name is surrounded by brackets | `request.headers[X-Custom-Token]` | `["abc123"]` |
|
||||
For more information, refer to the [authorization concept page](/docs/concepts/security/#authorization).
|
||||
|
||||
## Properties
|
||||
## Supported Constraints
|
||||
|
||||
The following table lists the currently supported keys in Properties:
|
||||
The following table lists the currently supported keys for the `constraints` field:
|
||||
|
||||
| Name | Description | Key Example | Value Example |
|
||||
|------|-------------|-------------|---------------|
|
||||
| `source.ip` | Source workload instance IP address, supports single IP or CIDR | `source.ip` | `"10.1.2.3"` |
|
||||
| `source.namespace` | Source workload instance namespace | `source.namespace` | `"default"` |
|
||||
| `source.principal` | The identity of the source workload | `source.principal` | `"cluster.local/ns/default/sa/productpage"` |
|
||||
| `request.headers` | HTTP request headers. The actual header name is surrounded by brackets | `request.headers[User-Agent]` | `"Mozilla/*"` |
|
||||
| `request.auth.principal` | The authenticated principal of the request. | `request.auth.principal` | `"accounts.my-svc.com/104958560606"` |
|
||||
| `request.auth.audiences` | The intended audience(s) for this authentication information | `request.auth.audiences` | `"my-svc.com"` |
|
||||
| `request.auth.presenter` | The authorized presenter of the credential | `request.auth.presenter` | `"123456789012.my-svc.com"` |
|
||||
| `request.auth.claims` | Claims from the origin JWT. The actual claim name is surrounded by brackets | `request.auth.claims[iss]` | `"*@foo.com"` |
|
||||
| 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.name` | Destination workload instance name | YES | `destination.name` | `["productpage*", "*-test"]` |
|
||||
| `destination.namespace` | Destination workload instance namespace | YES | `destination.namespace` | `["default"]` |
|
||||
| `destination.user` | The identity of the destination workload | YES | `destination.user` | `["bookinfo-productpage"]` |
|
||||
| `request.headers` | HTTP request headers, The actual header name is surrounded by brackets | NO | `request.headers[X-Custom-Token]` | `["abc123"]` |
|
||||
|
||||
## 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"` |
|
||||
|
|
|
|||
|
|
@ -3,5 +3,5 @@ title: Does Istio support authorization?
|
|||
weight: 110
|
||||
---
|
||||
|
||||
Yes. Istio provides authorization features for services in the mesh.
|
||||
Yes. Istio provides authorization features for both HTTP and plain TCP services in the mesh.
|
||||
[Learn more](/docs/concepts/security/#authorization).
|
||||
|
|
|
|||
|
|
@ -13,6 +13,9 @@ matching requests should flow through. If all requests continue to be denied, yo
|
|||
|
||||
1. Make sure that your `ServiceRoleBinding` and referred `ServiceRole` objects are in the same namespace (by checking "metadata"/”namespace” line).
|
||||
|
||||
1. Make sure that your service role and service role binding policies don't use any HTTP only fields
|
||||
for TCP services. Otherwise, Istio ignores the policies as if they didn't exist.
|
||||
|
||||
1. In Kubernetes environment, make sure all services in a `ServiceRole` object are in the same namespace as the
|
||||
`ServiceRole` itself. For example, if a service in a `ServiceRole` object is `a.default.svc.cluster.local`, the `ServiceRole` must be in the
|
||||
`default` namespace (`metadata/namespace` line should be `default`). For non-Kubernetes environments, all `ServiceRoles` and `ServiceRoleBindings`
|
||||
|
|
|
|||
Loading…
Reference in New Issue