Role-based Access Control (RBAC)
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-explorerThis spec contains the new permissions:
- service-account-viewer.yaml - a Role with rules to get and list ServiceAccounts, and a RoleBinding applying it to the app's ServiceAccount
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-explorerNow 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/tokenThe 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/tokenEvery 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.
- sleep-with-no-token-sa.yaml - a new SA and Pod configured to use it
Back to the exercises.