Cluster level setting for enabling/disabling recording proxy

[russjones]

We should be able to enable and disable #1327 at the cluster level.

The proxy will use it for two purposes. The first is determine when it gets a request will it be running in the normal mode or will it be recording and forwarding traffic. The second is if it is running in recording and forwarding mode, it will need to request a role with RW access to services.CertAuthority resources.

Teleport nodes also need access to this setting so they can stop shipping audit logs to the Auth Server to prevent double logging.

The default setting for this should be normal mode.

[kontsevoy]

Proposal

Important: read the comments. This proposal is obsolete.

We have discussed this idea before, but punted. Now would be a good time to re-approach this. The idea was called "Cluster Configuration via tctl"

Consider this YAML file:

# cluster-config.yaml
kind: clusterConfig
version: v1
spec:
   # session_recording possible options: "node" (default) "proxy" and "off"
   session_recording: "node"

This cannot be used with regular tctl rm/insert because it's a nameless singleton. It always exists, cannot really be deleted and cannot exist in 2 copies wtih different names, so re-using resource commands would be unnatural.

Instead, lets keep most of the resource file format (for example having a kind+version is very useful) but make a user-friendly CLI commands for applying config:

# print the cluster configuration into stdout
$ tctl get config
# apply the new cluster config
$ tctl create cluster-config.yaml
# reset configuration to defaults:
$ tctl rm config

Note: you don't have to specify "name" for the config resource because there's only one, and -f (force) becomes the default for tctl create. But if a user specifies a name, we shouldn't reject it, but we should ignore it. Basically the behavior of get/create/rm will be different for "config" resource kind. This is because a config is something which always exists and always there's only 1 instance.

I propose to have just one configuration setting (proxy) for now and NOT migrate anything from teleport.yaml.

Alternative Approach

Another approach is to have a separate config-get and config-set CLI commands. Curious to hear your thoughts on them vs re-using CRUD commands. (we've discussed this and decided against it)

[russjones]

I like the ability to easily change cluster level configuration. Right now to make cluster level changes you have the following options:

1. If you are not running your Auth Server in HA mode cause a short outage to change cluster level configuration (if you are not using the caching ability we have).
2. If you are running the Auth Server in HA mode, make sure you organize all of our configuration files correctly so after doing a rolling restart you end with the right configuration.

In addition, it would be nice to consolidate all cluster level configuration (name, static tokens, and auth preferences) so we can easily add to it and operate on it.

[kontsevoy]

Updated Proposal

We have decided that moving to a dynamic cluster config is better be done all-at-once, and it should include the ability to change things like static tokens and a cluster name.

For now, it's much better from user expectation's point of view to simply add a new setting to /etc/teleport.yaml

# fragment of /etc/teleport.yaml
auth_service:
   # session_recording possible options: "node" (default) "proxy" and "off"
   session_recording: "node"