Configuration

The Controller provides administrators and authorized users mechanisms by which they can customize and manage the kind of access possible via Zero Trust Kubectl Access (ZTKA).

Org Wide Settings¶

KubeConfig Validity¶

A default validity time period is used for the downloadable Kubeconfig files. If required, Org Admins can customize the "Org Wide" validity of Kubeconfigs.

Once the Kubeconfig expires, the users will no longer be able to access the clusters remotely using KubeCTL and will be required to download a new Kubeconfig.

Require Active Session¶

For a stronger security posture, Org Admins can also optionally require a specific user to demonstrate that they can successfully authenticate to the web console with an active session before they are allowed to perform KubeCTL operations using the downloaded Kubeconfig file.

Read Only Users¶

Users that have Read Only RBAC privileges (roles) can only perform read only actions via KubeCTL and are not allowed access to Kube API verbs that result in changes/updates on the cluster.

Local vs SSO Users¶

Both locally managed users as well as SSO users have the ability to fully leverage the ZTKA capabilities in the Controller.

Per User Settings¶

Per user overrides for KubeCTL settings ca

KubeConfig Validity Overrides¶

Org Admins can specify per user overrides for Kubeconfig Validity. For example, the company policy may only allow a "1-day" KubeCTL access for contractors.

• As an Org Admin, click on System and navigate to Users
• Search for the user and click on Profile
• Update the Kubeconfig Validity and Save

In the example below, the user will be able to download Kubeconfigs that are only valid for 24-hours

Require Active Session¶

For a stronger security posture, Org Admins can also optionally require a specific user to demonstrate that they can successfully authenticate to the console with an active session before they are allowed to perform KubeCTL operations using the downloaded Kubeconfig file.

Revoke Kubeconfig¶

Sometimes, it may be necessary to revoke a specific user's Kubeconfig immediately. As the central access point for all clusters, ZTKA will immediately revoke this user's access via Kubeconfig. Note that it is not required to do this cluster by cluster.

• As an Org Admin, click on System and navigate to Users
• Search for the user and click on Revoke

Disable KubeCTL Access¶

Some organizations may want to limit authorized users to be able to perform KubeCTL against clusters using the "Browser based KubeCTL" shell in the console. i.e. that may wish to disable users from being able to use the KubeCTL CLI to access clusters remotely. To do this, admins need to set the Kubeconfig validity to "0" hours.

Self Revocation¶

Project admins are provided the means to revoke their Kubeconfigs. They may wish to perform this if they believe that their Kubeconfig file has been compromised (e.g lost/stolen laptop).

• Login into the Web Console
• Click on "My Tools"
• Click on "Revoke Kubeconfig"

Per Cluster Settings¶

For specific operating environments, Admins may wish to "disable" user access via the Zero Trust KubeCTL channel. Admins can enable these overrides at a cluster level.

• Navigate to the Project and to the Infrastructure menu
• Click on "settings" (gear icon on the far right) for a cluster
• Select "KubeCTL Settings"

Break Glass Process¶

Organizations can use the "per cluster" KubeCTL access control capability to implement a "Break Glass" process for their production environments. An audit trail is generated everytime a setting is modified giving security personnel a comprehensive view into when the break glass process started, ended and all the activity performed in between.

• START Break Glass
• KubeCTL access by operational personnel
• END Break Glass

KubeCTL CLI Access¶

Admins can enable/disable remote KubeCTL access to this cluster using a KubeCTL CLI

Browser based KubeCTL Access¶

Admins can enable/disable browser based KubeCTL access to this cluster