我仍然是kubernetes newbe。但是我正在寻找一种使开发人员控制访问Kubectl Exec命令的方法。我想让他们运行大部分仅阅读命令，但要防止一些高风险命令，也可以防止交互式下载/安装等。还希望在会议期间记录其所有操作以进行审核目的。
我没有看到使用RBAC进行任何直接的方法。也没有在牧场主中看到这些选项。我正在寻找一些指导和指导以实现这种能力。
我敢肯定，你们中的一些人已经以某种方式取得了成就。
I am still bit of kubernetes newbe. But I am looking for a way to give developers controlled access to kubectl exec command . I want to give them run most of the read-only command but prevent some high risk command and also prevent interactive download/install etc. Also want to log all their action during sessions for audit purpose.
I am not seeing any straight forward way to do it using rbac. Also not seeing those options in rancher either. I am looking for some guidance and direction to achieve such capability.
I am sure some of you have achieved it some way.
发布评论
评论（1）
Kubernetes RBAC只能在您可以或不能
exec中验证到PODS中，（通过检查createpods/exec resources），之后切换到SPDY协议并传递您的输入并从docker exec在容器运行时返回输出，而无需实际关心使用RBAC进出的内容，您还必须指定POD名称，这些名称可能可能可能如果您使用的是部署，请遇到问题，每个新修订将生成不同的POD名称。由于RBAC中未实现模式匹配 - 每次生成新的POD名称时，您都必须更改角色。
因此，答案是“不，您可以使用RBAC进行”的
替代解决方案是使用某种CI/CD（Jenkins，Gitlab-Ci等）或编排工具（Rundeck，Ansible-Tower等）。将创建某种脚本，您的开发人员会将参数传递给工作，即由您控制的工作，即
，从本质上讲，您将负责管理对该工作/脚本的访问，创建和维护该脚本的ServiceAccount，等等。
如果您害怕图像可变性，即您不希望开发人员在运行的容器中安装某些内容，但是否则可以将其提供外壳（请记住，他们仍然可以读取任何秘密/env vars/configmaps和即使是默认情况下使用POD使用的ServiceAccount令牌），您也应该考虑以下内容：
root。尝试使用映像，以支持rootles操作，然后在runasuser中指定Security> SecurityContext中的字段中正确的非根UID，或配置runasnononRoot：true标志以拒绝作为根运行的容器。ReadOneNonlylyrotfilesystem使POD在您的命名空间中运行，在安全上下文中，它将拒绝将操作写入pod ephemeral Storage（但是，如果您将任何卷载为RW，则仍然可以访问它们以写操作）。这种方法的可行性取决于您的应用程序使用某种不相关链接的临时文件时：
exec实际上有效 Kubernetes RBAC can only validate whenever you can or cannot
execinto pods, (by checkingcreateverb onpods/execresource), after that it switches to SPDY protocol and passes your input and returning back output from analog ofdocker execon your container runtime, without actually caring about what's going in and outWith rbac you also have to specify pod name, which might be problematic if you are using Deployments, where each new revision will generate a different pod name. Since pattern matching is not implemented in rbac - you would have to change your role every time new pod name is generated.
So the answer is "No, you can' do it with rbac"
An alternative solution would be to use some kind of CI/CD (jenkins,gitlab-ci etc.) or orchestration tool (rundeck, ansible-tower etc) where you will create some kind of script, where your developers would pass arguments to a job, controlled by you, i.e.
Which, essentially, means, that you would be responsible for managing access to that job/script, creating and maintaining serviceAccount for that script, etc.
If you are afraid of image mutability, i.e. you don't want your developers to install something in running container, but otherwise are okay with giving them shell on it (remember, they can still read any secrets/env vars/configMaps and even serviceAccount tokens that pod uses of you mount them by default), you should consider the following:
root. Try to use images, that support rootles operation, and then either specify correct non-root UID inrunAsUserfield insecurityContext, or configurerunAsNonRoot: trueflag to deny containers running as root.readOnlyRootFilesystemin security context, which will deny write operation to pod ephemeral storage (but if you mounted any volume as RW - they still will be accessible to write operations). Feasibility of this approach depends on whenever your apps use some kind of temporary files of notRelevant links:
execactually works