The current implementation of rakkess with client-go library and genericclioptions works well, but it results in a rather large binary. However, the api machinery is only used to query SelfSubjectAccessReview for all resources and a list of server resources.
A different approach would be to call out to kubectl via exec.Command and create the SelfSubjectAccessReview through a yaml string. All additional args would then be forwarded to kubectl. Thus, all the heavy lifting is done by kubectl, whereas rakkess could remain small ans slim.
The following items need to be evaluated:
[ ] Performance: how much slower is the kubectl client
[ ] Correctness: Do both versions yield identical results (also when given identical options)?
[ ] Testability: Can the new implementation be tested as thoroughly?
[ ] Platform independence: Does that work on windows, where the kubectl binary is usually called kubectl.exe?
[ ] Extensibility: If switching the client, what has to be sacrificed?
[ ] What other advantages are there beside smaller binary size?
The current implementation of
rakkesswith client-go library and genericclioptions works well, but it results in a rather large binary. However, the api machinery is only used to querySelfSubjectAccessReviewfor all resources and a list of server resources. A different approach would be to call out tokubectlviaexec.Commandand create theSelfSubjectAccessReviewthrough a yaml string. All additional args would then be forwarded tokubectl. Thus, all the heavy lifting is done bykubectl, whereasrakkesscould remain small ans slim. The following items need to be evaluated:kubectlclientkubectlbinary is usually calledkubectl.exe?