Configuration

The Controller provides mechanisms by which administrators can customize and manage access via Zero Trust Kubectl Access (ZTKA).

Org Wide Settings¶

General¶

Service Account lifetime¶

This can be used by the Org Admins to configure the "idle time" for the ephemeral service account beyond which it is automatically de-provisioned. By default, this is set to 480 minutes.

Org Wide Kubeconfig

View SA Lifetime¶

The user's service account lifetime is injected into the remote cluster when the user attempts to access it using Kubectl. Let us look at an example:

User "demos@rafay.co" attempts to access cluster and a service account called "demos-64rafay-46co" is created on the cluster "Just In Time (JIT)".

kubectl get sa -n rafay-system

You will see output similar to the following

NAME                 SECRETS   AGE
default              1         24d
demos-64rafay-46co   1         10s
system-sa            1         24d

This service account will be automatically removed from the cluster after the configured "idle lifetime". To view the

kubectl describe sa demos-64rafay-46co -n rafay-system

Here is an example of what you should see. Notice that there are two labels with "Unix epoch timestamps"

authz-expiry - When the service account will expire and will be automatically removed from the cluster
authz-refreshed - Representing idle timer for lack of user activity

Users can use an Epoch Converter Tool to view the data in "Human Readable" format. In the example below, the service account will be deleted from the cluster on "Tuesday, October 4, 2022 12:26:59 AM"

Name:                demos-64rafay-46co
Namespace:           rafay-system
Labels:              authz-expiry=1664843219
                     authz-refreshed=1664814419
                     rafay-permission=kubectl.fullaccess
                     rafay-relay=true
                     relay-user=demos-64rafay-46co
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   demos-64rafay-46co-token-cxddm
Tokens:              demos-64rafay-46co-token-cxddm
Events:              <none>
kubectl

CLI Access¶

KubeConfig Validity¶

A default validity time period is used for the downloadable Kubeconfig files. This can be used by the Org Admins to customize the "Org Wide" validity of Kubeconfigs.

Org Wide Kubeconfig

Once the Kubeconfig expires, users will no longer be able to access the clusters remotely using KubeCTL CLI 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.

Org Wide Kubeconfig

Important

This setting can be used in conjunction with an appropriate IDP configuration for the controller application to restrict users to performing kubectl operations using the downloaded kubeconfig only when users are on trusted networks.

Note

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

Per User Settings¶

Per user overrides for KubeCTL settings can be configured by Org Admins.

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

Per User Validity Overrides

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.

The following examples show how to set organization wide kubectl settings from the CLI.

rctl update kubesetting -h
update kubectl setting

Usage:
  rctl update kubesetting [flags]

Examples:

  rctl update kubesetting --disablecli
  rctl update kubesetting --disableweb
  rctl update kubesetting --enablekubeapiproxy
  rctl update kubesetting --enablesession
  rctl update kubesetting --enforceorgadminsecretaccess
  rctl update kubesetting --validityperiod <timeInHours>
  rctl update kubesetting --validityperiod <timeInHours> --disablecli --disableweb --enablekubeapiproxy --enablesession --enforceorgadminsecretaccess


Flags:
      --disablecli                    Disable Kubectl CLI Access (Terminal)
      --disableweb                    Disable Browser Kubectl Access
      --enablekubeapiproxy            Enable Kube API Proxies
      --enablesession                 Require console login before kubectl access
      --enforceorgadminsecretaccess   Allow only Organization Admin to access secret via Kubectl
  -h, --help                          help for kubesetting
      --validityperiod string         Set Kubeconfig's validity period (Hours)

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

Revoke Kubeconfig for User

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¶

Users 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"

Revoke Kubeconfig for Project Admins

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"

Per Cluster Enable/Disable

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 KubeCTL CLI

Browser based KubeCTL Access¶

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