Support MFA prompt for aws-iam-authenticator

mitom commented 4 years ago

What would you like to be added: Support for prompting for MFA codes for AWS auth

Why is this needed: When the role needed to use a cluster enforces MFA, Lens does not prompt for it, it times out on connecting. The workaround for this, is to assume the role in the CLI and export access/secret keys, then Lens can use this role and connect to the cluster without problem. However, this method limits the cluster switching functionality to 1 account.

Environment you are Lens application on:

Kubernetes distribution: EKS
Desktop OS: OSX

omriarieli commented 4 years ago

Hi, we also would very like to see this as we want to delete kubernetes dashboard but our developers are using assume role to see resources like logs etc.. @mitom this trick does not work for me, i assumed my role then exported access key id and secret access key but still lens cannot connect to the cluster

arohter commented 4 years ago

We're not using aws-iam-authenticator to perform SSO step, but we leverage the de-facto credential_process method to do this:

in kubeconfig:

users:
- name: dev
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      env:
      - name: AWS_PROFILE
        value: prof-dev
      command: aws
      args:
      - eks
      - get-token
      - --cluster-name
      - my-cluster
      - --role
      - arn:aws:iam::942566782114:role/assumed-dev

in ~/.aws/config

[profile prof-dev]
region = us-east-1
credential_process = aws-okta cred-process ...

Kubeconfig is setup to invoke aws-cli command to get eks creds via an assumed role, and then leverages aws-cli/sdk credential_process to shell out to 3rd party SSO provider to get initial IAM credentials.

Nuru commented 4 years ago

