2

Suppose a simple RBAC setup in Kubernetes (assuming default namespace for simplicity):

  • ServiceAccount + Role + RoleBinding
  • The role has allows to get and list verbs for pods and pods/log
  • a Pod using the above ServiceAccount
  • the pod is running curl to get all pods in default in a loop

As all entities are created, the pod is able to get the pods successfully.

Now, I want to change the underlying Role in the cluster - for example, restrict it to another namespace, or just remove permissions for the Pods altogether. Note that I'm only changing the Role - no other entities are changed.

My expectation is that eventually somehow the pod would get the change, and won't be able to get the pods anymore.

In fact, the pod continues to chug alone like nothing changed. I do know that the Bearer Token is mounted in the pod in a well-known location.

My question is this: is it the question of a longer time-out (in other words, if I let the pod run for X minutes, the change will take effect), or am I missing something fundamental here?

Ilya Ayzenshtok
  • 721
  • 2
  • 7
  • 18
  • 1
    I'm not able to replicate this behavior. I update the permission in the underlying `Role` tied up with a `serviceAccount` using a `RoleBinding`. I exec back into the same running `pod`, and perform the same operation using `curl` (to make it identical to yours) but I get a `"pods \"xxx\" is forbidden: User \"xxx\" cannot get resource \"pods/exec\" in API group` while before it worked fine. – rock'n rolla Apr 27 '23 at 11:39

0 Answers0