带有对象过滤的 kubernetes 资源级别 RBAC

Question

i'm doing some resource level RBAC for k8s custom objects and finding it difficult to get filter resources using native k8s calls

cluster is my custom CRD and user john has access to only one crd instance not all instances of CRD using k8s native RBAC

➜  k get clusters
NAME               AGE
aws-gluohfhcwo     3d2h
azure-cikivygyxd   3d1h

➜  k get clusters --as=john
Error from server (Forbidden): clusters.operator.biqmind.com is forbidden: User "ranbir" cannot list resource "clusters" in API group "operator.biqmind.com" in the namespace "biqmind"

➜  k get clusters --as=john aws-gluohfhcwo
NAME             AGE
aws-gluohfhcwo   3d2h

i have explicitly specify object name to get the list of objects to which user is authenticated. any suggestions on how this can be solved?

full rbac is posted here

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: biqmind
  name: cluster-admin-aws-gluohfhcwo
rules:
- apiGroups: ["operator.biqmind.com"]
  resources: ["clusters"]
  resourceNames: ["aws-gluohfhcwo"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cluster-admin-aws-gluohfhcwo-binding
  namespace: biqmind
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: cluster-admin-aws-gluohfhcwo
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: ranbir

Answer 1

User "ranbir" cannot list resource "clusters" in API group "operator.biqmind.com" in the namespace "biqmind"

You must add RBAC permissions with the verb list for the specified user in the specified namespace, to let that user list "clusters".

When doing

kubectl get clusters --as=john aws-gluohfhcwo

you use the RBAC verb get , but to list without specifying a specific name, the user also need permission to list .

Example of giving list permission, without resourceName: :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: biqmind
  name: cluster-admin-aws-gluohfhcwo
rules:
- apiGroups: ["operator.biqmind.com"]
  resources: ["clusters"]
  resourceNames: ["aws-gluohfhcwo"]
  verbs: ["get", "watch", "create", "update", "patch", "delete"]

- apiGroups: ["operator.biqmind.com"]
  resources: ["clusters"]
  verbs: ["get", "list"]

Answer 2

Enforcing RBAC on the user side is easy in concept. You can create RoleBindings for individual users, but this is not the recommended path as there's a high risk of operator insanity.

The better approach for sane RBAC is to create that your users map to; how this mapping is done is dependent on your cluster's authenticator (eg the aws-iam-authenticator for EKS uses mapRoles to map a role ARN to a set of groups).

Groups and the APIs they have access to are ultimately determined based on an organization's needs, but a generic reader (for new engineers just getting the hang of things), writer (for your engineers), and admin (for you) role is a good start. (Hey, it's better than admin for everyone.)

Here is example of configuration file:

# An example reader ClusterRole – ClusterRole so you’re not worried about namespaces at this time. Remember, we’re talking generic reader/writer/admin roles.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: reader
rules:
– apiGroups: [“*”]
resources:
– deployments
– configmaps
– pods
– secrets
– services
verbs:
– get
– list
– watch
---
# An example reader ClusterRoleBinding that gives read permissions to
# the engineering and operations groups
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: reader-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: reader
subjects:
- kind: Group
  name: umbrella:engineering
- kind: Group
  name: umbrella:operations
---
# An example writer ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: writer
rules:
- apiGroups: [“*”]
resources:
- deployments
- configmaps
- pods
- secrets
- services
verbs:
- create
- delete
- patch
- update
---
# An example writer ClusterRoleBinding that gives write permissions to
# the operations group
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: reader-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: reader
subjects:
- kind: Group
  name: umbrella:operations

Here is exact explanation: rbac-article .

Take notice that default Roles and Role Bindings

API servers create a set of default ClusterRole and ClusterRoleBinding objects. Many of these are system: prefixed, which indicates that the resource is “owned” by the infrastructure. Modifications to these resources can result in non-functional clusters. One example is the system:node ClusterRole. This role defines permissions for kubelets. If the role is modified, it can prevent kubelets from working.

All of the default cluster roles and rolebindings are labeled with kubernetes.io/bootstrapping=rbac-defaults .

Remember about auto-reconciliation

At each start-up, the API server updates default cluster roles with any missing permissions, and updates default cluster role bindings with any missing subjects. This allows the cluster to repair accidental modifications, and to keep roles and rolebindings up-to-date as permissions and subjects change in new releases.

To opt out of this reconciliation, set the rbac.authorization.kubernetes.io/autoupdate annotation on a default cluster role or rolebinding to false. Be aware that missing default permissions and subjects can result in non-functional clusters.

Auto-reconciliation is enabled in Kubernetes version 1.6+ when the RBAC authorizer is active.

Useful article: understanding-rbac .