• RBAC (deprecated)
    • AccessRule
    • AccessRule.Constraint
    • RbacConfig
    • RbacConfig.Mode
    • RbacConfig.Target
    • RoleRef
    • ServiceRole
    • ServiceRoleBinding
    • Subject

    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 ServiceRoleBindingobjects.

    A ServiceRole specification includes a list of rules (permissions). Each rule hasthe 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, only POST is allowed; other methods will result in denying services.
    • paths: HTTP paths or gRPC methods. Note that gRPC methods should bepresented 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.

    1. apiVersion: "rbac.istio.io/v1alpha1"
    2. kind: ServiceRole
    3. metadata:
    4.   name: products-viewer
    5.   namespace: default
    6. spec:
    7.   rules:
    8.   - services: ["products.svc.cluster.local"]
    9.     methods: ["GET", "HEAD"]
    10.     constraints:
    11.     - key: "destination.labels[version]"
    12.       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 subjectsto ServiceRole “product-viewer”:

    • User “alice@yahoo.com”
    • Services in “abc” namespace.
    1. apiVersion: "rbac.istio.io/v1alpha1"
    2. kind: ServiceRoleBinding
    3. metadata:
    4.   name: test-binding-products
    5.   namespace: default
    6. spec:
    7.   subjects:
    8.   - user: alice@yahoo.com
    9.   - properties:
    10.       source.namespace: "abc"
    11.   roleRef:
    12.     kind: ServiceRole
    13.     name: "products-viewer"

    AccessRule

    AccessRule defines a permission to access a list of services.

    FieldTypeDescriptionRequired
    servicesstring[]A list of service names.Exact match, prefix match, and suffix match are supported for service names.For example, the service name “bookstore.mtv.cluster.local” matches“bookstore.mtv.cluster.local” (exact match), or “bookstore” (prefix match),or “.mtv.cluster.local” (suffix match).If set to [””], it refers to all services in the namespace.Yes
    pathsstring[]Optional. A list of HTTP paths or gRPC methods.gRPC methods must be presented as fully-qualified name in the form of“/packageName.serviceName/methodName” and are case sensitive.Exact match, prefix match, and suffix match are supported. For example,the path “/books/review” matches “/books/review” (exact match),or “/books/” (prefix match), or “/review” (suffix match).If not specified, it matches to any path.This field should not be set for TCP services. The policy will be ignored.No
    methodsstring[]Optional. A list of HTTP methods (e.g., “GET”, “POST”).If not specified or specified as “”, it matches to any methods.This field should not be set for TCP services. The policy will be ignored.For gRPC services, only POST is allowed; other methods will result in denying services.No
    constraintsConstraint[]Optional. Extra constraints in the ServiceRole specification.No

    AccessRule.Constraint

    Definition of a custom constraint. The supported keys are listed in the “constraint and properties” page.

    FieldTypeDescriptionRequired
    keystringKey of the constraint.No
    valuesstring[]List of valid values for the constraint.Exact match, prefix match, and suffix match are supported.For example, the value “v1alpha2” matches “v1alpha2” (exact match),or “v1” (prefix match), or “alpha2” (suffix match).No

    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 createdglobally 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 allservices in the default namespace.

    1. apiVersion: "rbac.istio.io/v1alpha1"
    2. kind: ClusterRbacConfig
    3. metadata:
    4.   name: default
    5.   namespace: istio-system
    6. spec:
    7.   mode: ON_WITH_INCLUSION
    8.   inclusion:
    9.     namespaces: [ "default" ]
    FieldTypeDescriptionRequired
    modeModeIstio RBAC mode.No
    inclusionTargetA list of services or namespaces that should be enforced by Istio RBAC policies. Note: This field haveeffect only when mode is ON_WITH_INCLUSION and will be ignored for any other modes.No
    exclusionTargetA list of services or namespaces that should not be enforced by Istio RBAC policies. Note: This field haveeffect only when mode is ON_WITH_EXCLUSION and will be ignored for any other modes.No

    RbacConfig.Mode

    NameDescription
    OFFDisable Istio RBAC completely, Istio RBAC policies will not be enforced.
    ONEnable Istio RBAC for all services and namespaces. Note Istio RBAC is deny-by-defaultwhich means all requests will be denied if it’s not allowed by RBAC rules.
    ON_WITH_INCLUSIONEnable Istio RBAC only for services and namespaces specified in the inclusion field. Any otherservices and namespaces not in the inclusion field will not be enforced by Istio RBAC policies.
    ON_WITH_EXCLUSIONEnable Istio RBAC for all services and namespaces except those specified in the exclusion field. Any otherservices and namespaces not in the exclusion field will be enforced by Istio RBAC policies.

    RbacConfig.Target

    Target defines a list of services or namespaces.

    FieldTypeDescriptionRequired
    servicesstring[]A list of services.No
    namespacesstring[]A list of namespaces.No

    RoleRef

    RoleRef refers to a role object.

    FieldTypeDescriptionRequired
    kindstringThe type of the role being referenced.Currently, “ServiceRole” is the only supported value for “kind”.Yes
    namestringThe name of the ServiceRole object being referenced.The ServiceRole object must be in the same namespace as the ServiceRoleBinding object.Yes

    ServiceRole

    ServiceRole specification contains a list of access rules (permissions).

    FieldTypeDescriptionRequired
    rulesAccessRule[]The set of access rules (permissions) that the role has.Yes

    ServiceRoleBinding

    ServiceRoleBinding assigns a ServiceRole to a list of subjects.

    FieldTypeDescriptionRequired
    subjectsSubject[]List of subjects that are assigned the ServiceRole object.Yes
    roleRefRoleRefReference to the ServiceRole object.Yes

    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.

    FieldTypeDescriptionRequired
    userstringOptional. The user name/ID that the subject represents.No
    propertiesmap<string, string>Optional. The set of properties that identify the subject.No