Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions docs/pages/access-controls/guides/moderated-sessions.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -148,6 +148,11 @@ spec:
modes: ['moderator', 'observer']
```

You should note that users who are assigned a role with a `join_sessions` allow policy are
implicitly allowed to list sessions. In most cases, `deny` statements take precedent.
However, if the `join_sessions` policy is set in a role, the `join_sessions` policy
overrides any explicit deny setting for listing sessions.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes it sound like they would be able to list all sessions. Is that actually the case?

My expectation is that a join_sessions policy should only override a deny rule for sessions that you are allowed to join.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jentfoo Can you clarify the intent here? Does join_sessions only allow you to join and list the sessions matching the allow rule?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes it sound like they would be able to list all sessions. Is that actually the case?

This is accurate, any user with join_sessions can list sessions, even if list sessions is explicitly denied. This appears to be a one off in our RBAC where deny wont take precedent (at least the only one I know of so far).

We discussed this on the issue here: https://github.com/gravitational/security-findings/issues/26

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but the role documented in the linked issue allows you to join all sessions for all roles.

I suspect if your join policy says "you can only join kube sessions for role foo" you might see different behavior.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure, I have not tested that case

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, let's hold this open until we understand the current behavior. I will try to get to testing it this afternoon.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zmb3 @jentfoo Any chance someone can take a stab at testing the behavior to clarify? I haven't been able to work out exactly what the environment and roles should look like to test the scenario.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I confirmed the behavior and my expectation in the first comment matches the current behavior.

My expectation is that a join_sessions policy should only override a deny rule for sessions that you are allowed to join.

This is what happens.

So a join_sessions policy doesn't override an explicit deny for all sessions, it only overrides the deny rule for sessions that you have permission to join (which makes sense).

The UI bug is still present, I had to verify this via API.


#### Joining sessions example

Here is an example of Jeff with role `prod-access` connecting to
Expand Down