Document, fix and re-introduce where rules for access_requests and events

[klizhentas]

Feature Request

Teleport's RBAC rules' where filters let developers limit the scope the roles based on the user identity and resource tags.
From Gravity's documentation:

The role developers uses special property user.spec.traits that contains user OIDC claims or SAML attribute statements after users have successfully logged into Gravity Hub.

kind: role
version: v3
metadata:
  name: developers
spec:
  allow:
    logins:
    - developers
    namespaces:
    - default
    kubernetes_groups:
    - admin
    rules:
    - resources:
      - role
      verbs:
      - read
    - resources:
      - app
      verbs:
      - list
    - resources:
      - cluster
      verbs:
      - connect
      - read
      where: contains(user.spec.traits["roles"], resource.metadata.labels["team"])

We should document this feature and enable it for many Teleport's use cases:

Limiting the scope of approvals

#3559 and #4309

Allow user to approve access requests for their team except the ones created by themselves:

kind: role
version: v3
metadata:
  name: access_request_grantor
spec:

  allow:

    rules:
    - resources:
      - access_request
         verbs: [list, read, update]

   where: contains(user.spec.traits["roles"], resource.metadata.spec.annotations["team"])     

  # deny approval of roles created by yourself
  deny:
    rules:
    - resources:
      - access_request
         verbs: [update]

     where: equals(user.metadata.name, resource.metadata.spec.requested_by)     

Limiting the scope of the events

#924

Let users view their own events

kind: role
version: v3
metadata:
  name: access_request_grantor
spec:

  allow:

    rules:
    - resources:
      - event
         verbs: [list, read]

   where: contains(user.spec.traits["roles"], resource.metadata.spec.user)     

  # deny approval of roles created by yourself
  deny:
    rules:
    - resources:
      - access_request
         verbs: [list, read, update]

     where: equals(user.metadata.name, resource.metadata.spec.requested_by)     

[klizhentas]

@fspmarshall I think we might not need approve verb, because it is redundant with where scope and verb for access_request resource

[fspmarshall]

rfd/0014 will cover this usecase.