Details of the ImplementationTLS cipher suites
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
Modifying the list of cipher suites is not supported. Changes made on CP VMs directly will work but will not be preserved during the upgrade (upgrade will overwrite these settings with configuration coming from the newer version).
FirewallControl-plane VMs are connected to two network interfaces, eth0 for management network (VC, ESX, NSX) and workload network (pods running in Kubernetes cluster), and incoming traffic is restricted independently for both those interfaces.
Open ports on the management networkOpen ports on the workload networkThere are no firewall rules in-place restricting outgoing traffic.
There are no APIs, or supported mechanism to edit
iptables configuration for Control Plane VMs but, of course, external firewall can be used to limit the connectivity.
SSH AccessSSH is enabled and can be used for troubleshooting/support. It is not recommended to use SSH to make configuration changes to the CP VMs since these changes will be lost during the cluster's upgrade and repair.
Disabling SSH on CP VMs will not affect the cluster’s operations (it will only affect troubleshooting/support). There is no API for managing SSH on CP VMs.
Root account can be used to login using SSH, and the password is stored encrypted in VCDB (it's encrypted using AES-256-GCM). Root password can be rotated on-demand using
vCenter REST API : com.vmware.vcenter.namespacemanagement.clusters.rotatepassword. There is no periodic password rotation in-place.
Root password is hashed in /etc/shadow using SHA-512
sshd uses 2048 bit RSA as server key with the following:
Secrets stored on CP VMsSecrets like private keys are stored encrypted at rest and only decrypted in memory. Encryption secret is stored in VCDB and delivered to Control-plane VMs when they boot up via a secure channel (guest operations).
Certificates
User-facing certificatesCertificates exposed to the users, i.e., apiserver load balancer certificate, also known as Virtual IP certificate, and the default ingress certificate, are initially signed by vCenter’s Certificate Authority (VMCA) and can be replaced after cluster enablement in vCenter UI by navigating to cluster configuration > Supervisor Cluster > Certificates. Certificate Signing Requests can be obtained there, and signed certificates can be uploaded there. WCP Service does not accept private keys there; only a certificate generated using CSR issued by WCP Service will be accepted there.
Cluster-internal certificatesAll communication within the Supervisor cluster is secured using TLS, and the identity of the parties is established with the root of trust that’s internal to the Kubernetes cluster. This ensures that services running in different Supervisor clusters on the same VC can’t communicate, limiting the damage that a single compromised cluster could cause.
There are no APIs to allow the rotation of the internal certificates. These certificates will be refreshed during every cluster upgrade.
Streaming logsControl-plane VMs follow VC configuration for streaming logs for auditing purposes. To control where logs from CP VMs are streamed, the user needs to modify the log streaming configuration for VCSA (that configuration is maintained by Appliance Management and can be configured in VAMI UI or using the
Appliance Management APIs ).
3rd party softwareInstallation of 3rd party software (like anti-virus software) is not recommended on CP VMs. Such software will be removed during the upgrade. It is impossible to foresee all the possible conflicts between such software and components running on CP VMs affecting the supportability of such an environment.