apps-on-azure

Lab Solution

Kube-explorer RBAC

First confirm the app doesn’t have access to ServiceAccount objects:

kubectl auth can-i get serviceaccounts -n default --as system:serviceaccount:default:kube-explorer

This spec contains the new permissions:

You could also amend the original Role, but that would mean any other principals using that role would also get the new permission.

kubectl apply -f labs/rbac/solution/service-account-viewer.yaml

kubectl auth can-i get serviceaccounts -n default --as system:serviceaccount:default:kube-explorer

Now the app has the permissions it needs, the Service Account link works (e.g. http://localhost:30010/ServiceAccounts), but only for the default namespace. You should still get a 403 error if you try to view ServiceAccounts in another namespace (http://localhost:30010/ServiceAccounts?ns=kube-system)

Securing the sleep Deployment

First verify the original sleep Pod does have the SA token mounted:

kubectl exec deploy/sleep -- cat /var/run/secrets/kubernetes.io/serviceaccount/token

The simplest way to fix it is with the automountServiceAccountToken field in the Pod spec:

kubectl apply -f labs/rbac/solution/sleep-without-sa-token.yaml

kubectl wait --for=condition=Ready pod -l app=sleep,sa-token=none

kubectl exec deploy/sleep -- cat /var/run/secrets/kubernetes.io/serviceaccount/token

Every Pod runs in the context of a ServiceAccount - check and you’ll see this one uses the default SA:

kubectl get pod -l app=sleep,sa-token=none -o jsonpath='{.items[0].spec.serviceAccountName}'

A better approach is to use a custom ServiceAccount with automountServiceAccountToken set at the SA level.

Any app which doesn’t use the API server can use this SA - apps which do use the API server will each have their own SA with the permissions the app needs.

Back to the exercises.