K9s: Support AWS authentication.

[umi0410]

Is your feature request related to a problem? Please describe.
I've been using kubernetes with AWS EKS(Elastic Kubernetes Service) and I installed k9s on my macbook. However, oneday I had to use k9s on my teammate's computer and I didn't want to install k9s. So I tried using k9s through k9s docker image. But I couldn't use it because the authentication for EKS needs aws cli.

Describe the solution you'd like

1. Add installation for aws cli command in Dockerfile.
2. Build an image and tag with additional content like 0.21.7-aws or 0.21.7-eks because it is needed by only people who want to use EKS.
3. When someone run a container, what he or she should do is only attaching an additional volume about current aws configure

Describe alternatives you've considered
I'm not sure but some GKE(Google Kubernetes Engine) and AKS(Azure Kubernetes Service) users may need the feature.

Additional context - Example

This is a demo to connect to eks by k9s. It will be very convenient if there is an docker image which includes the following codes and we can use eks( and other cloud kubernetes services someday ) by only with an additional volume.

# Supposing there is an eks cluster
# Attach an aws configuration volume 
$ docker run --rm --name k9s -it -v ~/.kube/config:/root/.kube/config -v ~/.aws:/root/.aws \
--entrypoint sh quay.io/derailed/k9s

# install awscli
$ apk update && apk add python3 && pip3 install awscli

# Let's use k9s. EKS will be available now.
$ k9s

[goffinf]

Personally I’m not a great fan of bundling additional tools inside the
image. This tends to detract from its primary purpose and makes it
much more difficult to maintain, especially for version management.
Also, where does it stop. As you mention there are many different
platforms that the K9s community uses, and all of them have their own
CLI and API toolchain.

For something like the AWS CLI, you could run that in an entirely
separate docker container and mount the binary path and declare any
env vars when launching K9s. If you run a local dev K8s install you
could use an initContainer or sidecar for the same purpose. That way
we maintain a cleaner separation rather than ending up with an über
image.

My 4 cents

Fraser.

On 15/08/2020, Umi [e-mail] wrote:

src="https://raw.githubusercontent.com/derailed/k9s/master/assets/k9s_small.png"
align="right" width="100" height="auto"/>

Is your feature request related to a problem? Please describe.
I've been using kubernetes with AWS EKS(Elastic Kubernetes Service) and I
installed k9s on my macbook. However, oneday I had to use k9s on my
teammate's computer and I didn't want to install k9s. So I tried using k9s
through k9s docker image. But I couldn't use it because the authentication
for EKS needs aws cli.

Describe the solution you'd like

1. Add installation for aws cli command in Dockerfile.
2. Build an image and tag with additional content like 0.21.7-aws or
   0.21.7-eks because it is needed by only people who want to use EKS.
3. When someone run a container, what he or she should do is only attaching
   an additional volume about current aws configure

Describe alternatives you've considered
I'm not sure but some GKE(Google Kubernetes Engine) and AKS(Azure Kubernetes
Service) users may need the feature.

Additional context
Example

This is a demo to connect to eks by k9s. It will be very convenient if there
is an docker image which includes the following codes and we can use eks(
and other cloud kubernetes services someday ) by only with an additional
volume.

# Supposing there is an eks cluster
# Attach an aws configuration volume
$ docker run --rm --name k9s -it -v ~/.kube/config:/root/.kube/config -v
~/.aws:/root/.aws --entrypoint sh quay.io/derailed/k9s

# install awscli
$ apk update && apk add python3 && pip3 install awscli

# Let's use k9s. EKS will be available now.
$ k9s

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/derailed/k9s/issues/840

[derailed]

@umi0410 yes I totally agree with @goffinf here and keeping k9s image vendor agnostic.