TKG Service with Supervisor leverages vSphere security features and lets you provision workload clusters that are secure by default.
vSphere IaaS control plane is an add-on module to vSphere that is able to leverage the security features that are built into vCenter Server and ESXi. For more information, see the vSphere Security documentation.
Supervisor encrypts all secrets stored in the database (etcd). The secrets are encrypted via a local encryption key file, which is provided at boot by vCenter Server. The decryption key is stored in memory (tempfs) on Supervisor control plane nodes and on disk in encrypted form within the vCenter Server database. The key is available in clear text to the root users of each system.
The same encryption model applies to the data in the database (etcd) that is installed on each TKG cluster control plane. All etcd connections are authenticated with certificates that are generated at installation and rotated during upgrades. Manual rotation or updating of the certificates is currently not possible. Secrets held within the database of each workload cluster are stored in clear text.
A TKG cluster does not have infrastructure credentials. The credentials that are stored within a TKG cluster are only sufficient to access the vSphere Namespace where the TKG cluster has tenancy. As a result, there is no privilege escalation avenue for cluster operators or users.
The authentication token used to access a TKG cluster is scoped such that the token cannot be used to access the Supervisor or other TKG clusters. This prevents cluster operators, or individuals who might try to compromise a cluster, from using their root-level access to capture a vSphere administrator's token when they log in to a TKG cluster.
A TKG cluster is secure by default. Starting with Tanzu Kubernetes release v1.25, TKG clusters have the Pods Security Adminission controller (PSA) enabled by default. For Tanzu Kubernetes releases up to v1.24, restrictive Pod Security Policy (PSP) is available for any TKG cluster. If developers need to run privileged pods or root containers, at a minimum a cluster administrator must create a RoleBinding that grants user access to the default privileged PSP.