Teleport v3.0 introduces Kubernetes support

AFAIR, "debugging", at least in java allowed you to set a "breakpoint" in codesearch, but essentially something magically was happening behind, where if the CPU goes through this line you've marked as breakpoint it'll remember the surroundings (like variables in that scope, etc).

Furthermore, one could declare (a bit like "live" coding) a one-liner (say in java) that would get called if that lines passes - so you can log something in better fashion, etc. But it had limitations.

First I didn't get it, then it sunk into me - once you have thousands of jobs - it's pointless to try and debug one of them (thousands, as in MapReduce thousands). Not that I've used the feature a lot, but tried it several times and worked fine.

It had nice integration with codesearch, where you can, given your "namespace" and "job" name, can set the codesearch to be "synced" to the CL it built your job + cherrypicks (I guess) - so the code you are looking is the code that your binary got compiled (another benefit of monolith depots, is that such things are easier there, or maybe it'll take a bit more work to get it working with multiple repos).

E.g. magic :)

> Kubernetes projects leads would argue that any time a user has to SSH into one of their K8s workers, they should file a bug against Kubernetes.

Agreed. In general, every time you need to SSH anywhere, it means that there is some tooling you are missing.

In very rare cases, you do need to break the glass to deal with exceptional conditions, but this should be rare.

OIDC tied to a LDAP directory is generally how you setup authentication for larger numbers of users. It really isn't that hard and has a dozen or so solutions with sensible config and operational footprints.

Here is an example of how to do this (OIDC). Notice the short and concise documentation on how to set this up. It isn't too bad at all if you're running your own apiserver already:

https://github.com/heptiolabs/gangway

The obvious benefit is that synchronizes Kubernetes auth with SSH access, i.e. you don't have to authenticate twice if your organization uses SSH-based tools and k8s-based tooling, moreover it extends the same RBAC rules to both SSH and k8s, i.e. "developers must not touch production data" will be enforced for both "ssh production-host" and "kubectl exec production-pod".

The second, perhaps less obvious, benefit is Teleport's built-in audit as shown in the video, i.e. all your interactions with all Kubernetes clusters are logged in one centralized place for audit purposes (and, in the case of the interactive sessions) can be replayed in a Youtube-like player.

But yes, if you don't need the audit, and you don't use SSH, and if you only have one k8s cluster, this may be an overkill.

The biggest difference is that Teleport is a full MITM for all apiserver traffic, leveraging the cluster-local certificate authority for short-lived creds (similar to how K8s internal bits such as the kubelet speaks TLS to the apiserver). Notably this also works with completely air-gapped clusters or end-users, or clusters where you want access to apiserver to be via egress (hidden bastion) only.

K8s authentication methods that go inline with the apiserver, such as oidc or dex, achieve the same goals but are a bit of a different design flavor and arguably less clean from a threat or failure model perspective.

OIDC generally requires additionally add-ins (e.g. Dex, or keycloak) to operate with things like AD.

I don't have a clue and would also like to know.

Whenever there is a 'contact us' pricing page, I don't even bother. I can't even tell my boss to look into it if I don't know what the required budget will be, and I won't give out information to get contacted by sales teams and waste my time on a project that I wasn't even allocated time for.

Plus it won't even be only my time, it will be finance and maybe even legal. So now there are multiple people involved to get a quote before it's even figured out if the solution fits the budget or if it is even a fit for the problem (unless there is some sort of trial).

Whenever a project does this, it had better be the only thing capable of dousing a burning fire to get even considered.