vSphere IaaS Control Plane Security

vSphere IaaS control plane leverages vSphere security features and provisions TKG 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.

The 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 the Supervisor nodes and on disk in encrypted form within vCenter Server database. The key is available in clear text to the root users of each system. Secrets held within the database of each workload cluster are stored in clear text. 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. The same encryption model applies to the data in the database (etcd) that is installed on the control plane for each TKG cluster.

In Supervisor, you can run confidential vSphere Pods on compatible systems. You can create confidential vSphere Pods by adding Secure Encrypted Virtualization-Encrypted State (SEV-ES) as a security enhancement. For more information, see Deploy a Confidential vSphere Pod in vSphere IaaS Control Plane Services and Workloads.

A TKG cluster is secure by default. Restrictive PodSecurityPolicy (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. For more information, see Using TKG Service with vSphere IaaS Control Plane.

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.