Authentication means verifying the identity of a client. Authorization, on the other hand, verifies the permissions of that client, or: “can this service do what they’re asking to do?”

Kubernetes supports authorization through role-based access control (RBAC). In this model, you can map a role (a set of permissions) to a role binding (who exactly has these permissions?).

Istio uses RBAC to allow you to set authorization policies between services in your cluster. Let’s see how.

Here, the ShoeStore application is deployed to the default Kubernetes namespace. There are three services, and all speak plain HTTP:

  1. shoes: exposes an API for all the shoes in the store
  2. users: stores purchase history
  3. inventory: loads new shoe models into shoes.

shoes rbac

We want to authorize inventory to be able to POST new inventory to shoes, but not be able to access users at all. To do this, we will need three Istio resources.

First, we need to enable authorization for the default Kubernetes namespace:

apiVersion: "rbac.istio.io/v1alpha1"
kind: ClusterRbacConfig
  name: default
    namespaces: ["default"]

Second, we’ll define our ServiceRole, the abstract set of permissions to POST data to the shoes service:

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
  name: shoes-user
  namespace: default
  - services: ["shoes.default.svc.cluster.local"]
    methods: ["POST"]

Lastly, we’ll bind this abstract shoes-user role to a concrete set of subjects — in this case, any request that has the hello:world HTTP header.

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
  name: shoes-user-binding
  namespace: default
  - properties:
      request.headers[hello]: "world"
    kind: ServiceRole
    name: "shoes-user"

From here, the inventory service can only make requests to shoes with the hello:world header, and the users service is still locked down. This is because RBAC is on, but we haven’t assigned any ServiceRoles to access the users service.

To learn more: