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)
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.