如何使用“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 中，大多数资源都使用其 object 名称的字符串表示形式来表示和访问，例如 Pod 的 pod。 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 (test)、 Role和RoleBinding 。 Role yamls如下：

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 线程即使没有pods/exec create权限，用户也可以使用 websocket 端点执行到 pod 中。 特别是在@liggitt 评论中：

因此，与 pods/exec 子资源一起使用的动词应该只是表明 HTTP 方法与该 API 端点一起使用？

这就是所有资源动词的工作方式（get 映射到特殊情况列表和观察中的特定动词）。 请参阅https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb

因此，构建 RBAC 角色的管理员应该查看代码并找出 websocket exec 端点支持哪些 HTTP 方法？

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

希望它回答了你的问题。 如果您仍有疑问，请告诉我。