Idle timeout behavior.

[klizhentas]

Description

Many policies CJIS and PCI for example enforce 30 and 15 minutes idle connection termination as a requirement. Make sure that idle connection in teleport indeed terminates after 15 minutes of inactivity.

We have set the timeout, but we need to make sure it actually works.

Proposed solution

There is no single way that will work for everyone, after several conversations with customers here are the modes this ticket should enable:

• Terminate session after predefined max idle timeout has happened. Define idle timeout by setting period of inactivity (not client heartbeats)
• Do not terminate session after predefined max inactivity timeout has happened. This is required for some other important use cases who wish to issue very short lived certificate, but want to allow keeping session active.
• Force Terminate connection on the proxy when certificate has expired. This is required to implement temporary access pattern for some important use cases.
• Force terminate connection when local user has been deleted.
• Make the timeout duration configurable as well, as some customers indicated the desire to have this configurable.

[klizhentas]

talk to @kontsevoy and @klizhentas before working on it, each point comes from a real use-case requested by someone.

[kontsevoy]

Proposal

Lets add two settings to both /etc/teleport.yaml and the role definition:

auth_service:
   # Maximum time a connection is allowed to remain idle, i.e. without any input from the client. 
   # 15m (default). Can also be "off" i.e. boolean parsing also applies
   disconnect_client_idle:  15m
   # When enabled, a connection will be terminated when the client certificate expires. 
   # OFF by default.
   disconnect_expired_cert: off

And in the role...

kind: role
version: v3
metadata:
  name: intern
spec:
  options: 
     # these two settings override the global ones:
     disconnect_client_idle:  1m
     disconnect_expired_cert: on

Notes:

• As with all boolean options, 1 and 0 as well as true and false must also be supported.
• I have picked the defaults to correspond to existing behavior this way deploying a new version will not change the behavior.
• This proposal does not address "Force terminate connection when local user has been deleted." use case. Lets move that to a separate ticket, because we'll need tctl and web UI support for that.

[klizhentas]

what if we don't want to disconnect idle client behavior, should it be - disconnect_client_idle:off?

[klizhentas]

also, why not: disconnect: {client_idle: 15m, expired_cert: off}

[kontsevoy]

lets leave as-is as discussed.

[klizhentas]

See final result here:

Auth server now supports global
defaults for timeout behavior:

auth_service:
  # default value is 'never' - for backwards-compatibility reasons
  client_idle_timeout:  15m
  # default value is `no` for backwards compatibility reasons
  disconnect_expired_cert: no

New role options were introduced:

kind: role
version: v3
metadata:
  name: intern
  spec:
    options:
    # these two settings override the global ones:
    client_idle_timeout:  1m
    disconnect_expired_cert: yes

[klizhentas]

Global vs local options resolution:

Roles do not "relax" global default values when set. For example, in the following setup:

auth_service:
   client_idle_timeout: 15m

and user's role:

kind: role
version: v3
metadata:
  name: intern
  spec:
    options:
    client_idle_timeout:  20m

still, the most restrictive option will be used 15m, so if administrator set global idle timeout of 15m there is no way to override it in the system.

If there are two roles with two values available, the most restrictive option will be used as well,
so if role A has client_idle_timeout: 15m and role B has client_idle_timeout: 10m the resulting value will be 10m.

This means that default global values are permissive - for example default idle timeout is never in the cluster and disconnect_expired_cert: no.

[mind-drive]

where will I put this?

[mind-drive]

at server side or at client side?