-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Cloud users to set web_idle_timeout
and similar settings.
#18829
Comments
@vitorenesduarte Let's see if we can follow our dynamic configuration method for https://github.com/gravitational/teleport/blob/master/rfd/0016-dynamic-configuration.md If you have questions, feel free to ping me and I can step you through what we want. |
SummaryFor this we need:
DetailsCurrently the This seems to be due to this line: teleport/lib/config/configuration.go Line 661 in 8bdcd19
Teleport changes (part I)
This will allow the Cloud changesWhen a tenant is being provisioned, Cloud's tenant operator can create a This process would be similar to what we do currently for the Teleport changes (part II)The above changes should allow users to set a custom To prevent invalid changes, we can extend the existing cloud-only resource validation so only a subset of the fields can be modified: teleport/lib/modules/modules.go Lines 117 to 139 in 8bdcd19
|
There are fields in the cluster networking config that we MUST prevent cloud tenants from updating as changes to these fields could break networking and thus the customers access to their teleport cluster. These fields include
However we don't want to lock these to a specific value as we want the ability to update these on our end if necessary. There are additional fields that I think would be good for us to prevent customers from updating as they could increase load on our infrastructure and alter the way we expect agents to reconnect and heartbeat, but these fields don't have the same risk of a customer breaking their teleport cluster. These fields include:
As a general rule anything a customer could configure to alter the way teleport handles networking or agent behavior we should assess the impact that changing the value could have on a cloud tenant. |
Looks like this wasn't fully addressed because the config is still being reverted after pods restart. @lxea |
c-puf is looking to have a longer timeout for ssh nodes and desktop clients. |
This was implemented a while ago. |
Expected behavior:
It should be possible to update the
web_idle_timeout
option on a Cloud tenant.Current behavior:
If you run
tctl get cluster_networking_config
on a Cloud instance, it shows that the current settings are controlled via a config file. If you try to make any changes to the object viatctl create -f cluster_networking_config.yaml
, you get the following warning:If you supply both
-f
and--confirm
, it does make the change, but it only stays in effect until the pod is restarted.Additionally, it is possible to remove the
proxy_listener_mode: 1
bit, which is not ideal. Values that need to be a certain way in Cloud should be enforced to stay at that value.client_idle_timeout
andidle_timeout_message
are also useful options to allow users to control within thecluster_networking_config
resource.Bug details:
The text was updated successfully, but these errors were encountered: