Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Read RBAC resources from stdin instead of calling kubectl #5

Closed
luksa opened this issue Jun 1, 2019 · 4 comments
Closed

Comments

@luksa
Copy link
Collaborator

luksa commented Jun 1, 2019

To follow Unix philosophy, we could remove the code that fetches RBAC resources through kubectl, and instead just read them from STDIN.

It's possible to get all required resources with a single command, so we should be able to run:

kubectl get sa,roles,rolebindings,clusterroles,clusterrolebindings --all-namespaces -o json | rback

Since the plan is to create a kubectl-rback plugin, which will run the above command, most users will never have to type the full command and instead just run kubectl rback.

The added benefit would be that you could also get the RBAC resource list JSON from anywhere (e.g. email?) and still be able to convert it to a graph file. Perhaps we could create an online service where you paste in your RBAC JSON and it renders the graph (ok, maybe not a great idea as far as security goes, but it does demonstrate the benefit nicely).

@luksa
Copy link
Collaborator Author

luksa commented Jun 1, 2019

@mhausenblas WDYT?

@mhausenblas
Copy link
Member

Yeah, that makes a lot of sense to me. Just one question: why didn't I think of that in the first place? ;)

@mhausenblas
Copy link
Member

Also, I thought you needed some rest from it after your mega code drop, LOL. Keep it up, man!

@luksa
Copy link
Collaborator Author

luksa commented Jun 4, 2019

Merged.

@luksa luksa closed this as completed Jun 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants