Product Security Requirements of Supervisor Control Plane VMs
search cancel

Product Security Requirements of Supervisor Control Plane VMs

book

Article ID: 328731

calendar_today

Updated On:

Products

VMware

Issue/Introduction

vSphere with Tanzu Control Plane VMs adhere to VMware's Product Security Requirements. If you are looking for more information on the Security control implemented in deploying the Control Plane VM's of Supervisor, this KB article aims to provide you with that. In this article, you will find the details of the following security implementation
1. TLS Cipher Suites
2. Firewall
    a. Open Ports on the Management network
    b. Open Ports on the Workload network
3. SSH Access
    a. Key Exchange Algorithms
    b. Host Key Algorithms
    c. Message Authentication Code Algortithms
4. Secrets Stored on Control Plane VMs
5. Certificates
6. Streaming Logs
 


Resolution

Details of the Implementation

TLS 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).

Firewall

Control-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 network

image.png

Open ports on the workload network

image.png

There 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 Access
SSH 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:
 
Key Exchange Algorithms:
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
diffie-hellman-group-exchange-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group14-sha256

Host Key Algorithms:
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-ed25519
rsa-sha2-512
rsa-sha2-256

Message Authentication Code Algorithms:
hmac-sha2-256
hmac-sha2-512
[email protected]
[email protected]

Secrets stored on CP VMs
Secrets 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 certificates

Certificates 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 certificates
All 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 logs
Control-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 software
Installation 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.