Closed deusxanima closed 2 years ago
Responding to @russjones comments from weekly prod sync: both customer and my tests were done on self-hosted clusters. No DynamoDB throttling observed in either case (in my cluster specifically I ran test against a single node with only 1 user, myself, and no other traffic, with 20 read/writes provisioned in Dynamo). This is the RBAC role I tested with:
kind: role
metadata:
labels:
description: this is a test
name: tmp
spec:
allow:
app_labels:
'*': '*'
cluster_labels:
'*': '*'
db_labels:
'*': '*'
db_names:
- '*'
db_users:
- '*'
kubernetes_groups:
- read
- '{{interal.kubernetes_groups}}'
kubernetes_labels:
'*': '*'
logins:
- '{{internal.logins}}'
- ubuntu
node_labels:
env: db
rules:
- resources:
- access_request
verbs:
- list
- read
- update
- delete
- create
- resources:
- applications
verbs:
- list
- read
- update
- delete
- resources:
- role
verbs:
- list
- create
- read
- update
- delete
- resources:
- auth_connector
verbs:
- list
- create
- read
- update
- delete
- resources:
- session
verbs:
- list
- read
where: contains(session.participants, user.metadata.name)
- resources:
- trusted_cluster
verbs:
- list
- create
- read
- update
- delete
- resources:
- event
verbs:
- list
- read
- resources:
- user
verbs:
- list
- create
- read
- update
- delete
- resources:
- token
verbs:
- list
- create
- read
- update
- delete
- resources:
- remote_cluster
verbs:
- list
- create
- read
- update
- delete
- resources:
- node
verbs:
- list
- create
- read
- update
- delete
- resources:
- kube_service
verbs:
- delete
windows_desktop_labels:
'*': '*'
windows_desktop_logins:
- Administrator
- '{{internal.windows_logins}}'
deny: {}
options:
cert_format: standard
client_idle_timeout: 1h0m0s
desktop_clipboard: true
enhanced_recording:
- command
- network
forward_agent: true
max_session_ttl: 8h0m0s
port_forwarding: true
record_session:
desktop: true
version: v5
I'll gather the role file from customer environment as well. Is there any additional info that would be helpful in this instance?
Customer role:
kind: role
metadata:
name: teleport-view
spec:
allow:
rules:
- resources:
- access_request
- event
- role
- user
verbs:
- list
- read
- resources:
- session
verbs:
- list
- resources:
- session
verbs:
- read
where: contains(session.participants, user.metadata.name)
deny: {}
options:
max_session_ttl: 12h0m0s
version: v4
Customer confirmed that removing the where
conditional clears the issue. Same behavior observed in my cluster.
@Aharic this should be fixed now, can you confirm whether there is still an issue?
Confirmed in my env. Closing out.
Expected behavior: Using RBAC for sessions should not cause Session Recordings page to display an endless loading spinner or take 30-60 seconds to pull up a session recording on an otherwise low-traffic cluster.
Current behavior: If a role is configured with RBAC for sessions, navigating to or refreshing Session Recordings page at times causes the page to display an endless loading spinner. This behavior is observed even with a single user/single recording cluster where Session Recording page may take up to 30-60 seconds to pull up the session recording. DynamoDB table limits are far above the read/write load observed during this time. Logs on the auth/proxy server also seem to lag at this time and are not updated until the session page is fully refreshed.
Bug details:
Recreation steps
Configure a role w/ RBAC for Sessions for an OIDC/SAML user:
echo test
)gz#5050