Public-works IoT operators ask whether a Pod’s ServiceAccount automatically inherits the Role of the human who applied the manifest. What is correct?
Select an answer to reveal the explanation.
Short Explanation
Who submitted the paperwork is not who the desk clerk becomes. The Pod speaks as its ServiceAccount, so that account needs its own RoleBindings. The human’s kubectl rights do not drip into the container identity.
Full Explanation
Public-works IoT operators sometimes assume a Pod inherits the Role of the human who applied the manifest. That is incorrect: admission uses the apply-user’s credentials, but runtime API calls from the Pod use the Pod’s ServiceAccount, which needs its own bindings. Who filed the paperwork is not who the desk clerk becomes once the process is running inside the municipal cluster. Granting a human permission to create Pods never automatically grants those Pods permission to list Secrets, watch Endpoints, or mutate other civic APIs. The API server does not copy the apply-user’s ClusterRole into the Pod at admission. Deployments and bare Pods follow the same ServiceAccount model; there is no special case where Deployments inherit the deployer’s kubeconfig identity for in-cluster calls. There is no inheritRbACFromUser: true field on the Pod spec—any such annotation or key would be fiction rather than a Kubernetes feature. Exam caveat: creating a Pod and acting as that Pod are two different subjects; always bind Roles to the ServiceAccount the workload actually uses. Operational check: apply a Pod or Deployment with an explicit ServiceAccount, attempt an in-cluster API action that the human can perform but the ServiceAccount cannot, observe Forbidden, then add a RoleBinding for that ServiceAccount and retest until the IoT workload’s intended verbs succeed only for that account.