{{internal.logins}} ignored on Teleport Enterprise roles

[lrt512]

What happened:

We're doing a PoC of Teleport Enterprise in k8s without using SSO to start. Every user with the admin role has only the root login, even though the role has

  logins:
    - '{{internal.logins}}'
    - root

Very much an edge case, but entertaining.

What you expected to happen:

I was expecting the local user login to be propagated

How to reproduce it (as minimally and precisely as possible):

Just have a role where you have this

  logins:
    - '{{internal.logins}}'
    - root

In this case, tsh status will give only

Logins:     root

If you omit root and only give

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

tsh login will return

*trace.AccessDeniedError this user cannot create SSH sessions, has no allowed logins

Environment:

• Teleport version (use teleport version): Teleport Enterprise v3.1.5git:v3.1.5-0-g7621bbd5 go1.11.5
• Tsh version (use tsh version): Teleport v3.1.5 git:v3.1.5-0-g7621bbd5 go1.11.5
• OS (e.g. from /etc/os-release): Ubuntu 18.04.1

[klizhentas]

Hey Larry, thanks for your report. We will look into it.

[klizhentas]

And just to clarify, it's stopped working for existing users after upgrade or for new local users? If the latter, how did you add new users?

[lrt512]

I'm about to add some context, but all users are on a brand-new enterprise-trial-license deployment via the Helm chart.

Users are created with tctl users add --roles=admin bob

[lrt512]

A few bits of context. I played with this in several ways:

1. Specifiying the login in the role logins, i.e.

# tctl get roles/admin
kind: role
metadata:
  name: admin
spec:
  allow:
    kubernetes_groups:
    - '{{internal.kubernetes_groups}}'
    logins:
    - '{{internal.logins}}'
    - ltremblay
    node_labels:
      '*': '*'

A tsh status then gives

Profile URL: https://teleport...
Logged in as: ltremblay
Cluster: teleport...
Roles: admin*
Logins: ltremblay
Valid until: 2019-02-14 02:04:51 -0500 EST [valid for 12h0m0s]
Extensions: permit-agent-forwarding, permit-port-forwarding, permit-pty

2. Adding the login directly to the user's traits:

# tctl get users/ltremblay
kind: user
metadata:
  name: ltremblay
spec:
  created_by:
    time: 0001-01-01T00:00:00Z
    user:
      name: 00b119bc-923f-4d76-a6ab-88457baca6fb.teleport...
  expires: 0001-01-01T00:00:00Z
  roles:
  - admin
  status:
    is_locked: false
    lock_expires: 0001-01-01T00:00:00Z
    locked_time: 0001-01-01T00:00:00Z
  traits:
    kubernetes_groups: null
    logins:
    - ltremblay

And the output of tsh status is the same as in 1)

In these cases, login works as usual (after logging out, clearing out ~/.tsh for good measure, then logging in to get the reflected changes). It's a bit cumbersome to have to go back and add usernames to roles or user traits after the fact, though!

Of course, yes, SSO integration is the better choice.

[M0nsieurChat]

We've got the same problem for newly created users after upgrading to Teleport Enterprise v3.1.7git:v3.1.7-0-g44074d74 go1.11.5

[sgargan]

Also seeing this since moving to enterprise, wasted a good chunk of evaluation time looking into it.

[russjones]

@lrt512 @M0nsieurChat @sgargan What was your expected behavior of {{internal.logins}}? Also, are you using Enterprise with an SSO provider or with local accounts?

It's a field that's used in OSS to propagate logins for local users through traits. tctl users add jsmith root,jsmith where "root" and "jsmith" become part of the services.User object under traits which then get filled into {{internal.logins}}.

For Enterprise users, the expectation is to add {{external.claimName}} to allow logins to be fetched from an identity provider.

[klizhentas]

alright, let's take another look into it in the context of 4.1

[M0nsieurChat]

@M0nsieurChat @sgargan What was your expected behavior of {{internal.logins}}? Also, are you using Enterprise with an SSO provider or with local accounts?

I don't know, my users were created like so (old syntax, I know ) :
tctl users add johndoe johndoe,ubuntu,root

The logins: dictionnary containing all the logins specificied would do the trick for me :)

We are using Enterprise with local accounts. We plan to switch on SAML by next year.

[klizhentas]

@russjones I don't think it's enough to unhide the flag to solve this issue - we should also re-add processing of internal trait in enterprise mode in addition to the external trait - something we don't do right now.

[russjones]

@klizhentas We do process {{internal.logins}} in Enterprise. There is just no way to set it this trait on services.User which is what the --logins flag does.

[klizhentas]

ok

[webvictim]

I think I just got bitten by this bug as well.

[igtsekov]

I hit this issue also. Any fix/workaround?