Events Access Control

[klizhentas]

Feature Request

Update events system to support the following use-cases:

• Members of the teams should be able to see events from their own team, but not others (including session recordings and playbacks).

• Create a role for team auditors, who will be able to see the events from some teams, but not access the infrastructure.

• Provide efficient pagination so people can export the data (current API has hardcoded limit per range period that makes data export a problem) #5435

Backends

• For on-premises, customers are OK to use Elastic Search as a backend.
• We have to support existing backends, DynamoDB and local disk backend.

Namespaces

I would like to finish implementation of namespaces to fix this problem. Events, nodes and every single resource already support namespaces internally. The default namespace is used at all times at the moment.

Namespaces design should be similar to Kubernetes:

• Nodes, Kubernetes clusters, DBs and Apps could be placed into namespace.
• Default namespaces is used by default as today
• Users can select a namespace and tsh profile could be updated to select the namespace.
• Events and session recordings generated by users accessing the resources should be placed in the namespace
• Roles are updated to support access to namespaces:

kind: role
name: team-access
spec:
   allow:
      namespaces: ['{{traits.teams}}']

• CLI flags tsh ls --n default tsh set-context --set-namespace=default --set-cluster=root tctl get nodes -n default

• User interface. A new namespace selector should be present in the UI next to the cluster selector.

[russjones]

@klizhentas While namespaces exist, since they have been unused since inception, I don't know how much isolation they provide. They may be in a more unfinished state than we expect since their functionality has never been exercised.

The other thing is namespaces force the user to think about them, ideally we wouldn't do that to users.

We could add tags to events then in our resource definition we could use the where clause to specify that this user can fetch events but only events with tags matching some value that comes from claims. Admittedly this would work for ElasticSearch, probably not DynamoDB and disk.

[klizhentas]

Namespaces provide better concept for team isolation and security. Kubernetes is a great example. Once you place a resource in a namespace, it is really not visible by default and all actions on it require namespace to be defined. It is true that namespaces force people to think about them. However, imagine the most common use-case - a team gets a namespace in teleport. Most of the time that's what they will use and they won't need to think about the other namespaces.

TLDR: Kubernetes has proven that namespaces are a good idea for isolation purposes. Teleport on purpose uses similar concepts like labels, so bringing in namespaces is a good choice.

[klizhentas]

Here is a cheaper version of it:

• Have every event associated with a user record user and user's traits
• Have every node associated with a user record a node and node's traits

Support a role:

kind: role
version: v3
metadata:
  name: session-viewer
spec:

    # list of allow-rules. see below for more information.
    rules:
    - resources: [session]
      verbs: [list, read]
      where: 'contains(event.spec.user.labels, user.spec.traits["group"])'
   # allow to see events that are initiated by user's group
    - resources: [event]
      verbs: [list, read]
      where: 'contains(event.spec.user.labels, user.spec.traits["group"])'

By default do not allow users to view sessions other than started by themselves

[russjones]

@klizhentas

1. This would apply to session recordings, do we want to do any restrictions on joining a live session? It's a different resource ssh_session.

2. I don't think all events in the system are emitted with a user identity, if I recall correctly some are just cluster state change information. The only way to see those would be if you don't have a where clause specified which means wildcard right?

kind: role
version: v3
metadata:
  name: admin
spec:
    rules:
    - resources: [event]
      verbs: [list, read]

3. Do we still use GetSessionEvents and GetSessionChunk? I think those are the only ones that use the session resource. If those were only used pre-streaming, we can just use event.

[klizhentas]

@stevenGravy @russjones

MVP:

Have modes:

• Users can only view their only session recordings
• Users can't join other users sessions and view active sessions

Post MVP:

• Have mode when team members can view and join sessions based on the traits and labels

[klizhentas]

• See no problem in having post MVP complex scenario with filtering based on labels only work in AWS Athena / Loki scenario post parquet.

[russjones]

RFD for Events Access Control: https://github.com/gravitational/teleport/pull/8084

[russjones]

Remaining backend changes for active sessions @codingllama.

https://github.com/gravitational/teleport/pull/8588 https://github.com/gravitational/teleport/pull/8568

Remaining frontend changes for recorded and active sessions @atburke.

https://github.com/gravitational/webapps/issues/406

[codingllama]

Active sessions RFD merged as https://github.com/gravitational/teleport/pull/8962 - I'm trying out the server-side changes, they may need a couple tweaks.

[codingllama]

Active sessions implementation landed on master yesterday, RFDs are up-to-date, so all the backend work required here is done. I'm working on backporting changes to v8, but that should be simple (and doesn't block anyone).

@rudream, something I noticed in the Web UI is that when a user tries to join a forbidden active session (say, because of a new "where" condition), it errors saying "The session is no longer active" instead of giving an "access denied" error. Just giving you a heads up in case you want to tweak that.

[russjones]

I'm going to re-open this but remove it from the Queue. We implemented basic support for events access control (can see your own or all sessions) but we didn't implement team based access controls where all members of a particular team can see each other sessions.