I think this is something that is not reasonable for Lens to do. Asking for your MFA token is the responsibility of your credentials provider, and AFAIK there is no standard or even common way for Lens to facilitate that. Lens can and should notify you that it cannot access the cluster due to invalid credentials (see #250, #346), but after that you need to take that up with your credentials provider.

As @arohter pointed out above, you can have multiple clusters each using a different AWS IAM role by specifying the role ARN in the Kubeconfig. I have this working currently for multiple clusters, each with a different AWS account and different role ARN.

I think it is more than reasonable and appropriate for Lens to have the same behavior as kubectl with respect to authentication, which is that kubectl executes the command specified in the kubeconfig and errors out if it fails. The current problem is mainly #346 and lack of documentation.

omriarieli commented 4 years ago

@Nuru our kubectl works with assume role and when you use kubectl command it asks for mfa pin. that prompt just doesnt appear in lens the command kubectl is configured to run is aws-iam-authenticator to get a token. in my opinion lots of people are working like that and lens would miss on a lot of audience as they would not be able to work with this great app.

Nuru commented 4 years ago

@omriarieli Actually, the MFA prompt is not coming from kubectl, it is coming from aws-iam-authenticator. Even then, it only works because you have already done a bunch of stuff to get it to work, including setting up profiles in your $AWS_CONFIG_FILE and somehow getting credentials in a place that aws-iam-authenticator can find them. Because aws-iam-authenticator is a command-line tool, it asks for MFA on the command line. The appropriate place to make this feature request (that the MFA prompt should use a system dialog/popup and not the terminal, or at least have a configuration that allows that) is there.

I go into the issue in greater detail here, but the short story is that you have to configure your system in such a way that aws-iam-authenticator can get the credentials it needs when run by Lens with no environment variables. This is really up to you, not Lens. Yes, I agree that Lens should alert you when it needs you to update your credentials (see #346), but there are too many different ways people get credentials for Lens to take on the task of providing them. Lens is not specific to AWS, it is a Kubernetes tool. It should not get involved beyond the confines of kubectl because that is work other people can and have done. I would much prefer the Lens team work on the feature requests that only they can implement.

What ~I would~ used to (see later recommendation to use Leapp) recommend in your case is that you use a tool like aws-vault to handle creating a temporary session and caching your MFA and running an AWS metadata server that aws-iam-authenticator can access. This ~will probably~ unfortunately does not work better in aws-vault version 6, ~due out soon~, and is broken in version 5; for now I use version 4 this way:

I create an AWS access key and save it in my keychain using aws-vault add (one-time setup)
I open a terminal window and run:
```
aws-vault exec --assume-role-ttl=1h --session-ttl=12h --debug my_profile -- sleep inf
```
(I use --debug just so I have status updates in the window, it is not really necessary.)

Here, my_profile can either be for the role kubectl needs or for a role that can assume the role kubectl needs, depending on what works best for you. It will prompt you for your keychain password and your MFA and then serve temporary credentials via a local AWS metatdata server that aws-iam-authenticator can access. When your session expires, aws-vault will try to renew it. If it needs a new MFA token, it will prompt you in the terminal window. With the server running, aws-iam-authenticator can get the credentials via TCP, which will continue to work when it is called (indirectly) by Lens.

If you think all of the above is too hard or too complicated or you try it and it does not immediately work right, then you see my point about it being a bigger task then Lens should take on.

omriarieli commented 4 years ago

@Nuru i see it differently, if kubectl supports aws-iam-authenticator the i think it should be transparent. as to your suggestion for aws-vault it can work but what if my organization has 1000's of employees working on kubernetes and configured their kubeconfig like that? i dont think thats a realistic ask for a whole organization to change their configs and install additional software so they can see their logs in a gui. i appreciate the info non the less. Thanks

mitom commented 4 years ago

@Nuru thank you for your insight. I can understand your reasoning on this not necessarily being the concern of Lens to solve and that it's a kubernetes focused tool not an EKS focused one. At the same time, as it was pointed out, we can just run kubectl without any extra steps and we'll get a prompt for MFA, which makes it seem like this workflow is supported by kubectl.

You're correct, under the hood kubectl just runs an external program and expects it will be good to go after. In a sense, kubectl on the terminal expects to work with other terminal programs. Lens aims to be kubectl in the GUI (apologies, I know this is not their words but mine), so by that logic it could expect to work with other GUI programs as you suggested raising it with aws-iam-authenticater to adda GUI prompt. The problem is that kubectl is the standard k8s tooling, so everything will aim to be compatible with it, whilst Lens isn't, so nothing will aim to be compatible with it. So the choice is either for Lens to ignore this and expect everything else will change, or for it to recognise it needs a way to interact with the rest of the k8s ecosystem in the GUI - which could be something like "if this kubectl config has a command to execute, open an interactive terminal and run it in there" (which may or may not work).

EKS is one of the biggest k8s platforms and this is a standard workflow - i.e. mandatory MFA/SSO - in any enterprise accounts and most others as well in my experience. It's entirely up to Lens to decide if they want to cater to their workflow or not, come up with an alternative way of achieving this. I'd personally not disregard the problem because it applies to EKS (and anything else requiring a user-prompt to authenticate) and not kubernetes in general given that EKS makes up a significant portion of all k8s clusters.

jakolehm commented 4 years ago

@mitom @omriarieli how does Lens currently work in that MFA scenario? Does it show that input is needed without option to actually input anything? Or is input/prompt completely hidden?

mitom commented 4 years ago

@jakolehm It does not prompt at all or provide information why it failed, when ran from the UI it simply sits on the "Connecting..." screen. When ran from the terminal to debug, it prints an "Unauthrozied" error but does not offer why. I'm not sure if the behaviour changed since I opened this ticket originally as this issue has rendered it useless for me and I went back to k9s.

Nuru commented 4 years ago

@mitom @omriarieli I agree with you that it would be nice for Lens to support MFA and I am sure it would be a great convenience for you. It would be a convenience for me, too. If you want to implement it and provide a pull request for it, I would support it and applaud you if it works.

However, I consult for a number of different companies, so perhaps have a wider perspective on this than you do. I can tell you that in sample of 6 companies I see 4 different ways to manage AWS authentication and MFA tokens (and none of them are using aws-iam-authenticator, though even if they were, my opinion on this issue would not change). This is a part of the security infrastructure part of the organization, and tends to be idiosyncratic, making it too big and complicated a job for Lens.

I predict that if the Lens team gets it working for aws-iam-authenticator using AWS SSO, that it still won't work for some other tools people use, and then the argument will be, "well, you did it for that, why not for this?" And then the request will be "can you integrate it with 1Password so that 1Password automatically fills in my MFA token." It can suck up an enormous amount of time, and any fixes Lens makes will only support Lens, not any other GUI tool in the world.

If you look at the aws-iam-authenticator code you see they have already made the mechanism for getting the MFA token pluggable/configurable. And once they add the option for getting it from the GUI, it will provide a solution for every GUI tool you want to use, not just Lens.

At the moment, Lens has 58 open Feature Requests, I would rather the Lens team work on the ones that only they can fix, and push the security tool providers to provide general support for GUI tools that will go beyond just Lens.

Nuru commented 4 years ago

@mitom wrote:

EKS is one of the biggest k8s platforms and this is a standard workflow - i.e. mandatory MFA/SSO .... I'd personally not disregard the problem because it applies to EKS (and anything else requiring a user-prompt to authenticate) and not kubernetes in general given that EKS makes up a significant portion of all k8s clusters.

@mitom, I really do understand your point of view: it is a very user-centered product design view that I usually champion. You want your tools to work for you and not have to work extra to make the tools function. It is because I generally share your view that I am making such a point to disagree with it here. And even then, my disagreement is not based on the outcome, as I certainly want you to be able to use Lens. My disagreement is with who should make that possible and how.

I do not disregard this problem, I share it. I have had access to dozens of Kubernetes clusters across several companies. Some of them are EKS clusters. All of the AWS credentials I have require MFA. And I am using Lens successfully every day because I make my authentication tools support the tools that need authentication and ask for it in standard ways. Lens is asking for authentication by asking for a kubeconfig file: that is a standard way, and, except for caching the file rather than taking a reference to it, Lens is doing everything else with it in a standard way. @omriarieli, If I am running an organization of 1000's of engineers, then it becomes even more important to ensure that the authentication system supports the tools that use it rather than expecting the tools to do something non-standard to support our authentication system. (You may think running kubectl without a terminal is non-standard, but it is not, and the standard for kubectl authentication plugins says they should work without a terminal.)

I support the Lens team fixing #346 and #324 so that their kubectl can use the same kubeconfig file your kubectl is using and let you know when authentication has failed. That is where I strongly recommend drawing the line. Just getting that far is going to be pretty hard work. If the team is up for it, and after they have those bugs fixed, I could be convinced to support them creating a sort of plugin for kubectl to give it a terminal context (I have a design in mind) but I think it is a crappy solution that no one is going to be happy with. In any case, you are going to have to wait for it, and why wait when you can get it working now.

I posted one possible solution for @omriarieli and I was going to post another one for you, @mitom, but I did not know enough details about your setup. Even if I did, I do not know how you want it to work. How often do you want to enter your MFA token? Where are you getting it from. When Lens is running in the background, do you want a dialog box to pop up in front of whatever you are doing and ask for the MFA code, or do you want it to wait until it is the active (front-most) application? Or are you on a Mac and want to get a Notification that you need to refresh your credentials?

You will be much happier in the long run with a solution you design yourself using the tools available.

Here is a very simple way for you to get started, and you can build from there:

Open up a terminal window running bash
Run while kubectl auth can-i -Aq list ns; do sleep 10; done
Respond to prompts for your MFA token as needed
If the loop exits, start it again
Use Lens between prompts

shogomuranushi commented 4 years ago

I'm one of those who uses assume-role in MFA. Lens is very good, so I tried to find a way to enable MFA but not enter the MFA Pin on Lens.

For now, I think aws-mfa is the most preferable.

Create a .aws/credentials that looks like this.

[default]
aws_access_key_id = xxxx
aws_secret_access_key = xxxx

[dev-long-term]
aws_access_key_id = xxxx
aws_secret_access_key = xxxx
aws_mfa_device = arn:aws:iam::xxxxxxxxx:mfa/shogo.muranushi
assume_role = arn:aws:iam::xxxxxxxx:role/AdminRole

Execute the following command to enter the MFA.

$ aws-mfa --duration 43200 --profile dev

Then .aws/credentials will be in the following state

[default]
aws_access_key_id = xxxx
aws_secret_access_key = xxxx

[dev-long-term]
aws_access_key_id = xxxx
aws_secret_access_key = xxxx
aws_mfa_device = arn:aws:iam::xxxxxxxxx:mfa/shogo.muranushi
assume_role = arn:aws:iam::xxxxxxxx:role/AdminRole

[dev]
assumed_role = True
assumed_role_arn = arn:aws:iam::xxxxxxxx:role/AdminRole
aws_access_key_id = xxxx
aws_secret_access_key = xxxx
aws_session_token = xxxx
aws_security_token = xxxx
expiration = 2020-06-01 16:23:43

You can now access the EKS cluster that references the dev profile from Lens.

As @Nuru says, I think it's heavy to put the responsibility around authentication on Lens. However, there are many environments that require MFA input, and users would be happy if they could use Lens without tools like aws-mfa.

odg0318 commented 4 years ago

I hope this feature +1

tklovett commented 4 years ago

I use the AWS CLI's aws eks get-token for authentication using MFA:

- name: my-cluster
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - eks
      - get-token
      - --cluster-name
      - my-cluster
      command: aws

I also experienced the issue on first boot of Lens failing authentication due to missing MFA token. However! if you use your terminal to assume the AWS role and run open within that shell, Len's will inherit the AWS_ auth env vars!

Opened applications inherit environment variables just as if you had launched the application directly through its full path.

Replace aws-assume with your tool du jour – as long as it exports the AWS_SESSION_TOKEN and other AWS_.* environment variables, you should be good to go.

> aws-assume $role open /Applications/Lens.app/

rr-paras-patel commented 4 years ago

I use Lens with aws-okta to get aws credential and inject into same shell in which the Lense process starts. it works smoothly. e.g. alias on my .file with macOS alias olo='killall '\''Lens'\''; aws-okta exec AWS-PROFILE_NAME -- open -a '\''Lens'\' It's been year i am using like this.

jurgenweber commented 4 years ago

https://github.com/lensapp/lens/issues/595 is maybe a dupe? BTW this feature would be absolutely amazing.

sjonni1 commented 3 years ago

#

I use the AWS CLI's aws eks get-token for authentication using MFA:
- name: my-cluster
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - eks
      - get-token
      - --cluster-name
      - my-cluster
      command: aws
I also experienced the issue on first boot of Lens failing authentication due to missing MFA token. However! if you use your terminal to assume the AWS role and run open within that shell, Len's will inherit the AWS_ auth env vars!

Opened applications inherit environment variables just as if you had launched the application directly through its full path.

Replace aws-assume with your tool du jour – as long as it exports the AWS_SESSION_TOKEN and other AWS_.* environment variables, you should be good to go.
> aws-assume $role open /Applications/Lens.app/

I like this method, aws-mfa works really well.

Nokel81 commented 3 years ago

related to #200

rpadovani commented 3 years ago

After having spent a bit to make this working, I'm gonna share what I did for future reference with aws vault on linux: first, you probably want to read this issue.

TL;DR: You set up your kubeconfig like this:

users:
- name: REDACTED
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      command: aws-vault
      args:     
        - exec
        - YOUR_PROFILE
        - --prompt=ykman
        - --
        - aws
        - "eks"
        - "get-token"
        - "--cluster-name"
        - "REDACTED"
        - "--role-arn"
        - "REDACTED"

If you don't have a yubikey, and you need to enter a TOTP from another application, you can just use --prompt=zenity instead of --prompt=ykman. It will show you a popup where you can enter your code.

If you encounter an error that aws-vault is not in your $PATH, 'cause you have installed it locally to your user, you can do something like this (it's bad and ugly, I know, I am open to other suggestions):

sudo ln -s ~/.local/bin/aws-vault /usr/bin/aws-vault

hlascelles commented 3 years ago

You could try an absolute path... This works great for me.

users:
- name: REDACTED
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      command: ~/.local/bin/aws-vault
      args:     
        - exec
        - YOUR_PROFILE
        - --prompt=ykman
        - --
        - ~/.local/bin/aws
        - eks
        - get-token
        - --cluster-name
        - REDACTED
        - --role-arn
        - REDACTED

jcogilvie commented 3 years ago

I tried out Lens today and expected it to have some kind of behavior like OP suggests.

I'm reading through the workarounds on this thread, but the problem is--if I understand correctly--they all want me to take an additional step which I've put a lot of effort into getting rid of (i.e., manage the auth token lifecycle externally on my own; the ability of aws-iam-authenticator to transparently/implicitly ask me for MFA when it's needed has been a huge blessing) and/or manage environment variables as state, which is problematic in my multicluster env.

Currently-observed behavior trying to connect to a cluster with a role that hasn't had its auth token refreshed recently is:

/usr/local/Cellar/python@3.9/3.9.5/Frameworks/Python.framework/Versions/3.9/lib/python3.9/getpass.py:91: GetPassWarning: Can not control echo on the terminal.
passwd = fallback_getpass(prompt, stream)
Warning: Password input may be echoed.
Enter MFA code for arn:aws:iam::...:mfa/my.user:

2021/08/30 16:54:12 http: proxy error: getting credentials: exec: exit status 255

I know the fix is probably bigger than I make it sound, but really all that needs to happen here from a UX perspective is to open this in a real-enough terminal that I can type the answer to the prompt, rather than pretending to be a terminal just enough to pass me its stdout/stderr.

Nuru commented 3 years ago

@mitom @jcogilvie @omriarieli @amarouni @jakolehm I have a new solution for you.

As I said back in May 2020, I do not think this is something reasonable to ask Lens to implement. You may have a better sense of why I think that after you look at what has gone into building the tool that I am recommending you use to solve this and several other related problems: Leapp. It is a free, open source tool securely manages your AWS credentials and is a replacement for aws-vault, aws-mfa, saml2aws, aws-google-auth, and aws sso. It is an app based on Electron which gives it a GUI, and web-browser features like rendering web pages, running JavaScript, and saving cookies. Among its features are a system-level prompt for MFA tokens when needed (on macOS, it uses macOS notifications) and an app window.

Leapp is the solution to this problem, but as you can see if you dig into it, it is complex enough to implement that it warrants being its own standalone application. This is not something the Lens team should be investing time in, both because it is hard and complicated and because the solution, once developed, merits distribution as its own tool.

Note that once you configure your computer to use Leapp, it will provide AWS credentials management (login, logout, MFA token requests) via its GUI for anything on your system that uses the AWS SDK and has access to your $HOME directory. This means I can (and do) even use it inside Docker containers if I mount my home directory into the container and set up appropriate environment variables. (Leapp handles Azure credentials, too.)

Nuru commented 3 years ago

@jurgenweber @mhenrixon @ovidiusabou @bzlom I don' t know why you gave thumbs-down to my comment recommending Lens developers focus on Lens features and let someone else provide security tools, but that is in fact what has happened. Mirantis has invested a lot in developing Lens features that only they could develop and Noovolari has developed Leapp to handle the security aspect of cloud computing not only for Lens, but for every application that needs it. This is much better for everyone.

jcogilvie commented 3 years ago

You seem like a reasonable person @Nuru and reasonable people can disagree.

Lens bills itself as the IDE--an Integrated Development Environment--for Kubernetes. The google byline says "Lens is the only IDE you'll ever need to take control of your Kubernetes clusters. It is a standalone application..."

But if I have to use yet another tool in my workflow to handle something that works out-of-the-box in conjunction with kubectl, that's a failure of Integration and Lens is no longer the 'only thing I'll ever need.'

I'm coming from a background of using JetBrains products, which have kitchen-sink integrations with everything under the sun, and to my mind, that's an IDE's job. And in the event they don't integrate well, they at least give me a CLI to set things up myself.

If Lens can build me an integration with Leapp that pops up in-band, I'd certainly consider using that. But as a standalone app Leapp is way overkill for my needs and it doesn't actually solve the problem I'm trying to express.

To my eye, the entire point of this issue is doing auth in-band. Adding another tool doesn't solve that issue, which is why you're getting downvoted on this, an issue about doing auth in-band. You appear to be telling people the problem they have isn't a problem.

Nuru commented 3 years ago

@jcogilvie wrote

You seem like a reasonable person @Nuru and reasonable people can disagree.

Indeed. I mostly am responding to ensure that we both have all our facts straight, and then we can reasonably disagree about how to deal with them.

Lens bills itself as the IDE--an Integrated Development Environment--for Kubernetes. The google byline says "Lens is the only IDE you'll ever need to take control of your Kubernetes clusters. It is a standalone application..."

Yes, it is a standalone application that, like many others, still requires you to have a supportive platform to run it on.

But if I have to use yet another tool in my workflow to handle something that works out-of-the-box in conjunction with kubectl, that's a failure of Integration and Lens is no longer the 'only thing I'll ever need.'

Not sure exactly what you mean here about "something that works out-of-the-box in conjunction with kubectl". Your current configuration, as I understand it, requires that you have installed the aws CLI and configured a file like ~/.aws/config, and then created a "kubeconfig" file that is configured to call the aws CLI. And yes, that combination of command line tools only works on the command line when it comes to prompting for MFA tokens.

I would not, however, characterize either kubectl or aws as things that work "out-of-the-box" together. aws sso is even worse, requing that you launch a web browser and copy and paste an authentication code, as well as set up your AWS config file. Leapp handles all of that for you in one application with a consistent UI.

The current situation with Lens is that if, on the command line, kubectl get ns works (returns a list of namespaces), Lens works. That is pretty good integration by my standards.

I'm coming from a background of using JetBrains products, which have kitchen-sink integrations with everything under the sun, and to my mind, that's an IDE's job.

JetBrains doesn't ship Docker desktop so you can run Docker containers, they expect you to download, install, and configure it. AFAIK, they do not ship an aws CLI or SDK, either. Like Lens, they expect you have have a kubeconfig set up that provides access to your Kubernetes cluster and leave it up to you to set that up.

I am not aware that JetBrains (an expensive closed-source commercial IDE, not a free open-source IDE like Lens) has a solution for prompting for MFA codes to refresh AWS sessions integrated into their IDE. I use IntelliJ, so please show me how they do it so I can start using it. All I get is an error message in the error log that it can't connect to the server. (Until I started using Leapp; now I get the standard Leapp prompt for a new MFA token.)

And in the event they don't integrate well, they at least give me a CLI to set things up myself.

Again, not quite sure what you mean there. You still have the same kubernetes and aws CLI commands to use to keep your Kubernetes connection authenticated. When Lens has an authentication failure, you have the CLI to restore the connection.

If Lens can build me an integration with Leapp that pops up in-band, I'd certainly consider using that. But as a standalone app Leapp is way overkill for my needs and it doesn't actually solve the problem I'm trying to express.

I don't really know what you mean by "in band". If I'm using Lens and it stops working and Leapp puts up a notification that my MFA needs to be refreshed, that is good enough for me, and actually preferable to having 2 different apps trying to refresh the MFA token at the same time. It has the added advantage that it requires no work from Mirantis (nothing to integrate) and works the same on my system for every application (kubectl, aws, Lens, etc.) that needs AWS authentication. It also has the advantage of supporting Azure the same way, so I can use Lens with Kubernetes deployed on Azure, again without needing anything more from Mirantis.

I think probably the best solution Mirantis could come up with for adding some kind of MFA prompt to Lens would have a window pop up to ask for the MFA token, but that window might pop up in Lens while you are working on the CLI where you also get prompted for the token by kubectl/aws, and if you entered it there (on the command line), there would be no way for Lens to know about it. And then if you saw the window in Lens and entered another MFA token, at best it would be a hassle that you had to repeat the step, and at worst it might break your CLI session.

Even then, this only solves the problem for authentication with a TOTP 6-digit string you type it. What if you have a U2F hardware key as your second factor? Or are using push notifications to a smartphone app for 2FA because you are using Google Workspaces (formerly Gsuite) to provide federated login to AWS?

To my eye, the entire point of this issue is doing auth in-band. Adding another tool doesn't solve that issue, which is why you're getting downvoted on this, an issue about doing auth in-band. You appear to be telling people the problem they have isn't a problem.

I'm telling people that the problem of AWS authentication is not a problem of managing a Kubernetes cluster. For Lens to solve your problem the way everyone on this thread seems to want it solved, Mirantis would have to implement Leapp, and you would still need to configure it, and there is still a decent chance it would conflict with your other uses of AWS clients. You think Leapp is "way overkill" for your needs, but I do not think Lens could handle all the use cases without implementing something about as complex as Leapp, making to me think it is "way overkill" to ask Mirantis to do it.

I want Mirantis to assume that they have a kubectl they can use to talk to the cluster and work on everything Kubernetes based on that assumption. I don't want them working behind kubectl to make kubectl work with clusters, because they are not the right people to do it and it takes away from what only they can do, which is improve Lens' management of a Kubernetes cluster.

Of course everybody, including me, would like everything to "just work". If Mirantis wants to make it happen, great. Unfortunately, we live in a world of limited resources, and I want to see them most effectively deployed. At the moment, to me that looks like letting Noovolari work on everything related to managing cloud authentication on a workstation (and not caring about Kubernetes at all) and letting Mirantis work on everything Kubernetes (without caring about authentication).

Also, before you knock out Leapp as "way overkill" that "doesn't actually solve the problem", I suggest you give it a try.

joebowbeer commented 3 years ago

To my surprise, I'm liking the Leapp solution. Now I can use lens as easily as I can use octant or k9s.

AndrewFarley commented 2 years ago

FYI: I think #595 is a more universal and on-point solution for this problem. Allowing an interactive console and/or a pre-connect script would solve the use-case for any and every 2FA-based auth for k8s out there afaik (and not just be AWS-specific as this issue is). I'd recommend closing this issue and deferring attention to that one.

In regards to some of the feedback from the team about Lens "not dealing with this", I think that makes this application have a huge hurdle for folks who practice better/best-practice security practices mandatorily in their organization. I can only imagine trying to train a bunch of folks to DiY a shell script and have to make sure Lens is not started, run 2fa, then after 2fa is complete in this console open the app (on OS-X, anyway) which then has the env vars needed to connect successfully. And THEN if they want to switch clusters (eg: from dev to staging) they need to quit Lens, and re-run a new script, and open a new copy of Lens after manual 2FA in the CLI and choose the different kube profile and server, ad infinity. I would ask you to seriously reconsider the demand/need for this, as this will be a necessity to handle "natively" in Lens especially for larger-tier (large to enterprise companies) adoption.

Also, I'd add a note; that suggesting to use YET ANOTHER app (Leapp) on top of Lens is a huge hurdle especially in an large/enterprise company, because now they need to audit and approve enterprise-wide usage of two pieces of software. The enterprises I have worked for in recent history would not accept such terms. They often already have standard 2FA enterprise-wide (RSA / DUO), and/or existing password solutions (LastPass/1Password), and would never accept usage of a different tool which offers the (arguably) same/similar features as already well-known and accepted techs in this field.

Hasgaroth commented 2 years ago

It is possible to use Lens combined with MFA and aws-vault using the following command line to start Lens, and supplying my MFA token on the command line.

 aws-vault exec --duration=4h {your_profile} -- /Applications/Lens.app/Contents/MacOS/Lens

My credentials are stored in aws-vault as primary

I have the following configuration in my ~/.aws/config file

[profile primary]
region=eu-central-1
source_profile=primary
mfa_serial=arn:aws:iam::{primary_account}:mfa/my-user

[profile dev]
include_profile=primary
role_arn=arn:aws:iam::{remote_accout}:role/{remote_role}

Lens starts up ok, and can connect to the cluster in the relevant AWS account.

To connect to another EKS cluster in another AWS account, just exit Lens, and restart using an alternate profile.

Nuru commented 2 years ago

I continue to recommend Leapp for managing your AWS and Azure credentials, including MFA, but for people like @AndrewFarley for whom adding an app is a "huge hurdle", you can also pass the credentials to Lens (and everything else that uses the AWS SDK) via the AWS_SHARED_CREDENTIALS_FILE.

In your KUBECONFIG file you set up the environment variables by adding to the user.exec portion:

      env:
      - name: AWS_PROFILE
        value: my-profile
      - name: AWS_SHARED_CREDENTIALS_FILE
        value: ~/.aws/credentials.my-profile

Then you can use whatever tools you want to use to get yourself an MFA-authenticated session and stash the session keys in the credentials file. In this way you can work with as many clusters in parallel as you want from a single Lens app instance.

Note that this is a standard AWS SDK mechanism for passing credentials. Also, for people worried about writing credentials to disk, note that you should only be writing short-lived session credentials to disk and that the AWS SDK is probably already writing them to disk in ~/.aws/cli/cache/ and/or ~/.aws/sso/cache/.

One way you could populate the file is with a bash script, like this:

creds="~/.aws/credentials.${AWS_PROFILE}"
printf "[%s]\n" "${AWS_PROFILE}" > "$creds"
printf "aws_access_key_id=%s\n" "$AWS_ACCESS_KEY_ID"  >> "$creds"
printf "aws_secret_access_key=%s\n" "$AWS_SECRET_ACCESS_KEY" >> "$creds"
printf "aws_session_token=%s\n" "$AWS_SESSION_TOKEN" >> "$creds"
printf "region=%s\n" "${AWS_REGION:-${AWS_DEFAULT_REGION}}" >> "$creds"

Then you could populate it by running

aws-vault exec {your_profile} -- this-script

Is this a bit annoying and clunky? Yes, that is why I recommend using Leapp instead. This is just for those who feel using Leapp is too big a hurdle, yet still want to be able to access multiple clusters requiring differing AWS credentials from within a single instance of Lens.

Mattie112 commented 2 years ago

We'd also like this feature :)

@Nuru, could you elaborate how to achieve this with Leapp? I did not get it to work (might be a bit offtopic for this issue so you can also comment here https://github.com/Noovolari/leapp/issues/254). Thanks for any pointers you can provide!

Nuru commented 2 years ago

@Mattie112 See comment here about how to set up Leapp and here about how to set up your KUBECONFIG to allow Lens to access your AWS EKS cluster.

lensapp / lens

Support MFA prompt for aws-iam-authenticator #208