Note: This process does not apply if you are using a publicly-signed certificate. Using a publicly-signed certificate will simplify operations for the provider and the tenant. If you are a VMware Cloud Director tenant, check with your provider to determine if you need to apply any changes.
VMware Cloud Director Extension for VMware Tanzu Mission Control uses certificates to encrypt traffic to the Harbor repository and Tanzu Mission Control services. Self-signed certificates may be used when a publicly-signed certificate is not available.
Use a single self-signed certificate authority (CA) for Harbor and Tanzu Mission Control. CA certificates are generally valid for a longer period of time. They also allow you to trust all endpoints with a single step rather than repeating the process for each service. Configuring the cluster and kapp-controller to trust the CA will allow you to rotate Harbor certificates without having to repeat this process until the CA expires.$ openssl req -x509 -sha256 -days 1825 -newkey rsa:2048 \ -keyout $HOME/rootCA.key -out $HOME/rootCA.crt \ -nodes -extensions v3_ca \ -subj "/C=US/ST=CA/L=City Name/O=CompanyName/OU=OrgName/CN=Tanzu Mission Control Issuing CA"
On some platforms, you may get an error like Error Loading extension section v3_ca. This happens with the system default configuration does not support generating certificate authorities. The issue may be resolved by creating a custom configuration before running openssl.
$ cp /etc/ssl/openssl.cnf . $ cat <<EOF >> openssl.cnf [ v3_ca ] basicConstraints = critical,CA:TRUE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always EOF $ openssl req -x509 -sha256 -days 1825 -newkey rsa:2048 \ -keyout $HOME/rootCA.key -out $HOME/rootCA.crt \ -nodes -extensions v3_ca -config openssl.cnf \ -subj "/C=US/ST=CA/L=City Name/O=CompanyName/OU=OrgName/CN=Tanzu Mission Control Issuing CA"
Note: Updating the cluster definitions will execute a rolling-recreation of all nodes in the cluster. All pods will be restarted at least once as they are rescheduled from old worker nodes to new ones. This is a natural behavior for Kubernetes clusters. Applications with multiple nodes will see less interruption than applications with a single node.
The script may be run from any machine with network access to the VCD API. Be sure to have these utilities installed and in the user's PATH before running the script.export VCD_URL=https://vcd.example.com export VCD_USERNAME=system_local_user export VCD_PASSWORD= export VCD_API_TOKEN=
$ ./insert_cse_cluster_node_certificates.sh myorg tmc01 rootCA.crt rootCA2.crt --dry-run
$ kubectl get nodes NAME STATUS ROLES AGE VERSION tmc01-control-plane-node-pool-5sdmz Ready control-plane 42h v1.24.10+vmware.1 tmc01-control-plane-node-pool-dcjr9 Ready control-plane 43h v1.24.10+vmware.1 tmc01-control-plane-node-pool-gr4sm Ready control-plane 43h v1.24.10+vmware.1 tmc01-worker-node-pool-1-64cddcc746xwnznb-68gtm Ready <none> 42h v1.24.10+vmware.1 tmc01-worker-node-pool-1-64cddcc746xwnznb-6pd7k Ready <none> 43h v1.24.10+vmware.1 tmc01-worker-node-pool-1-64cddcc746xwnznb-7dtvq Ready <none> 42h v1.24.10+vmware.1
$ kubectl get kubeadmcontrolplanes,machinedeployments -A NAMESPACE NAME CLUSTER INITIALIZED API SERVER AVAILABLE REPLICAS READY UPDATED UNAVAILABLE AGE VERSION tmc01-ns kubeadmcontrolplane.controlplane.cluster.x-k8s.io/tmc01-control-plane-node-pool tmc01 true true 3 3 3 0 43h v1.24.10+vmware.1 NAMESPACE NAME CLUSTER REPLICAS READY UPDATED UNAVAILABLE PHASE AGE VERSION tmc01-ns machinedeployment.cluster.x-k8s.io/tmc01-worker-node-pool-1 tmc01 3 3 3 0 Running 43h v1.24.10+vmware.1
The kapp-controller is responsible for lifecycle management (LCM) of Tanzu packages on the cluster. Clusters running or being managed by TMC-SM will use Tanzu packages from the Harbor repository. Follow this process to ensure the packages can be retrieved.
Note: These commands use kubectl to modify the kapp-controller configuration. This requires network access to the Kubernetes API. The tenant may need to execute these commands if the cluster is connected to a private network and the provider does not have network access to it.
Note: An error like cat: rootCA.crt: No such file or directory means that the specified file could not be found. Check the path to the file and attempt to run the script again.
kubectl patch -n tkg-system configmap/kapp-controller-config \ -p "$( \ CURRENT_CACERTS=$(kubectl get -n tkg-system configmap/kapp-controller-config -o=jsonpath="{.data.caCerts}") \ NEW_CACERTS=$(echo "$CURRENT_CACERTS" && cat rootCA.crt) \ jq -c -n '{"data": {"caCerts": $ENV.NEW_CACERTS}}' \ )" kubectl -n tkg-system rollout restart deploy/kapp-controller
kubectl patch -n kapp-controller secret/kapp-controller-config \ -p "$( \ CURRENT_CACERTS=$(kubectl get -n kapp-controller secret/kapp-controller-config -o=jsonpath="{.data.caCerts}" | base64 -d) \ NEW_CACERTS=$(echo "$CURRENT_CACERTS" && cat ca-certificates.crt) \ jq -c -n '{"stringData": {"caCerts": $ENV.NEW_CACERTS}}' \ )" kubectl -n kapp-controller rollout restart deploy/kapp-controller
$ export KUBECONFIG=$PWD/kubeconfig-harbor.txt $ kubectl create secret tls -n cert-manager selfsigned-ca-pair \ --cert=$HOME/rootCA.crt --key=$HOME/rootCA.key $ cat <<EOF | kubectl apply -f - { "apiVersion": "cert-manager.io/v1", "kind": "ClusterIssuer", "metadata": { "name": "selfsigned-ca-clusterissuer" }, "spec": { "ca": { "secretName": "selfsigned-ca-pair" } } } EOF
$ cp $HOME/rootCA.crt /usr/local/share/ca-certificates/ $ sudo update-ca-certificates
$ cp $HOME/rootCA.crt /etc/pki/ca-trust/source/anchors/ $ sudo update-ca-trust
$ sudo tdnf install -y openssl-c_rehash $ sudo cp $HOME/rootCA.crt /etc/ssl/certs/rootCA.pem $ sudo rehash_ca_certificates.sh
--input-cert-provider=cluster-issuer --input-cert-cluster-issuer-name=selfsigned-ca-clusterissuer --input-harbor-ca-bundle-file=$HOME/rootCA.crt
$ cp $HOME/rootCA.crt /usr/local/share/ca-certificates/ $ sudo update-ca-certificatesFor Red Hat / CentOS
$ cp $HOME/rootCA.crt /etc/pki/ca-trust/source/anchors/ $ sudo update-ca-trustFor Photon
$ sudo tdnf install -y openssl-c_rehash $ sudo cp $HOME/rootCA.crt /etc/ssl/certs/rootCA.pem $ sudo rehash_ca_certificates.shAlternatively, you can use the SSL_CERT_DIR to define a user-managed location for trusted certificates.
$ mkdir $HOME/ssl-certs $ cp rootCA.crt $HOME/ssl-certs $ cp VCD.pem $HOME/ssl-certs $ export SSL_CERT_DIR=$HOME/ssl-certsYou can now proceed with cluster attachment and use of the tmc CLI.