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.64k stars 1.76k forks source link

Role mapping across trusted clusters does not work if `{{internal.logins}}` trait is the only one specified #3402

Open webvictim opened 4 years ago

webvictim commented 4 years ago

What happened: Most of this issue is essentially a duplicate of #3376

The behaviour of {{internal.logins}} is broken in the same way as {{internal.kubernetes_groups}} is - if you only specify {{internal.logins}} and no other values on a role, logins do not get mapped correctly. If you add any other value at all, it works as expected.

To clarify - this does not work:

kind: role
version: v3
metadata:
  name: dev
...
spec:
  allow:
    logins:
    - '{{internal.logins}}'
...

This does work:

kind: role
version: v3
metadata:
  name: dev
...
spec:
  allow:
    logins:
    - dummylogin
    - '{{internal.logins}}'
...

What you expected to happen: Logins should be correctly mapped across using the {{internal.logins}} field, regardless of other login values.

How to reproduce it (as minimally and precisely as possible): See #3376 and Zendesk issue 1098.

Environment:

benarent commented 4 years ago

@webvictim Is this just for trusted clusters? Or is it OK for a normal cluster?

webvictim commented 4 years ago

@benarent I think there's only a need to use {{internal.logins}} when mapping across clusters, as you don't normally need to make any reference to that trait in the roles that a cluster uses internally.

The use case here is when you want to define a list of logins once on a root cluster, then have a leaf cluster automatically pick that list up when the role gets mapped over - without needing to have a matching list of logins on the leaf side.

I think we add {{internal.logins}} to the logins: section of any role created via the web UI by default for exactly this reason - the idea is that unless otherwise specified, you should always be able to 'inherit' a list of logins when mapping roles from the root of a trusted cluster to a leaf.