mirror of
https://github.com/gravitational/teleport.git
synced 2026-09-24 16:17:11 +08:00
Andrew Lytvynov
b16ad647b4
This change has several parts: cluster registration, cache updates, routing and a new tctl flag. > cluster registration Cluster registration means adding `KubernetesClusters` to `ServerSpec` for servers with `KindKubeService`. `kubernetes_service` instances will parse their kubeconfig or local `kube_cluster_name` and add them to their `ServerSpec` sent to the auth server. They are effectively declaring that "I can serve k8s requests for k8s cluster X". > cache updates This is just cache plumbing for `kubernetes_service` presence, so that other teleport processes can fetch all of kube services. It was missed in the previous PR implementing CRUD for `kubernetes_service`. > routing Now the fun part - routing logic. This logic lives in `/lib/kube/proxy/forwarder.go` and is shared by both `proxy_service` (with kubernetes integration enabled) and `kubernetes_service`. The target k8s cluster name is passed in the client cert, along with k8s users/groups information. `kubernetes_service` only serves requests for its direct k8s cluster (from `Forwarder.creds`) and doesn't route requests to other teleport instances. `proxy_service` can serve requests: - directly to a k8s cluster (the way it works pre-5.0) - to a leaf teleport cluster (also same as pre-5.0, based on `RouteToCluster` field in the client cert) - to a `kubernetes_service` (directly or over a tunnel) The last two modes require the proxy to generate an ephemeral client TLS cert to do an outbound mTLS connection. > tctl flag A flag `--kube-cluster-name` for `tctl auth sign --format=kubernetes` which allows generating client certs for non-default k8s cluster name (as long as it's registered in a cluster). I used this for testing, but it could be used for automation too.