Add clarity to `client_idle_timeout` documentation

pschisa commented 11 months ago

Applies To

https://goteleport.com/docs/reference/config/ https://goteleport.com/docs/access-controls/reference/

Details

We currently have two different descriptions for client_idle_timeout

role reference

    # client_idle_timeout determines if SSH sessions to cluster nodes are
    # forcefully terminated after no activity from a client (idle client).
    # it overrides the global cluster setting. examples: "30m", "1h" or "1h30m"
    client_idle_timeout: never

config reference

    # Determines if sessions to cluster resources are forcefully terminated after
    # no activity from a client (idle client).
    # Examples: "30m", "1h" or "1h30m"
    client_idle_timeout: never

This leads to confusion and does not answer some fundamental questions of the functionality

Is the functionality limited to only SSH sessions or all protocols?
What qualifies as a session?
What counts as a client?
Does this have an impact on web apps, ssh sessions in web, etc or is that only web_idle_timeout?

How will we know this is resolved?

Determine which protocols, which clients, and which scenarios client_idle_timeout is meant to be enforced and unify the descriptions to be the same with clearer intended behavior.

ravicious commented 10 months ago

FWIW, client_idle_timeout seems to work for db access as well. https://github.com/gravitational/teleport/issues/20557

pschisa commented 10 months ago

https://github.com/gravitational/teleport/issues/18496

mmcallister commented 1 week ago

This topic seems to come up a lot in Zendesk inquiries.

I've also seen this note repeated:

"When a user has multiple roles assigned that specify conflicting options the most secure or restrictive value will be used" Related feature req: https://github.com/gravitational/teleport/issues/42328

mmcallister commented 1 week ago

@ravicious @zmb3 This is what I've gathered for Paul's Qs above. Can you confirm/correct my understanding here? Thanks!

client_idle_timeout applies to all protocols, not just SSH, and governs any active session regardless of how it's initiated (through the tsh client or via the web)
A session refers to any active interaction between a user and a resource within the Teleport cluster, such as K8 sessions with kubectl, SSH, DB connections w/ MySQL etc
A client can be the tsh client, a web browser, or any third-party tool connecting through Teleport
The client_idle_timeout does impact web app sessions, but the web_idle_timeout is specifically for sessions in the Teleport Web UI (not individual SSH or web app sessions)

ravicious commented 1 week ago

I think that's correct, it seems like MonitorConn in lib/srv/monitor.go is the single central place that controls that.

I'm just not sure if it's supported for all protocols. Have you tried changing this setting on an actual cluster and checking if it works with dbs and k8s, just to confirm this? I can see MonitorConn being used in the code for SSH, databases and apps, but I don't see it being used for other protocols.

The client_idle_timeout does impact web app sessions (…)

But how does it impact web app sessions exactly? I think it'd be good to include that in the docs as well.

mmcallister commented 1 week ago

Thanks Rafał! Good call, I shouldn't say all protocols. I will give it a spin with k8s to confirm.

The client_idle_timeout does impact web app sessions (…) But how does it impact web app sessions exactly?

The client_idle_timeout seems to impact SSH sessions initiated from the web interface from my tests. I think that's about it for that part.

ravicious commented 6 days ago

The client_idle_timeout seems to impact SSH sessions initiated from the web interface from my tests. I think that's about it for that part.

Cool, that's important to clarify. Without it, I'd have assumed that client_idle_timeout has an impact on the length of a Web UI session itself.

gravitational / teleport