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:
shoes: exposes an API for all the shoes in the store
users: stores purchase history
inventory: loads new shoe models into
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 metadata: name: default spec: mode: 'ON_WITH_INCLUSION' inclusion: namespaces: ["default"]
Second, we’ll define our
ServiceRole, the abstract set of permissions to
POST data to the
apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRole metadata: name: shoes-user namespace: default spec: rules: - 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 metadata: name: shoes-user-binding namespace: default spec: subjects: - properties: request.headers[hello]: "world" roleRef: 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
To learn more: