I love all these fun tools popping up that expose ssh (and non-openssh at that!) as a transport protocol for more interesting stuff. As a person who had to deal with k9s across many EKS clusters (and the config generation mess), I can totally see why you’d want to “just” ssh into the cluster. Impressive.
Yeah! I did the dashboard for fun, and then wired up the ssh -L, ssh -R and scp stuff. That’s when I got really excited about it. ssh has so many rich use cases that I’m not sure folks realize is possible. With kty as it is today, you can replace many of the “remote development” and vpn tools that are k8s specific with nothing more than ssh, something that everyone has and is likely comfortable with.
I think I could see a use-case: single-node clusters with locked-down RBAC exposed for advanced debugging purposes, like an onprem product distributed as a VM image.
Lots of VM images come with half-baked shells that let you configure certs, generate support payloads, etc. while preventing full SSH access so the customer doesn’t break anything.
Just take your cloud-based k8s app, bundle it into a VM running k3s, install kty, grant it access to the “viewer” group in k8s, and suddenly you have an on-prem version of your cloud-native app.
What an interesting use case! Really any kind of access like that. Because kty is using openid providers, you wouldn’t need to create special accounts in your existing solution to provide access.
Also, kty itself doesn’t actually have any access on the cluster. It impersonates the user, so they always have their own granted RBAC.
Great question! This is just hitting the api server after all =) k9s is fantastic, as is kubectl, but they have a couple downsides:
You need to have a kubeconfig setup with an auth plugin. It is always a struggle for me to get that setup based on whatever weird auth system a cluster has been configured to do.
You can do port forwarding with kubectl, but it has limitations and only gets data into the cluster. With this, you can forward arbitrary services on the cluster to your local host.
Obviously kubectl lets you copy files in and out - but again, it has limitations. tar is a reasonable dependency, but not everyone has it in their containers.
I wanted to be able to use a tool that was ubiquitous, like ssh which didn’t require anything crazy from an authentication perspective. It definitely isn’t a replacement for other tools, it is just something convenient that folks who aren’t comfortable with the k8s ecosystem can use to quickly get going.
ssh is very locked down in my environment, so this tool is a non-starter. k9s is a lifesaver, especially when it’s a different team that controls the cluster infra from my own.
k9s is great, but because you need to run it locally - it is really solving a different problem than kty. All you need is ssh, and more importantly, you don’t need a kubeconfig or any kind of auth plugin installed to make it work.
I’ve been using k9s for many years since it’s early days. Great software. Has exactly what one would want when working with Kubernetes. So many times have I wonder if feature X would exist, only to find out that the answer is always yes.
I would not want to work with Kubernetes without k9s.
I love all these fun tools popping up that expose ssh (and non-openssh at that!) as a transport protocol for more interesting stuff. As a person who had to deal with k9s across many EKS clusters (and the config generation mess), I can totally see why you’d want to “just” ssh into the cluster. Impressive.
Yeah! I did the dashboard for fun, and then wired up the
ssh -L,ssh -Randscpstuff. That’s when I got really excited about it.sshhas so many rich use cases that I’m not sure folks realize is possible. With kty as it is today, you can replace many of the “remote development” and vpn tools that are k8s specific with nothing more thanssh, something that everyone has and is likely comfortable with.why an ssh server over just hitting the kube api like kubectl and other tools like k9s do?
I think I could see a use-case: single-node clusters with locked-down RBAC exposed for advanced debugging purposes, like an onprem product distributed as a VM image.
Lots of VM images come with half-baked shells that let you configure certs, generate support payloads, etc. while preventing full SSH access so the customer doesn’t break anything.
Just take your cloud-based k8s app, bundle it into a VM running k3s, install kty, grant it access to the “viewer” group in k8s, and suddenly you have an on-prem version of your cloud-native app.
What an interesting use case! Really any kind of access like that. Because kty is using openid providers, you wouldn’t need to create special accounts in your existing solution to provide access.
Also, kty itself doesn’t actually have any access on the cluster. It impersonates the user, so they always have their own granted RBAC.
I was wondering the same. Is it that the token lives somewhere more secure? But that explanation doesn’t jibe…
Great question! This is just hitting the api server after all =) k9s is fantastic, as is kubectl, but they have a couple downsides:
kubectl, but it has limitations and only gets data into the cluster. With this, you can forward arbitrary services on the cluster to your local host.kubectllets you copy files in and out - but again, it has limitations.taris a reasonable dependency, but not everyone has it in their containers.I wanted to be able to use a tool that was ubiquitous, like
sshwhich didn’t require anything crazy from an authentication perspective. It definitely isn’t a replacement for other tools, it is just something convenient that folks who aren’t comfortable with the k8s ecosystem can use to quickly get going.People who are interested in this may also be interested in k9s
ssh is very locked down in my environment, so this tool is a non-starter. k9s is a lifesaver, especially when it’s a different team that controls the cluster infra from my own.
k9sis great, but because you need to run it locally - it is really solving a different problem thankty. All you need isssh, and more importantly, you don’t need a kubeconfig or any kind of auth plugin installed to make it work.I’ve been using k9s for many years since it’s early days. Great software. Has exactly what one would want when working with Kubernetes. So many times have I wonder if feature X would exist, only to find out that the answer is always yes. I would not want to work with Kubernetes without k9s.
Being able to replay complex cluster interactions after the fact is exciting. I’m looking forward to reading the rest of the posts in the series.
Would this let me use my own open ID provider? I dislike using git or the other ones that other people control.
Yup, bring your own provider. There are a couple requirements on the provider, but it should work fine.