RBAC (deprecated)
Note: The v1alpha1 RBAC policy is deprecated by the v1beta1 Authorization policy. This page is kept for migration purpose and will be removed in Istio 1.6.
Istio RBAC (Role Based Access Control) defines ServiceRole and ServiceRoleBinding objects.
A ServiceRole specification includes a list of rules (permissions). Each rule has the following standard fields:
- services: a list of services.
- methods: A list of HTTP methods. You can set the value to
["*"]
to include all HTTP methods. This field should not be set for TCP services. The policy will be ignored. For gRPC services, onlyPOST
is allowed; other methods will result in denying services. - paths: HTTP paths or gRPC methods. Note that gRPC methods should be presented in the form of “/packageName.serviceName/methodName” and are case sensitive.
In addition to the standard fields, operators can also use custom keys in the constraints
field,
the supported keys are listed in the “constraints and properties” page.
Below is an example of ServiceRole object “product-viewer”, which has “read” (“GET” and “HEAD”) access to “products.svc.cluster.local” service at versions “v1” and “v2”. “path” is not specified, so it applies to any path in the service.
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
name: products-viewer
namespace: default
spec:
rules:
- services: ["products.svc.cluster.local"]
methods: ["GET", "HEAD"]
constraints:
- key: "destination.labels[version]"
values: ["v1", "v2"]
A ServiceRoleBinding specification includes two parts:
- The
roleRef
field that refers to a ServiceRole object in the same namespace. - A list of
subjects
that are assigned the roles.
In addition to a simple user
field, operators can also use custom keys in the properties
field,
the supported keys are listed in the “constraints and properties” page.
Below is an example of ServiceRoleBinding object “test-binding-products”, which binds two subjects to ServiceRole “product-viewer”:
- User “alice@yahoo.com”
- Services in “abc” namespace.
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
name: test-binding-products
namespace: default
spec:
subjects:
- user: alice@yahoo.com
- properties:
source.namespace: "abc"
roleRef:
kind: ServiceRole
name: "products-viewer"
AccessRule
AccessRule defines a permission to access a list of services.
AccessRule.Constraint
Definition of a custom constraint. The supported keys are listed in the “constraint and properties” page.
RbacConfig
RbacConfig implements the ClusterRbacConfig Custom Resource Definition for controlling Istio RBAC behavior.
The ClusterRbacConfig Custom Resource is a singleton where only one ClusterRbacConfig should be created
globally in the mesh and the namespace should be the same to other Istio components, which usually is istio-system
.
Below is an example of an ClusterRbacConfig
resource called istio-rbac-config
which enables Istio RBAC for all
services in the default namespace.
apiVersion: "rbac.istio.io/v1alpha1"
kind: ClusterRbacConfig
metadata:
name: default
namespace: istio-system
spec:
mode: ON_WITH_INCLUSION
inclusion:
namespaces: [ "default" ]
RbacConfig.Mode
Name | Description |
---|---|
OFF | Disable Istio RBAC completely, Istio RBAC policies will not be enforced. |
ON | Enable Istio RBAC for all services and namespaces. Note Istio RBAC is deny-by-default which means all requests will be denied if it’s not allowed by RBAC rules. |
ON_WITH_INCLUSION | Enable Istio RBAC only for services and namespaces specified in the inclusion field. Any other services and namespaces not in the inclusion field will not be enforced by Istio RBAC policies. |
ON_WITH_EXCLUSION | Enable Istio RBAC for all services and namespaces except those specified in the exclusion field. Any other services and namespaces not in the exclusion field will be enforced by Istio RBAC policies. |
RbacConfig.Target
Target defines a list of services or namespaces.
RoleRef
RoleRef refers to a role object.
ServiceRole
ServiceRole specification contains a list of access rules (permissions).
ServiceRoleBinding
ServiceRoleBinding assigns a ServiceRole to a list of subjects.
Subject
Subject defines an identity. The identity is either a user or identified by a set of properties
.
The supported keys in properties
are listed in “constraint and properties” page.