Once someone has been authenticated, what they can or cannot do depends upon authorization. Mixer plays an important role in authorization enablement in Istio. Let's learn about authorization through some examples:
- First, let's switch to subset v2 of the reviews
virtual service so that it shows black stars in the ratings (remember: review-1: no star, review-2: black stars, review-3: red stars(:
$ kubectl -n istio-lab patch vs reviews --type json -p '[{"op":"replace","path":"/spec/http/0/route/0/destination/subset","value": "v2"}]'
virtualservice.networking.istio.io/ratings patched
$ kubectl -n istio-lab get vs reviews -o yaml | grep -B1 subset:
host: reviews
subset: v2
- Refresh https://bookinfo.istio.io/productpage. You should see black stars in the ratings.
Authorization can be enabled by defining the ClusterRbacConfig object. The name of the object must be a default,
and there can only be one instance of ClusterRbacConfig.
- Define ClusterRbacConfig for the istio-lab namespace:
# Script : 09-create-clusterrbac-config.yaml
apiVersion: "rbac.istio.io/v1alpha1"
kind: ClusterRbacConfig
metadata:
name: default
spec:
mode: 'ON_WITH_INCLUSION'
inclusion:
namespaces: ["istio-lab"]
- Create default ClusterRbacConfig for enabling Istio authorization for services defined in an istio-lab namespace:
$ kubectl -n istio-lab apply -f 09-create-clusterrbac-config.yaml
clusterrbacconfig.rbac.istio.io/default created
- Wait for a few seconds for the rule to propagate. Point your browser to https://bookinfo.istio.io/productpage. You should see a message stating RBAC: access denied.
If necessary, clear your cache if the page doesn't load.
With this, deny access to all and then only allow access to users, groups, or roles to edge services and to service accounts for internal services.
Next, we will go through authorization at the namespace level so that each microservice that's defined in that namespace inherits the same authorization.