Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
webvictim opened this issue Mar 4, 2020 · 2 comments
Labels
bug rbac Issues related to Role Based Access Control trusted-cluster

Comments

@webvictim
Copy link
Contributor

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:

  • Teleport version (use teleport version): Teleport Enterprise v4.2.2git:v4.2.2-0-gb06a05d2 go1.13.2
  • Tsh version (use tsh version): Teleport v4.2.2 git:v4.2.2-0-gb06a05d2 go1.13.2
  • OS (e.g. from /etc/os-release): Fedora 30
@benarent
Copy link
Contributor

benarent commented Mar 4, 2020

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

@webvictim
Copy link
Contributor Author

webvictim commented Mar 4, 2020

@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.

@webvictim webvictim added this to the 5.0 "Snoqualmie" milestone Sep 1, 2020
@zmb3 zmb3 added the rbac Issues related to Role Based Access Control label Apr 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug rbac Issues related to Role Based Access Control trusted-cluster
Projects
None yet
Development

No branches or pull requests

4 participants