labs

Bu lab henuz cevrilmedi - Ingilizce surumu gosteriliyor.
Bu lab modernize edildi ama ucтan uca dogrulanmadi. Takilirsaniz bize bildirin.

Role-based Access Control (RBAC)

50 dkkubernetesGitHub'da gor
Bu sayfada

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:

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