基于对象过滤的kubernetes资源级RBAC

Question

我正在为k8s自定义对象做一些资源级别的RBAC，并且发现很难使用本机k8s调用获得筛选资源

cluster是我的自定义CRD，用户john只能访问一个crd实例，而不是使用k8s本机RBAC的所有CRD实例。

➜  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

我已经显式地指定了对象名，以获得用户身份验证对象的列表。对于如何解决这个问题，有什么建议吗？

完整的rbac在这里张贴

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

用户"ranbir“不能将API组"operator.biqmind.com”中的资源“集群”列在名称空间"biqmind“中。

您必须在指定的命名空间中为指定的用户添加带有谓词list的RBAC权限，才能让该用户list“集群”。

做的时候

kubectl get clusters --as=john aws-gluohfhcwo

您使用RBAC谓词get，但是要在没有指定特定名称的情况下进行列表，用户还需要list的权限。

授予list权限的示例，没有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

在用户端执行RBAC在概念上很容易。您可以为单个用户创建RoleBindings，但这并不是推荐的路径，因为操作员精神错乱的风险很高。

正确的RBAC更好的方法是创建您的用户映射到的对象；如何完成此映射取决于集群的身份验证器(例如，用于EKS的aws身份验证器使用mapRoles将角色ARN映射到一组组)。

组和他们可以访问的API最终是根据组织的需求来确定的，但是一个通用的读者(对于刚刚掌握了知识的新工程师来说)、编写者(对于您的工程师)和管理员(对于您来说)角色是一个好的开始。(嘿，这比管理对每个人都好。)

下面是配置文件的示例：

# 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

以下是确切的解释：rbac-条款。

注意到默认角色和角色绑定

API服务器创建一组默认的ClusterRole和ClusterRoleBinding对象。其中许多是系统:前缀，表示资源由基础设施“拥有”。对这些资源的修改可能导致非功能性集群。一个例子是系统:节点ClusterRole。此角色为kubelets定义权限。如果角色被修改，它可以阻止kubelets工作。

所有默认的集群角色和角色绑定都被标记为kubernetes.io/bootstrapping=rbac-defaults。

记住关于自动调节

在每次启动时，API服务器都会用缺少的权限更新默认集群角色，并使用任何缺失的主题更新默认集群角色绑定。这允许集群修复意外修改，并使角色和角色绑定随着新版本中的权限和主题的变化而更新。

若要选择退出此协调，请将默认集群角色上的rbac.Authization.kubernetes.io/autoupdate注释设置为false。请注意，缺少默认权限和主题可能会导致非功能集群。

当RBAC授权程序处于活动状态时，在Kubernetes版本1.6+中启用自动调节。

有用文章：理解-rbac。