I do understand RBAC and I'm able to create a role using rules en subjects, bind them with a user.
For example this role can only list the pods
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: development
name: list-pods
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "list"]Now we are using namespaces for every environment we have (dev, staging, prd). Now how do I have to provide this role to users in different namespaces? Do I have to create a clusterRole and bind it with a normal rolebinding or do I have to write the above .yaml once for dev, once for uat and once for prd? Are there somewhere rules written about how to handles those cases?
In your specific case I would create a single cluster role with the desired permissions and then bind it via role bindings to the appropriate subjects in the relevant namespaces.
Now how do I have to provide this role to users in different namespaces?
You do if you want to be able to constrain the ability to list Pods for that Subject on a per Namespace basis. For example, you might not want people to be able to see Pods in kube-system (or a hypothetical internal-security namespace). Using the ability to list Pods as an example makes this hard to imagine, but the ability to list, or view, or both, Secrets or ConfigMaps may make this more tangible. Presumably a Subject can view Secrets for their own project -- or even maybe not -- but not for other projects within the company. That kind of thing.
That gets even more real when one thinks about the ability to exec into arbitrary Pods -- because that's the biggest risk that I can think of to the safety and confidentiality of applications in the cluster.
Do I have to create a clusterRole and bind it with a normal rolebinding
No, one uses a ClusterRoleBinding for that purpose. "Have to" is not the right question; it depends on whether you want the binding to apply to all namespaces, current and future.
or do I have to write the above .yaml once for dev, once for uat and once for prd?
That also depends on whether those Namespaces have identical risk and identical Subjects who access them.
Are there somewhere rules written about how to handles those cases?
Definitely not; there's not one-size-fits-all for cluster security. It all depends on the kind of risk one is trying to drive down.
As a for-your-consideration, you're not obligated to use the RBAC constraints: you can certainly create a ClusterRoleBinding for every Subject to the cluster-admin ClusterRole and voilà, no more permission management. No more safeguards, either, but that's the spectrum.