How to allow any login for a user

[sgohl]

The specific use-case is: I want to define a role for a helpdesk team to support Developers on their virtual machines, who of course have their personal name as login, hence the allowed logins can not be defined explicitely.
allowing root for the supporters is not intended.

the role I came up with so far:

kind: role
metadata:
  name: helper
spec:
  allow:
    logins:
    - '{{internal.logins}}'
    node_labels:
      type: dev
  deny:
    logins:
    - root
version: v5

what I certainly want is:

allow:
    logins:
    - '{{internal.logins}}'
    - '*'

which understandably leads to the error message

wildcard matcher is not allowed in logins

what I hope for is that there is some other kind of variable like this '{{internal.logins}}' (which I don't find any explanation for) , but for "any login that is available on the target machine"

As a matter of fact, it would be absolutely sufficient if we'd be able to provide a uid instead of a username, because every user has the same uid of 1000, but that doesn't work either:

allow:
    logins:
    - '{{internal.logins}}'
    - '1000'

[webvictim]

Unfortunately, Teleport's RBAC checks require that you enumerate all individual logins that you might want to use. This is essentially a security feature to avoid inadvertently granting more access than intended.

[ethan-gallant]

What if your company has too many usernames to fit into the multiplexer header, it crashes Teleport auth requests and subsequently locks everyone out?

Asking for a friend 😉

[webvictim]

There are a few ways to solve this problem!

1. Set each user's username as a claim (OIDC) or attribute (SAML) in your SSO provider instead, then pass that username through to the role using the {{external.username}} nomenclature instead:

spec:
  allow:
    logins:
    - "{{external.username}}"

2. If you use individual users, set each user's logins as a trait on each the user themselves:

tctl users update gus --set-logins gus,ubuntu,ec2-user

...then reference that in the role instead:

spec:
  allow:
    logins:
    - "{{internal.logins}}"

This will cause the role to be individually evaluated for each user rather than having a large list which causes problems :)

Docs reference here: https://goteleport.com/docs/reference/access-controls/roles/#traits

[ethan-gallant]

@webvictim we're a PaaS platform and each customer gets their own username. We need customer support to be able to SSH into each customers account, additionally an automated script (using machine ID) periodically runs and scans each customers username so access requests is unfortunately not an option for us.

If we update the OIDC connector with each of the customers usernames periodically opposed to the role, will this work around the issue with the auth service crashing on login?

Using the role method to define the users, we currently get the below error and get locked out of Teleport. This happens when we reach about 600 entries in the users attribute.

2024-09-18T22:55:19Z WARN [MXTLS:1]   Handshake failed. dst_addr:[10.141.113.227:443](http://10.141.113.227:443/) error:[tls: handshake message of length 75965 bytes exceeds maximum of 65536 bytes] src_addr:[142.167.220.246:52809](http://142.167.220.246:52809/) multiplexer/tls.go:152

[webvictim]

@ethan-gallant Got it - sorry, I misunderstood what you were asking for the first time. Your use case is quite unique.

Using the OIDC claim instead will probably prevent the auth server crashing on startup, but it will still inevitably lead to the same outcome. I think you've been back and forth with our support team on this with potential mitigations (partitioning users into different roles) and I do know we have the dev team looking into it, so hopefully we can come up with a solution that way.