Kubernetes RBAC 动词：没有列表，反之亦然？看没有清单？

Question

虽然有很多关于 Kubernetes RBAC 的文档和示例以及不同资源的可用动词，但我找不到任何关于某些动词是否总是组合使用或是否有单独使用它们的用例的规则。特别是，我想知道动词 get、list 和 watch。将它们结合起来有什么用处，尤其是不结合它们？

• 是否允许获取资源但不列出列表？
• 相反，list 的用途是否允许获取？也许沿着信息稀疏的路线？
• 获取并列出，但没有手表？仅限制受信任的主体和服务帐户以对 API 服务器和 etcd 施加更大的压力？
• 观看没有列表或获取？这不会削弱大多数客户，因为他们是列表观察者吗？

Answer 1

有趣的问题，这里有一些想法和实际使用的例子。

在实践中还有很多例子。例如，您可以通过浏览kubectl describe clusterroles 来检查默认的 ClusterRoles。要查看 kubectl 在后台发出哪些 API 请求，您可以增加日志详细程度，例如，kubectl get pods -w -v 10。

get 但不是 list

您希望某人能够通过名称读取他们知道的资源，但不知道存在哪些其他资源。例如，允许做kubectl get mypod，但不允许做kubectl get pods。

例子：

• system:node ClusterRole 对端点、PV 和 PVC 具有 get 但没有 list 权限。
• system:coredns ClusterRole 对节点具有 get 但没有 list 权限。
• system:controller:expand-controller ClusterRole 对 Endpoints、Secrets 和 Services 具有 get 但没有 list 权限。

list 但不是 get

允许执行例如kubectl get pods 但不允许执行kubectl get pod mypod。这没有多大意义，因为您可以使用 get 获得的所有信息也包含在 list 中。尽管如此，在实践中还是有一些这样的用法。

例子：

• system:kube-dns ClusterRole 具有端点和服务的 list 和 watch 权限，但没有 get。
• system:controller:daemon-set-controller ClusterRoel 对节点具有 list 和 watch 权限，但没有 get 权限。
• system:coredns ClusterRole 拥有端点、命名空间、Pod 和服务的 list 和 watch 权限，但没有 get。李>

get 和 list，但不是 watch

实际上，在大多数情况下，有 list 的地方也有 watch。您可以剥夺某人的 watch 权限以减少 etcd 上的观察者数量。用户可以使用kubectl get pods 和kubectl get pods mypod，但不能使用-w 选项。

如果 API 不支持 watch 操作也有意义，例如可选的指标 API。

例子：

• system:controller:persistent-volume-binder ClusterRole 对节点有 get 和 list 权限，但没有 watch

watch，但不是 get 和 list

关于用例，它没有多大意义，因为您可以使用 get 和 list 获得的所有信息也包含在 watch。我不知道这在实践中有什么具体用法。

但是，从技术上讲，这是可能的。例如，如果你对 Pod 有 watch 权限，但没有 get 和 list，你可以这样做：

✅ kubectl get --raw="/api/v1/watch/namespaces/default/pods"
✅ kubectl get --raw="/api/v1/watch/namespaces/default/pods/mypod"

而且它有效。但是，这些watch 端点已被弃用，您应该使用带有watch 参数的list 端点。但这也有效：

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

但是，您不能像这样观看单个 Pod，因为 get 端点没有 watch 参数。因此，以下内容无效：

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

而且你根本无法使用 kubectl 观看资源。以下失败：

❌ kubectl get pods -w
❌ kubectl get pods mypod -w

因为 kubectl 分别在 watch 请求之前发出 list 和 get 请求，很可能是为了得到 resourceVersion 的然后将包含在后续 watch 请求中的资源。

注意：这意味着，如果您有 list 和 watch，那么 kubectl get pods -w 有效，但 kubectl get pods mypod -w 无效，如果您有 获取并观看，然后kubectl get pods mypod -w 有效，但kubectl get pods -w 无效。