Istio Role-Based Access Control (RBAC)
Istio Role-Based Access Control (RBAC) provides namespace-level, service-level, method-level access control for services in Istio Mesh. It features:
- Role-Based semantics, which is simple and easy to use.
- Service-to-service and endUser-to-Service authorization.
- Flexibility through custom properties support in roles and role-bindings.
The diagram below shows Istio RBAC architecture. The admins specify Istio RBAC policies. The policies are saved in Istio config store.
Istio RBAC Architecture
Istio RBAC engine does two things:
- Fetch RBAC policy. Istio RBAC engine watches for changes on RBAC policy. It fetches the updated RBAC policy if it sees any changes.
- Authorize Requests. At runtime, when a request comes, the request context is passed to Istio RBAC engine. RBAC engine evaluates the request context against the RBAC policies, and returns the authorization result (ALLOW or DENY).
In the current release, Istio RBAC engine is implemented as a Mixer adapter. The request context is provided as an instance of the authorization template. The request context contains all the information about the request and the environment that an authorization module needs to know. In particular, it has two parts:
- subject contains a list of properties that identify the caller identity, including
"groups"the subject belongs to, or any additional properties about the subject such as namespace, service name.
- action specifies “how a service is accessed”. It includes
"method"that the action is being taken on, and any additional properties about the action.
Below we show an example “requestcontext”.
apiVersion: "config.istio.io/v1alpha2" kind: authorization metadata: name: requestcontext namespace: istio-system spec: subject: user: source.user | "" groups: "" properties: service: source.service | "" namespace: source.namespace | "" action: namespace: destination.namespace | "" service: destination.service | "" method: request.method | "" path: request.path | "" properties: version: request.headers["version"] | ""
Istio RBAC Policy
Istio RBAC introduces ServiceRole and ServiceRoleBinding, both of which are defined as Kubernetes CustomResourceDefinition (CRD) objects.
- ServiceRole defines a role for access to services in the mesh.
- ServiceRoleBinding grants a role to subjects (e.g., a user, a group, a service).
A ServiceRole specification includes a list of rules. Each rule has the following standard fields:
- services: A list of service names, which are matched against the
action.servicefield of the “requestcontext”.
- methods: A list of method names which are matched against the
action.methodfield of the “requestcontext”. In the above “requestcontext”, this is the HTTP or gRPC method. Note that gRPC methods are formatted in the form of “packageName.serviceName/methodName” (case sensitive).
- paths: A list of HTTP paths which are matched against the
action.pathfield of the “requestcontext”. It is ignored in gRPC case.
A ServiceRole specification only applies to the namespace specified in
"metadata" section. The “services” and “methods” are required fields in a rule. “paths” is optional. If not specified or set to “*”, it applies to “any” instance.
Here is an example of a simple role “service-admin”, which has full access to all services in “default” namespace.
apiVersion: "config.istio.io/v1alpha2" kind: ServiceRole metadata: name: service-admin namespace: default spec: rules: - services: ["*"] methods: ["*"]
Here is another role “products-viewer”, which has read (“GET” and “HEAD”) access to “products” service in “default” namespace.
apiVersion: "config.istio.io/v1alpha2" kind: ServiceRole metadata: name: products-viewer namespace: default spec: rules: - services: ["products"] methods: ["GET", "HEAD"]
In addition, we support prefix match and suffix match for all the fields in a rule. For example, you can define a “tester” role that has the following permissions in “default” namespace:
- Full access to all services with prefix “test-“ (e.g, “test-bookstore”, “test-performance”, “test-api.default.svc.cluster.local”).
- Read (“GET”) access to all paths with “/reviews” suffix (e.g, “/books/reviews”, “/events/booksale/reviews”, “/reviews”) in “bookstore” service.
apiVersion: "config.istio.io/v1alpha2" kind: ServiceRole metadata: name: tester namespace: default spec: rules: - services: ["test-*"] methods: ["*"] - services: ["bookstore"] paths: ["*/reviews"] methods: ["GET"]
In ServiceRole, the combination of “namespace”+”services”+”paths”+”methods” defines “how a service (services) is allowed to be accessed”. In some situations, you may need to specify additional constraints that a rule applies to. For example, a rule may only applies to a certain “version” of a service, or only applies to services that are labeled “foo”. You can easily specify these constraints using custom fields.
For example, the following ServiceRole definition extends the previous “products-viewer” role by adding a constraint on service “version” being “v1” or “v2”. Note that the “version” property is provided by
"action.properties.version" in “requestcontext”.
apiVersion: "config.istio.io/v1alpha2" kind: ServiceRole metadata: name: products-viewer-version namespace: default spec: rules: - services: ["products"] methods: ["GET", "HEAD"] constraints: - key: "version" values: ["v1", "v2"]
A ServiceRoleBinding specification includes two parts:
- roleRef refers to a ServiceRole object in the same namespace.
- A list of subjects that are assigned the role.
A subject can either be a “user”, or a “group”, or is represented with a set of “properties”. Each entry (“user” or “group” or an entry in “properties”) must match one of fields (“user” or “groups” or an entry in “properties”) in the “subject” part of the “requestcontext” instance.
Here is an example of ServiceRoleBinding object “test-binding-products”, which binds two subjects to ServiceRole “product-viewer”:
- user “firstname.lastname@example.org”.
- “reviews” service in “abc” namespace.
apiVersion: "config.istio.io/v1alpha2" kind: ServiceRoleBinding metadata: name: test-binding-products namespace: default spec: subjects: - user: "email@example.com" - properties: service: "reviews" namespace: "abc" roleRef: kind: ServiceRole name: "products-viewer"
In the case that you want to make a service(s) publically accessible, you can use set the subject to
user: "*". This will assign a ServiceRole to all users/services.
apiVersion: "config.istio.io/v1alpha2" kind: ServiceRoleBinding metadata: name: binding-products-allusers namespace: default spec: subjects: - user: "*" roleRef: kind: ServiceRole name: "products-viewer"
Enabling Istio RBAC
Istio RBAC can be enabled by adding the following Mixer adapter rule. The rule has two parts. The first part defines a RBAC handler. It has two parameters,
"config_store_url"parameter specifies where RBAC engine fetches RBAC policies. The default value for
"k8s://", which means Kubernetes API server. Alternatively, if you are testing RBAC policy locally, you may set it to a local directory such as
"cache_duration"parameter specifies the duration for which the authorization results may be cached on Mixer client (i.e., Istio proxy). The default value for
"cache_duration"is 1 minute.
The second part defines a rule, which specifies that the RBAC handler should be invoked with the “requestcontext” instance defined earlier in the document.
In the following example, Istio RBAC is enabled for “default” namespace. And the cache duration is set to 30 seconds.
apiVersion: "config.istio.io/v1alpha2" kind: rbac metadata: name: handler namespace: istio-system spec: config_store_url: "k8s://" cache_duration: "30s" --- apiVersion: "config.istio.io/v1alpha2" kind: rule metadata: name: rbaccheck namespace: istio-system spec: match: destination.namespace == "default" actions: # handler and instance names default to the rule's namespace. - handler: handler.rbac instances: - requestcontext.authorization ---
Try out Istio RBAC with BookInfo Sample.