search

gravitational / teleport

The easiest, and most secure way to access and protect all of your infrastructure.
https://goteleport.com
GNU Affero General Public License v3.0
16.89k stars 1.7k forks source link

Socks proxy #10301

Open KlavsKlavsen opened 2 years ago

KlavsKlavsen commented 2 years ago

What

Add socks proxy for Kubernetes connections.

How

Use the socksproxy lib you seem to already have - to simply route http traffic via the teleport-kube-agent (and perhaps allow for optional fitering of urls - but since we're admins - not necessary for us)

I could simply setup privoxy (or firefox foxporxy plugin) - to route traffic with certain domain name to the socksproxy port that my local tsh listens on for socks proxy connections - when I have a connection to a k8s cluster.

Why

When we need to login to services on the cluster - like grafana, or argocd etc. - they are all integrated with Keycloak SSO - which as all other SSO's - will redirect my browser to a url accessible "on the kubernetes cluster side - often an internal one" - which won't work - and hence I cannot login to the web services on the cluster - unless I put them all on a public network or am behind a VPN (which was the point of using teleport - to avoid the VPN :)

Workaround

SSH to a node on same network and do socks proxy to that (part of SSH)

webvictim commented 2 years ago

I think you should be able to use Teleport application access to solve this issue. If you ran an agent inside the cluster and served the grafana.default.cluster.svc.local:3000 address via application access, you could then change your SSO redirect URLs to point to https://grafana.teleport.example.com instead, which should work...

KlavsKlavsen commented 2 years ago

SSO OICD urls are put in ALL configurations.. keycloak, k8s itself etc. - you want me to change ALL of those configs to use a teleport address / which would make them no longer work - for those NOT accessing it via teleport (ie. those on local network) :(

KlavsKlavsen commented 2 years ago

teleport application access really should have been a socks implementation instead - which IS the standard way of doing this (which is why SSH etc. supports it and there are even plugins for this in browsers and standard support in all browsers..

PaulFederato commented 11 months ago

@webvictim, I am in the same boat as @KlavsKlavsen but with Github SSO. I'd also like to add that if I went the route of changing all of the URLs then my developers would be unable to access critical applications until they all switch to Teleport, making it much harder to adopt this system.

Please consider adding socks proxy configurations