Open webvictim opened 4 years ago
@webvictim Is this just for trusted clusters? Or is it OK for a normal cluster?
@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.
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:
This does work:
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:
teleport version
):Teleport Enterprise v4.2.2git:v4.2.2-0-gb06a05d2 go1.13.2
tsh version
):Teleport v4.2.2 git:v4.2.2-0-gb06a05d2 go1.13.2
Fedora 30