kubectl
kubectl copied to clipboard
[ENH] - Kubectl flag to report permissions (ClusterRole .rules) used when creating.
I'd like to propose an additional flag on kubectl create e.g. --report-perms-used that will give some info on the exact apiGroups / resources / verbs / nonresourceURLS / verbs that were used during a kubectl create
Why is this needed: This could be very useful for Admins aiming for least-permissive pipelines (CI/CD) or separation of concerns (admin vs. app / developer) to properly create the ClusterRole for a service account. An elevated permission set could assist in determining the rules needed and create a service account before handoff to a deployment team. Ideally this is used in ocnjunction with --dry-run and be formatted in a way to faciltate copy / paste into a ClusterRole .rules yaml block.
This is different from can-i
and create clusterrole
in that in a complicated or externally maintained (e.g. vendor helm chart) the local team or admin won't know all the permissions required.
@jdunhamvrtx: This issue is currently awaiting triage.
SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted
label.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
We don't think this is something we'd want/be able to add because it would depend on the audit logs. Client side there isn't a way to differentiate between denied and not found.
Have a look at https://github.com/liggitt/audit2rbac.
/close
@eddiezane: Closing this issue.
In response to this:
We don't think this is something we'd want/be able to add because it would depend on the audit logs. Client side there isn't a way to differentiate between denied and not found.
Have a look at https://github.com/liggitt/audit2rbac.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.