If an attacker can force a username change at an IdP, upon second login,
the services.User object of the original user can be updated with new
roles and traits. If these new roles and traits differ, the original
user can have their privileges raised (or lowered).
To mitigate this, encode roles and traits within the certificate and use
these when fetching roles to make RBAC decisions. If roles and traits are
not encoded within an certificate (for example for old style SSH
certificates then fallback to using the services.User object and log a
warning.
This commit fixes issue #2766.
The prior logic in Kubernetes module used
SNI to route requests to the target kubernetes cluster.
This approach created problems with long cluster names
exceeding 61 character DNS label limit and
required setting up DNS wildcard records.
This commit changes the routing to use the metadata
encoded in client's x509 certificate to route the
request to the target cluster.
SNI approach will be supported for several versions
to preserve backwards compatibility.
Added utils.CertChecker that wraps a ssh.CertChecker. The new
certificate checker first checks if the certificate is a valid
certificate for Teleport. At the moment that is 2048-bit RSA then calls
the underlying certificate checker to perform the requested validation.
* Fetch groups for GSuite SSO. (#2456)
Fixes#2455
This commit adds support for fetching
groups for GSuite SSO logins via
OIDC connector interface.
If OIDC connector has a special scope:
`https://www.googleapis.com/auth/admin.directory.group.readonly`
teleport will fetch user's group membership and populate
groups claim.
* Pass kubernetes groups to the remote cluster. (#2484)
This commit 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.
When many nodes join the cluster or rotate certificates,
auth server was forced to generate may private/public
key pairs simultaneosly creating bottleneck
on the auth server side.
This commit pushes the private public key generation
logic back to clients releiving the pressure from
auth server.
This commit introduced mutual TLS authentication
for auth server API server.
Auth server multiplexes HTTP over SSH - existing
protocol and HTTP over TLS - new protocol
on the same listening socket.
Nodes and users authenticate with 2.5.0 Teleport
using TLS mutual TLS except backwards-compatibility
cases.
