如何使用"kubectl auth can-i"检查"exec"授权？

Question

如何使用kubectl auth can-i ...检查exec授权？

虽然get、create、delete等被认为是动词，但exec不是，如下所示：

$ kubectl --kubeconfig=config-prod.yml auth can-i exec po
Warning: verb 'exec' is not a known verb
yes

exec授权是否包含在另一个授权中，如create？

Answer 1

通常当有人创建RBAC规则并想检查哪些verbs可用于资源时使用：

$ kubectl api-resources -o wide | grep pods
pods                              po           v1                                     true         Pod                              [create delete deletecollection get list patch update watch]

然而，这并不是全部。如果你将使用不同的方法如下：

$ kubectl proxy &
Starting to serve on 127.0.0.1:8001
curl http://localhost:8001/api/v1
{
"kind": "APIResourceList",
"groupVersion": "v1",
"resources": [
{
...
### You will be able to find `pods` and verbs which can be used with pods
{
"name": "pods",
"singularName": "",
"namespaced": true,
"kind": "Pod",
"verbs": [
"create",
"delete",
"deletecollection",
"get",
"list",
"patch",
"update",
"watch"
],
"shortNames": [
"po"
### But also `pod/exec` and `pod/logs`
{
"name": "pods/exec",
"singularName": "",
"namespaced": true,
"kind": "PodExecOptions",
"verbs": [
"create",
"get"
]
},
{
"name": "pods/log",
"singularName": "",
"namespaced": true,
"kind": "Pod",
"verbs": [
"get"
]

在使用RBAC授权-参考参考资料中，您可以找到有关subresource的信息。

在Kubernetes API中，大多数资源都使用对象名称的字符串表示来表示和访问，例如Pod的pods。RBAC是指使用与相关API端点的URL中显示的名称完全相同的名称的资源。一些Kubernetes API涉及子资源，例如Pod 的日志

在本文档中，您有一个pods/logs的示例，但pods/exec也有类似的情况。

如果您将使用命令：

$ kubectl auth can-i create pods/exec
yes
$ kubectl auth can-i get pods/exec
yes
## Or
$ kubectl auth can-i get pods --subresource=exec
yes
$ kubectl auth can-i create pods --subresource=exec
yes

上述输出不包括Warning，因为我使用了来自pods/exec的verbs(get和create)。这是正确的语法，先使用verb，然后使用subresource。

为什么两个输出都是yes？我使用了一个管理员角色。

如果您想进行一些测试，可以创建ServiceAccount(测试)、Role和RoleBinding。Role山下：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-view-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-exec-view-role
rules:
- apiGroups: [""]
resources: ["pods/exec"]
verbs: ["get"]

auth can-i:的输出

$ kubectl auth can-i create pods/exec --as=system:serviceaccount:default:test
no
$ kubectl auth can-i get pods/exec --as=system:serviceaccount:default:test
yes

关于create pods/exec和get pods/exec之间的区别，您可以检查github线程用户可以使用websocket端点执行到pod中，即使没有pods/exec create权限。特别是在@liggitt评论中：

所以pods/exec子资源使用的谓词应该只是指示API端点使用的HTTP方法？

这就是所有资源谓词的工作方式(通过get映射到特殊情况列表和监视中的特定谓词)。看见https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-请求动词

因此，构建RBAC角色的管理员需要查看代码，并确定websocket-exec端点支持哪些HTTP方法？

否，子资源和相关动词应包含在API文档中。这值得反对https://github.com/kubernetes/website/issues/修复生成器以获取那些子资源

希望它能回答你的问题。如果你还有问题，请告诉我。