kubectl command wrapper #172
Conversation
|
@exequielrafaela same comment here about reviewers and PR state 🙏 |
@diego-ojeda-binbash agreed as stated in the related PR 🤝 ✅ 💪🏼 |
| return f"bash -c \"{chain.join(commands)}\"" | ||
|
|
||
|
|
||
| class CustomEntryPoint: |
There was a problem hiding this comment.
Love the use of context managers, very elegant solution!
| auth_method = container.TF_SSO_ENTRYPOINT | ||
| elif container.mfa_enabled: | ||
| auth_method = container.TF_MFA_ENTRYPOINT | ||
| # TODO: ask why this was necessary |
There was a problem hiding this comment.
@angelofenoglio @juanmatias maybe you can clarify me this guys?
There was a problem hiding this comment.
Hi!
The original use case in which the design was based on (containerized terraform commands, particularly MFA authenticated) made, and makes, quite a bit of effort to avoid overriding the host's credentials, and configuration files for the aws cli.
So the default behavior is to mount those files elsewhere (/tmp), use them as source of truth to know which profiles to assume and generate new aws config files that are going to perish alongside the container everytime a command is run.
With the use of SSO this is less and less common and we should think if it is really worth it.
There was a problem hiding this comment.
Considering this: https://github.com/binbashar/leverage/blob/master/leverage/container.py#L413-L416
We may as well get rid of this behavior, the thing is, it would take some tweaks both on the scripts and most of the containers definitions,
| auth_method = container.TF_SSO_ENTRYPOINT | ||
| elif container.mfa_enabled: | ||
| auth_method = container.TF_MFA_ENTRYPOINT | ||
| # TODO: ask why this was necessary |
There was a problem hiding this comment.
Hi!
The original use case in which the design was based on (containerized terraform commands, particularly MFA authenticated) made, and makes, quite a bit of effort to avoid overriding the host's credentials, and configuration files for the aws cli.
So the default behavior is to mount those files elsewhere (/tmp), use them as source of truth to know which profiles to assume and generate new aws config files that are going to perish alongside the container everytime a command is run.
With the use of SSO this is less and less common and we should think if it is really worth it.
| auth_method = container.TF_SSO_ENTRYPOINT | ||
| elif container.mfa_enabled: | ||
| auth_method = container.TF_MFA_ENTRYPOINT | ||
| # TODO: ask why this was necessary |
There was a problem hiding this comment.
Considering this: https://github.com/binbashar/leverage/blob/master/leverage/container.py#L413-L416
We may as well get rid of this behavior, the thing is, it would take some tweaks both on the scripts and most of the containers definitions,
What?
Add support to run
kubectlcommands from the leverage CLI.It works by taking the
kubectlconfig file from your home folder and passing the commands directly to the binary.The authentication for AWS (required for EKS) is handled by
leveragetransparently (although is slow, so a topic open for discussion).Why?
To keep unifying flows into a single tool. More details here.
References
New toolbox image required: binbashar/le-docker-leverage-toolbox#43
Open questions (Update: issues were created for all of them already!)
kubectldo we want to support? The binaries are kind of lightweight (~40MB) so we can have multiples on the image and provide a command to do the switch.terraformcommands? That is the approach I took, but is proved to be slow (takes ~2 seconds every time you execute a command). Forterraformis feasible but forkubectllooks like is not. I would like to take another approach.ToDo