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
17.42k stars 1.74k forks source link

Document passthrough of k8s groups and ssh logins in trusted clusters #2489

Open klizhentas opened 5 years ago

klizhentas commented 5 years ago

Description

New feature allows remote cluster to reference the kubernetes groups coming from the roles of the main cluster in the trusted clusters configuration.

For example, main cluster can have a user with a role 'main' and kubernetes groups:

kube_groups: ['system:masters']

and SSH logins:

logins: ['root']

Remote cluster can choose to map this 'main' cluster to it's own: 'remote-admin' cluster in the trusted cluster config:

role_map:
  - remote: 'main'
    local: 'remote-admin'

The role 'remote-admin' of the remote cluster can now be templated to use the main cluster role main logins and kubernetes_groups using variables:

logins: ['{{internal.logins}}']
kubernetes_groups: ['{{internal.kubernetes_groups}}']

This is possible because teleport now encodes both values in X509 certificate metadata and remote cluster passes these values as 'internal' traits to the template engine.

webvictim commented 4 years ago

This doesn't actually work as described, see #3376

webvictim commented 4 years ago

Also see #3402

benarent commented 4 years ago

I'm going to remove from the 4.3 milestone as it looks like it needs more testing / bug fixing.

ptgott commented 2 years ago

I've edited the Trusted Clusters guide to act as more of a step-by-step tutorial (https://github.com/gravitational/teleport/pull/10708), focusing on Server Access. Should we include a separate Trusted Clusters guide for Kubernetes that includes multiple Kubernetes clusters? It might even be worthwhile to add a separate section to the docs related to Trusted Clusters, rather than including all Trusted Cluster-related information in the same guide.