kubernetes 默认的RBAC角色"admin"不允许使用临时容器,

icomxhvb  于 5个月前  发布在  Kubernetes
关注(0)|答案(8)|浏览(80)

发生了什么?
嘿,伙计们,
我注意到默认的集群角色管理员没有足够的权限来使用新的临时容器功能。我的团队为开发团队提供了一个基于EKS的平台,我们在其中为他们提供一个命名空间(例如“bogus”),并通过RoleBinding将默认的ClusterRole "admin"绑定到该命名空间中的组,然后使用aws-auth将AWS IAM角色Map到相应的组。
该角色具有以下API子集,可用于Pods端点:

- apiGroups:
  - ""
  resources:
  - pods
  - pods/attach
  - pods/exec
  - pods/portforward
  - pods/proxy
  verbs:
  - create
  - delete
  - deletecollection
  - patch
  - update

我期望每个命名空间的Kubernetes功能都可以供这些用户使用。
你期望发生什么?
如果用户将默认的ClusterRole admin绑定到带有RoleBinding的命名空间,或者将其绑定到任何带有ClusterRoleBinding的命名空间,他们应该能够使用kubectl debug调试其命名空间中的任何pod。
我们如何尽可能最小精确地重现它?

  • 获取foo命名空间中到默认ClusterRole admin的RoleBinding,主题可以轻松进行身份验证。
  • 按照必要的身份验证方法访问具有该主题的集群。
  • kubectl run nginx --image=nginx --restart=Never -n foo
  • kubectl debug nginx -it --image=nginx -n foo

你会得到一个禁止错误,如下所示:

Error from server (Forbidden): pods "nginx" is forbidden: User "foo-admin" cannot patch resource "pods/ephemeralcontainers" in API group "" in the namespace "foo"

还有什么我们需要知道的吗?

  • 无响应*

Kubernetes版本

$ kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.4", GitCommit:"872a965c6c6526caa949f0c6ac028ef7aff3fb78", GitTreeState:"clean", BuildDate:"2022-11-09T13:36:36Z", GoVersion:"go1.19.3", Compiler:"gc", Platform:"darwin/arm64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"24+", GitVersion:"v1.24.16-eks-2d98532", GitCommit:"af930c12e26ef9d1e8fac7e3532ff4bcc1b2b509", GitTreeState:"clean", BuildDate:"2023-07-28T16:52:47Z", GoVersion:"go1.20.6", Compiler:"gc", Platform:"linux/amd64"}

云提供商
AWS
操作系统版本

Darwin Jos-Maias-MacBook-Pro-M1.local 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000 arm64
vmjh9lq9

vmjh9lq93#

这个看起来更像是FR而不是bug。
/remove-kind bug
/kind feature
/triage accepted

acruukt9

acruukt94#

这看起来更像是一个特性而不是bug。

你好,根据我对文档的解读,我认为这是一个bug。

If used in a RoleBinding, allows read/write access to most resources in a namespace, including the ability to create roles and role bindings within the namespace.
我猜“大多数资源”这个描述相当模糊:D

我期望一个管理员角色可以进入pods内部,重启它们,将它们的端口转发到本地机器等。我的预期是它也会默认具备在那个pod上启动额外的调试容器的能力。

如果这是WAD的话,我很乐意在我这边进行调整。

sbdsn5lh

sbdsn5lh5#

大家好,我只是想插个话。我也遇到了类似的情况。首先,如果不是补丁pod,那么角色中缺少的权限是什么?

具体来说,这个输出让我有点困惑。

sqxo8psd

sqxo8psd7#

将我从打开的PR中提出的评论提升:
添加临时容器的能力意味着绕过在容器类型存在之前创建的准入插件和安全策略。这是使用新子资源而不是默认将其包含在admin和edit角色中的关键原因。
管理员可以通过创建包含此权限的clusterrole并将其标记为包含在edit角色rbac.authorization.k8s.io/aggregate-to-edit: "true"(https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles)中来为此权限贡献给admin和edit角色。
我认为这在临时容器文档中被明确提及,但我在寻找它方面遇到了困难。将这些信息/理由/授权临时容器的方法添加到网站上的文档中是一个好主意。

vjrehmav

vjrehmav8#

/remove-kind feature
/kind documentation

相关问题