<p>How can I check for <code>exec</code> authorization using <code>kubectl auth can-i ...</code>?</p>
<p>While <code>get</code>, <code>create</code>, <code>delete</code>, etc. are considered verbs, <code>exec</code> is not, as shown below:</p>
<pre><code>$ kubectl --kubeconfig=config-prod.yml auth can-i exec po
Warning: verb 'exec' is not a known verb
yes
</code></pre>
<p>Is <code>exec</code> authorization included in another authorization, like <code>create</code>?</p>

<p>Usually when someone is creating <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/" rel="noreferrer">RBAC</a> rules and wants to check which <code>verbs</code> are available for resource using:</p>
<pre><code>$ kubectl api-resources -o wide | grep pods
pods                              po           v1                                     true         Pod                              [create delete deletecollection get list patch update watch]
</code></pre>
<p>However it's not all. If you will use bit different approach like below:</p>
<pre><code>$ kubectl proxy &amp;
Starting to serve on 127.0.0.1:8001
curl http://localhost:8001/api/v1
{
  &quot;kind&quot;: &quot;APIResourceList&quot;,
  &quot;groupVersion&quot;: &quot;v1&quot;,
  &quot;resources&quot;: [
    {
...
### You will be able to find `pods` and verbs which can be used with pods
{
      &quot;name&quot;: &quot;pods&quot;,
      &quot;singularName&quot;: &quot;&quot;,
      &quot;namespaced&quot;: true,
      &quot;kind&quot;: &quot;Pod&quot;,
      &quot;verbs&quot;: [
        &quot;create&quot;,
        &quot;delete&quot;,
        &quot;deletecollection&quot;,
        &quot;get&quot;,
        &quot;list&quot;,
        &quot;patch&quot;,
        &quot;update&quot;,
        &quot;watch&quot;
      ],
      &quot;shortNames&quot;: [
        &quot;po&quot;

### But also `pod/exec` and `pod/logs`
{
      &quot;name&quot;: &quot;pods/exec&quot;,
      &quot;singularName&quot;: &quot;&quot;,
      &quot;namespaced&quot;: true,
      &quot;kind&quot;: &quot;PodExecOptions&quot;,
      &quot;verbs&quot;: [
        &quot;create&quot;,
        &quot;get&quot;
      ]
    },
    {
      &quot;name&quot;: &quot;pods/log&quot;,
      &quot;singularName&quot;: &quot;&quot;,
      &quot;namespaced&quot;: true,
      &quot;kind&quot;: &quot;Pod&quot;,
      &quot;verbs&quot;: [
        &quot;get&quot;
      ]

</code></pre>
<p>In <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-resources" rel="noreferrer">Using RBAC Authorization - Referring to resources</a> you can find information about <code>subresource</code>.</p>
<blockquote>
<p>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</p>
</blockquote>
<p>In this Documentation, you have an example with <code>pods/logs</code> but a similar situation is for <code>pods/exec</code>.</p>
<p>If you will use command:</p>
<pre><code>$ 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
</code></pre>
<p>Above outputs don't include <code>Warning</code> as I used <code>verbs</code> (<code>get</code> and <code>create</code>) from <code>pods/exec</code>. So that's the correct syntax, use <code>verb</code> and then <code>subresource</code>.</p>
<p>Why are both outputs <code>yes</code>? I used an admin role.</p>
<p>If you want to make some tests you can create <code>ServiceAccount</code> (test), <code>Role</code> and <code>RoleBinding</code>. <code>Role</code> yamls below:</p>
<pre><code>apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-view-role
rules:
- apiGroups: [&quot;&quot;]
  resources: [&quot;pods&quot;]
  verbs: [&quot;get&quot;, &quot;list&quot;, &quot;watch&quot;]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-exec-view-role
rules:
- apiGroups: [&quot;&quot;]
  resources: [&quot;pods/exec&quot;]
  verbs: [&quot;get&quot;]
</code></pre>
<p>Outputs of <code>auth can-i</code>:</p>
<pre><code>$ 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
</code></pre>
<p>About the difference between <code>create pods/exec</code> and <code>get pods/exec</code> you can check github thread <a href="https://github.com/kubernetes/kubernetes/issues/78741" rel="noreferrer">Users can exec into pods with the websocket endpoint even without <code>pods/exec create</code> privileges</a>. Especially in @liggitt <a href="https://github.com/kubernetes/kubernetes/issues/78741#issuecomment-500412951" rel="noreferrer">comment</a>:</p>
<blockquote>
<p>So the verb used with the pods/exec subresource is just supposed to indicate what HTTP method is used with that API endpoint?</p>
</blockquote>
<p>That is how all the resource verbs work (with get mapping to specific verbs in the special cases list and watch). See <a href="https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb" rel="noreferrer">https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb</a></p>
<blockquote>
<p>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?</p>
</blockquote>
<p>No, the subresources and associated verbs should be included in the API doc. That would be worth an issue against <a href="https://github.com/kubernetes/website/issues/" rel="noreferrer">https://github.com/kubernetes/website/issues/</a> to fix the generator to pick up those subresources</p>
<p>Hope it answered your question. If you still have questions, let me know.</p>
