Question

我正在为k8s自定义对象进行某种资源级别的RBAC，发现使用本地k8s调用很难获取过滤器资源

cluster是我的自定义CRD，并且用户john仅使用k8s本地RBAC可以访问一个crd实例，而不是所有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”无法在名称空间“ biqmind”的API组“ operator.biqmind.com”中列出资源“集群”

您必须在指定名称空间中为指定用户添加动词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的更好方法是创建用户映射到的RBAC。映射的完成方式取决于您群集的身份验证器（例如，EKS的aws-iam-authenticator使用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-article。

请注意，默认角色和角色绑定

API服务器创建一组默认的ClusterRole和ClusterRoleBinding对象。其中许多是系统前缀的，表示资源由基础结构“拥有”。修改这些资源可能会导致群集无法正常运行。一个示例是system：node ClusterRole。该角色定义kubelet的权限。如果角色被修改，则会阻止kubelet正常工作。

所有默认群集角色和角色绑定均标有kubernetes.io/bootstrapping=rbac-defaults。

记住自动对帐

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

要选择退出此对帐，请将默认群集角色或角色绑定上的rbac.authorization.kubernetes.io/autoupdate注释设置为false。请注意，缺少默认权限和主题可能会导致群集无法正常运行。

当RBAC授权者处于活动状态时，

在Kubernetes版本 1.6 + 中启用了自动对帐。

有用的文章：understanding-rbac。

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

2 个答案: