Understanding TLS v1.2 Support on vSphere Kubernetes Service Workload Clusters using ClusterClass

Products

• VMware vSphere Kubernetes Service

Issue/Introduction

• There is an ask to enable TLS v1.2 support on workload clusters deployed via vSphere Kubernetes Service.
• Earlier it was achieved in TKGm clusters by including an additional parameter apiServerExtraArgs with the value tls-min-version: VersionTLS12 as mentioned in the following KB: Updating the API Server "tls-min-version" on a Running Workload Cluster
• Attempting to pass apiServerExtraArgs to a new ClusterClass object fails, as the specification does not support adding these manual Extra Args for TLS configuration. And following error is observed when modifying ClusterClass: 
  error when creating cluster.yaml admission webhook "capi.mutating.tanzukubernetescluster.run.tanzu.vmware.com" denied the request: Cluster and variable validation failed: spec.topology.variables[apiServerExtraArgs]: Invalid value: "{\"tls-min-version\":\"VersionTLS12\"}": variable is not defined

Environment

VMware vSphere Kubernetes Service

Resolution

No configuration changes or topology edits are required to support legacy workloads that rely on TLS v1.2. The VKS workload cluster already supports it natively.

The same can be verified by looking at KCP's yaml for the Guest Cluster under the apiServer configuration section:

• kubectl get kcp <KCP_Object_Name> -n <Namespace_Name> -o yaml: 
  
  spec:
    kubeadmConfigSpec:
      clusterConfiguration:
        apiServer:
          extraArgs:
  .
  .
  tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
            tls-min-version: VersionTLS12

Because these arguments are injected directly by the core TKG service controllers, attempting to append duplicate or conflicting arguments via the generic ClusterClass will result in validation errors. The applications will be able to securely communicate with the cluster using TLS v1.2 without any further action.