Kubectl auth: Difference between revisions
Jump to navigation
Jump to search
| Line 22: | Line 22: | ||
=Usage Examples= | =Usage Examples= | ||
Namespaces: | |||
<syntaxhighlight lang='yaml'> | |||
kubectl --as system:serviceaccount:test-ns:default auth can-i get ns | |||
</syntaxhighlight> | |||
Namespace: | |||
<syntaxhighlight lang='yaml'> | |||
kubectl --as system:serviceaccount:test-ns:default auth can-i get ns/some-namespace | |||
</syntaxhighlight> | |||
Also see: {{Internal|Kubernetes_Security_Operations#Authorization_Check|Authorization checks}} | Also see: {{Internal|Kubernetes_Security_Operations#Authorization_Check|Authorization checks}} | ||
Revision as of 21:03, 3 November 2020
Internal
Overview
kubectl auth inspects authorization.
It can check whether an action is allowed with:
kubectl auth can-i <verb> [<type>|<type>/<name>|<non-resource-url>
The verb is a logical Kubernetes API verb: "get", "list", "watch", "delete", etc. Type is a kubernetes resource. The name is the name of a particular resource.
It could also reconcile rules for RBAC Role, RoleBinding, ClusterRole, and ClusterRole binding objects.
The identity used to perform the call can be changed via the --as kubectl option:
kubectl --as system:serviceaccount:blue:blue-sa auth can-i get pod my-pod
Usage Examples
Namespaces:
kubectl --as system:serviceaccount:test-ns:default auth can-i get ns
Namespace:
kubectl --as system:serviceaccount:test-ns:default auth can-i get ns/some-namespace
Also see: