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

Question

How can I check for exec authorization using kubectl auth can-i... ?

While get , create , delete , etc. are considered verbs, exec is not, as shown below:

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

Is exec authorization included in another authorization, like create ?

Answer 1

Usually when someone is creating RBAC rules and wants to check which verbs are available for resource using:

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

However it's not all. If you will use bit different approach like below:

$ 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"
      ]

In Using RBAC Authorization - Referring to resources you can find information about subresource .

In the Kubernetes API, most resources are represented and accessed using a string representation of their object name, such as pods for a Pod. RBAC refers to resources using exactly the same name that appears in the URL for the relevant API endpoint. Some Kubernetes APIs involve a subresource, such as the logs for a Pod

In this Documentation, you have an example with pods/logs but a similar situation is for pods/exec .

If you will use command:

$ 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

Above outputs don't include Warning as I used verbs ( get and create ) from pods/exec . So that's the correct syntax, use verb and then subresource .

Why are both outputs yes ? I used an admin role.

If you want to make some tests you can create ServiceAccount (test), Role and RoleBinding . Role yamls below:

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"]

Outputs of 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

About the difference between create pods/exec and get pods/exec you can check github thread Users can exec into pods with the websocket endpoint even without pods/exec create privileges . Especially in @liggitt comment :

So the verb used with the pods/exec subresource is just supposed to indicate what HTTP method is used with that API endpoint?

That is how all the resource verbs work (with get mapping to specific verbs in the special cases list and watch). See https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb

So an admin building an RBAC role is expected to look at the code and figure out which HTTP methods are supported for the websocket exec endpoint?

No, the subresources and associated verbs should be included in the API doc. That would be worth an issue against https://github.com/kubernetes/website/issues/ to fix the generator to pick up those subresources

Hope it answered your question. If you still have questions, let me know.