Kubectl auth: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| Line 14: | Line 14: | ||
It could also reconcile rules for RBAC Role, RoleBinding, ClusterRole, and ClusterRole binding objects. | 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 [[Kubectl#--as|--as]] kubectl option: | |||
<syntaxhighlight lang='bash'> | |||
kubectl --as system:serviceaccount:blue:blue-sa auth can-i get pod my-pod | |||
</syntaxhighlight> | |||
=Usage Examples= | =Usage Examples= | ||
* [[Kubernetes_Security_Operations#Authorization_Check|Authorization checks]] | * [[Kubernetes_Security_Operations#Authorization_Check|Authorization checks]] | ||
Revision as of 00:37, 5 September 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