如何在Kubernetes中使用RBAC

Question

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?

Answer 1

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 Pod s for that Subject on a per Namespace basis. For example, you might not want people to be able to see Pod s in kube-system (or a hypothetical internal-security namespace). Using the ability to list Pod s as an example makes this hard to imagine, but the ability to list, or view, or both, Secret s or ConfigMap s may make this more tangible. Presumably a Subject can view Secret s 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 Pod s -- 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 Subject s 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.

Answer 2

在您的特定情况下，我将创建具有所需权限的单个群集角色，然后通过角色绑定将其绑定到相关名称空间中的相应主题。