RBAC model for Moderated Sessions needs more documentation

[milos-teleport]

Unsure if this should be a bug or a feature request.

Observations

The current RBAC for Moderated Session is underdocumented and implicitly allows certain access when customers don't necessarily expect that to be the case.

Implicit allow on ssh_session

A user can both list and join session, even though we don't provide an explicit list on ssh_sessions given this role:

version: v7
kind: role
metadata:
  name: moderator
spec:
  allow:
    join_sessions:
    - kinds:
      - ssh
      modes:
      - moderator
      name: ""
      roles:
      - 'access'`

A workaround is to add the following deny statement which can block us from viewing sessions, while still allowing us to join them if we know the UUID:

  deny:
    rules:
    - resources:
      - ssh_sessions
      verbs:
      - list

Unclear purpose of session_tracker

Another observation is that it is unclear what session_tracker does. A user can still list and join sessions given this added deny statement:

  deny:
    rules:
    - resources:
      - session_tracker
      verbs:
      - read
      - list

Edit:

list on session_tracker can be explicitly allowed in cases where no allow.session_join exists, so the users can list sessions without having access to them:

version: v7
kind: role
metadata:
  name: moderator
spec:
  allow:
    rules:
    - resources:
      - session_tracker
      verbs:
      - list

What would you like Teleport to do?

Document the desired behavior and usage patterns. Rework Moderated sessions RBAC if needed

What problem does this solve?

Avoids the situation where customers run into implicit allows they were not expecting

If a workaround exists, please include it.

To deny listing sessions while allowing joins, Teleport customers can currently add the following deny statement to their roles:

version: v7
kind: role
metadata:
  name: moderator
spec:
  allow:
    join_sessions:
    - kinds:
      - ssh
      modes:
      - moderator
      name: ""
      roles:
      - 'access'`
  deny:
    rules:
    - resources:
      - ssh_sessions
      verbs:
      - list

If users need only to list sessions without being able to join, this role would be appropriate:

version: v7
kind: role
metadata:
  name: moderator
spec:
  allow:
    rules:
    - resources:
      - session_tracker
      verbs:
      - list

[zmb3]

We already have #18446 tracking a revamp to moderated sessions docs, FYI.

This is working as designed though. If you have permission to join sessions then you will see them listed in the UI. (This is really no different than seeing SSH servers or kube clusters showing up in the UI if you have permission to access them).

Teleport does not have any sort of provisions for allowing a user join a session while also hiding its existence from the user.

[vasiliyplotnikov26]

Hey

This is working as designed though

Ok, thank you for confirming this.

If you have permission to join sessions then you will see them listed in the UI.

This makes total sense. I think it might be worth mentioning in the doc that join_sessions grants a list on sessions. It isn't intuitive because there is also the session_tracker resource

Another confusing thing is that if, for any reason, a user ends up with permissions that cloud be described the role below, a user can still list sessions despite an explicit deny, which should take precedence

version: v7
kind: role
metadata:
  name: moderator
spec:
  allow:
    join_sessions:
    - kinds:
      - ssh
      modes:
      - moderator
      name: ""
      roles:
      - 'access'
  deny:
    rules:
    - resources:
      - session_tracker
      verbs:
      - list

The statement below will deny listing sessions, but according to the Teleport Access Controls Reference, ssh_session allows viewing the active sessions page. The page itself is accessible, but the sessions are unavailable

  deny:
    rules:
    - resources:
      - ssh_session
      verbs:
      - list

The role below hides the active sessions page

kind: role
metadata:
  name: test_role
spec:
  allow: {}
  deny:
    rules:
    - resources:
      - ssh_session
      verbs:
      - list

But the role below grants the access to the page

kind: role
metadata:
  name: test_role
  revision: 20cc7b96-86e0-4f62-9eb6-721646e9224f
spec:
  allow:
    join_sessions:
    - kinds:
      - ssh
      modes:
      - moderator
      name: ""
      roles:
      - access
  deny:
    rules:
    - resources:
      - ssh_session
      verbs:
      - list

This is just a bit confusing

[zmb3]

This makes total sense. I think it might be worth mentioning in the doc that join_sessions grants a list on sessions. It isn't intuitive because there is also the session_tracker resource

This is covered in the [docs](https://goteleport.com/docs/admin-guides/access- controls/guides/moderated-sessions/#configure-an-allow-policy), but I agree with you it is confusing. I'll try and clean up this page.