<p>While there's a lot of documentation and examples on Kubernetes RBAC and also the available verbs for different resources, I couldn't find any rules on whether certain verbs are always used in combination or whether there are use cases to using them individually. In particular, I'm wondering about the verbs get, list, and watch. What uses are for combining them, and especially not combining them?</p>

<ul>
<li>are there uses for allowing get on resources, but not list?</li>
<li>au contraire, are there uses for list without allowing get? Maybe along the lines of information sparseness?</li>
<li>get and list, but no watch? To restrict only trusted subjects and service accounts to put more strain on the API server and etcd?</li>
<li>watch without list or get? Wouldn't that cripple most clients because they're listwatchers?</li>
</ul>

<p>Interesting question, here are some ideas and examples of usages in practice.</p>

<p>There are many more examples in practice. For example, you can inspect the default ClusterRoles by browsing through <code>kubectl describe clusterroles</code>. And to see which API requests kubectl makes under the hood, you can increase the log verbosity, for example, <code>kubectl get pods -w -v 10</code>.</p>

<h3><em>get</em> but not <em>list</em></h3>

<p>You want someone to be able to read resources they know by name but not discover what other resources exist. For example, allows to do <code>kubectl get mypod</code>, but not <code>kubectl get pods</code>.</p>

<p>Examples:</p>

<ul>
<li>The <code>system:node</code> ClusterRole has <em>get</em> but not <em>list</em> permissions on Endpoints, PVs, and PVCs.</li>
<li>The <code>system:coredns</code> ClusterRole has <em>get</em> but not <em>list</em> permissions on Nodes.</li>
<li>The <code>system:controller:expand-controller</code> ClusterRole has <em>get</em> but not <em>list</em> permissions on Endpoints, Secrets, and Services.</li>
</ul>

<h3><em>list</em> but not <em>get</em></h3>

<p>Allows to do, for example, <code>kubectl get pods</code> but not <code>kubectl get pod mypod</code>. It doesn't make much sense, because all the information you can get with <em>get</em> is also included in <em>list</em>. Nevertheless, there are some usages of this in practice. </p>

<p>Examples:</p>

<ul>
<li>The <code>system:kube-dns</code> ClusterRole has <em>list</em> and <em>watch</em> permissions for Endpoints and Services, but not <em>get</em>.</li>
<li>The <code>system:controller:daemon-set-controller</code> ClusterRoel has <em>list</em> and <em>watch</em> permissions for Nodes, but not <em>get</em>.</li>
<li>The <code>system:coredns</code> ClusterRole has <em>list</em> and <em>watch</em> permissions for Endpoints, Namespaces, Pods, and Services, but not <em>get</em>.</li>
</ul>

<h3><em>get</em> and <em>list</em>, but not <em>watch</em></h3>

<p>In practice, in most cases where there is <em>list</em> there is also <em>watch</em>. You could deprive someone of <em>watch</em> to reduce the number of watchers on etcd. Users can do <code>kubectl get pods</code> and <code>kubectl get pods mypod</code>, but not use the <code>-w</code> option.</p>

<p>Makes also sense if the API does not support <em>watch</em> operations, like, for example, the optional metric APIs.</p>

<p>Examples:</p>

<ul>
<li>The <code>system:controller:persistent-volume-binder</code> ClusterRole has <em>get</em> and <em>list</em> permissions for Nodes, but not <em>watch</em></li>
</ul>

<h3><em>watch</em>, but not <em>get</em> and <em>list</em></h3>

<p>Regarding the use case, it doesn't make much sense, because all the information you can get with <em>get</em> and <em>list</em> is also included in <em>watch</em>. I don't know of any concrete usage of this in practice.</p>

<p>However, technically, it's possible. For example, if you have <em>watch</em> permissions for Pods, but not <em>get</em> and <em>list</em>, you can do:</p>

<pre><code>✅ kubectl get --raw="/api/v1/watch/namespaces/default/pods"
✅ kubectl get --raw="/api/v1/watch/namespaces/default/pods/mypod"
</code></pre>

<p>And it works. However, these <code>watch</code> endpoints are deprecated and you should use the <em>list</em> endpoint with a <code>watch</code> parameter instead. But this also works:</p>

<pre><code>✅ kubectl get --raw="/api/v1/namespaces/default/pods?watch=true"
</code></pre>

<p>However, you can't watch a single Pod like this, because the <em>get</em> endpoint doesn't have a <code>watch</code> parameter. So, the following is invalid:</p>

<pre><code>❌ kubectl get --raw="/api/v1/namespaces/default/pods/mypod?watch=true"
</code></pre>

<p>And you can't watch resources with kubectl at all. The following fails:</p>

<pre><code>❌ kubectl get pods -w
❌ kubectl get pods mypod -w
</code></pre>

<p>Because kubectl makes a <em>list</em> and <em>get</em> request, respectively, before the <em>watch</em> request, most probably to get the <code>resourceVersion</code> of the resources which will then be included in the subsequent <em>watch</em> request.</p>

<p>Note: that means, if you have <em>list</em> and <em>watch</em>, then <code>kubectl get pods -w</code> works, but <code>kubectl get pods mypod -w</code> doesn't, and if you have <em>get</em> and <em>watch</em>, then <code>kubectl get pods mypod -w</code> works but <code>kubectl get pods -w</code> doesn't.</p>
