tsh kube login client_idle_timeout Not Functioning as Expected

[pnrao1983]

Expected behavior: The client_idle_timeout=30s configuration works as expected for SSH and database (DB) resources, disconnecting clients after the specified idle time. However, this timeout does not work with Kubernetes (kube) resources when using.   Current behavior:  SSH, DB, Desktop, and App resources are getting disconnected after the 30s idle timeout but not with kube sessions: Observed that the session remains active beyond the 30-second idle timeout.

pnrao@pnrao ~ % k get po -A
NAMESPACE     NAME                                      READY   STATUS    RESTARTS      AGE
kube-system   coredns-7db6d8ff4d-bw446                  1/1     Running   0             59d
kube-system   etcd-minikube                             1/1     Running   0             59d
pnrao@pnrao ~ % date
Tue Sep  3 10:11:06 EDT 2024
pnrao@pnrao ~ % date
Tue Sep  3 10:12:03 EDT 2024
pnrao@pnrao ~ % k get po -A
NAMESPACE     NAME                                      READY   STATUS    RESTARTS      AGE
kube-system   coredns-7db6d8ff4d-bw446                  1/1     Running   0             59d
kube-system   etcd-minikube                             1/1     Running   0             59d
pnrao@pnrao ~ %
pnrao@pnrao ~ % kubectl exec -it my-pod -- /bin/bash 

root@my-pod:/# date
Thu Sep  5 15:21:54 UTC 2024
root@my-pod:/# date
Thu Sep  5 15:22:44 UTC 2024
root@my-pod:/# date
Thu Sep  5 15:22:47 UTC 2024
root@my-pod:/# date
Thu Sep  5 15:23:52 UTC 2024

Additional Context: Testing with kubectl exec confirms that the timeout does not apply to Kube resources.   Here is the output for SSH session which work as expected:

root@ip-10-0-139-134 ~]# date
Tue Sep  3 02:13:37 PM UTC 2024
[root@ip-10-0-139-134 ~]# uptime
 14:13:39 up 83 days, 19:16,  3 users,  load average: 0.00, 0.00, 0.00
[root@ip-10-0-139-134 ~]# Client exceeded idle timeout of 30sERROR: wait: remote command exited without exit status or exit signal

The timeout does work correctly for database connections, as shown by the following: sql

mysql> SELECT CURDATE();
ERROR 2013 (HY000): Lost connection to MySQL server during query
The connection was lost due to inactivity, but it reconnected in the same window.

  Bug details:

• Teleport version    Tested in both Self Hosted & SaaS v16.x version
• Recreation steps Here is the role that I have used: I have attached below rule to admin user and logged in:

  kind: role
  metadata:
    name: kube-access
    revision: 077aa69f-b00c-47f0-b776-3ecb8484aaaf
  spec:
    allow:
      kubernetes_groups:
      - system:masters
      kubernetes_labels:
        '*': '*'
      kubernetes_resources:
      - kind: pod
        name: '*'
        namespace: '*'
        verbs:
        - '*'
    deny: {}
    options:
      cert_format: standard
      client_idle_timeout: 30s
      create_db_user: false
      create_desktop_user: false
  version: v6
   

• Debug logs NA     References: Issue #18496: Discussion on the client_idle_timeout not applying to kube. Issue #20557: Related to the client_idle_timeout_message in database access. Issue #32855: Clarification needed in client_idle_timeout documentation. Request: Please investigate why client_idle_timeout is not being enforced for kube resources and provide a fix or guidance on how to apply the timeout consistently across all resource types.

[zmb3]

Thank you @pnrao1983 for linking to the other relevant discussions!

[tigrato]

Kubernetes has a special behavior by using SPDY PING frames behind the scenes as a keep-alive mechanism. For connection monitoring, this activity ensures the connection remains active and is never terminated.

The PING frames are sent every 10s, so the connection is marked as active and never terminated.