Skip to content

FAQ

VPNs and Proxies

Authorized end users do not require a VPN to securely access their clusters operating behind corporate firewalls using the Zero Trust KubeCTL feature.

However, if a VPN is configured or in use, please ensure that "*.user.kubeapi-proxy.rafay.dev" FQDN is whitelisted in the proxy configuration.

The Zero Trust KubeCTL uses mutual authentication to secure the connection from the end user to the KubeCTL access proxy in the controller. Man-in-the-middle proxies that terminate the connection will break the security model and users will be shown an error message by the KubeCTL CLI.

Unable to connect to the server: x509: certificate signed by unknown authority

Disabling Kubeconfig Download

Org Admins can optionally completely disable the use of downloaded Kubeconfigs in their Org by setting a validity of "0 hours".


User SA Provisioning

User specific Service Accounts (sa) are provisioned "Just in Time (JIT)" on managed clusters by the Controller when the user attempts to access the cluster via KubeCTL the first time. This is automatically de-provisioned from the remote clusters "8" hours after the SA is idle and not used. This is to ensure that there are no dangling credentials on managed clusters.

In the image below, you can see that the SA for the user was created on the cluster "Just In Time (JIT)" when the user tried accessing the cluster using the browser based KubeCTL virtual terminal in the Web Console.

SA Created JIT


First Access Latency

When users access a managed cluster via the Web Console based Zero Trust KubeCTL terminal, they may encounter a slight delay/latency (2-3 seconds) before they can use the virtual terminal. This is because the user's service account is being provisioned just in time (JIT) on the remote clusters.

In the image below, you can see that the first time user access to the cluster took a few seconds longer than subsequent access.

First Time Access