Skip to main content

How to update the Private Image Registry SSL certificate with user-provided CA and SSL certificates

 

Details
An administrator may want to replace the SSL certificate with their own certificate for the Private Image Registry in a vSphere 7 kubernetes cluster. The Registry Service in vSphere 7 with Kubernetes does not currently support SSL certificate replacements for private image registries. However, this can be done manually if you have the CA certificate and signed SSL certificates.
Solution
  1. Make a note of the IP of the Private Image Registry, which is available at cluster Configuration Namespaces Image Registry.
  2. Create a file named openssl.conf with content similar to the following:
[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
x509_extensions    = SAN
req_extensions     = SAN
[ req_distinguished_name ]
[ SAN ]
subjectAltName = @alt_names
[alt_names]
IP.1=<registry IP>


Note: Replace <registry IP> with the IP address of your
Private Image Registry noted in Step 1.
  1. Generate a CSR for the new Private Image Registry SSL certificate based on the IP noted in Step 1.
Example: openssl req -nodes -new -keyout registry.key -out registry.csr -subj "/C=US/ST=CA/L=Palo Alto/O=VMware/OU=REGISTRY/CN=<registry IP>" -config openssl.conf

Note: Replace <regisgtry IP> with the IP address of your Private Image Registry noted in Step 1. You can replace the  other subj values if you prefer. Files named registry.key and registry.csr will be created in the current directory.

  1. Generate the new Private Image Registry SSL certificate using the registry.csr CSR file created in Step 3. This will require submitting the CSR to a certificate signing authority (either internal or public).
  2. Obtain the CA certificate from the issuing authority.
  3. Encode the content of the registry.key file, the new Private Image Registry certificate and the CA certificate by issuing commands similar to the following:
cat registry.key | base64 | tr -d '\n'
cat registry.crt | base64 | tr -d '\n'
cat ca.crt | base64 | tr -d '\n'
  1. On the vCenter Server Appliance, issue the /usr/lib/vmware-wcp/decryptK8Pwd.py command to get the IP address and root password for one of the control plane nodes.
  2. SSH as the root user to the IP address obtained in Step 7, using the password also obtained in Step 7.
  3. Issue the following command to obtain the name of the Private Image Registry namespace:

kubectl get ns |grep vmware-system-registry-

Note: You will see output similar to the following:

vmware-system-registry-990781218            Active   43h

  1. Issue a command similar to the following to get the name of the Private Image Registry secret that needs to be edited:
kubectl -n <registry ns> get secrets |grep ssl

Note: Replace <registry ns> with the
Private Image Registry namespace noted in Step 9. You will see output similar to the following:

harbor-990781218-ssl                     Opaque                                3      43h
  1. Issue a command similar to the following to edit the Private Image Registry secret:
kubectl -n <registry ns> edit secret <registry secret>

Note: Replace <registry ns> with the 
Private Image Registry namespace noted in Step 9 and replace <registry secret> with the Private Image Registry secret noted in Step 10.

Note: The following values need to be replaced:
  • ca.crt value should be replaced with the encoded content of the CA certificate noted in Step 6.
  • tls.crt value should be replaced with the encoded content of the Private Image Registry certificate noted in Step 6.
  • tls.key value should be replaced with the encoded content of the registry.key file noted in Step 6.
Note: Type :wq when you are finished editing the Private Image Registry secret.
  1. Issue a command similar to the following to identify and restart the Private Image Registry nginx pod:

kubectl get pod -n <registry ns> | grep nginx

Note: Replace <registry ns> with the
Private Image Registry namespace noted in Step 9. You will see output similar to the following:

harbor-990781218-harbor-nginx-85657d5f98-dlvcv       1/1     Running   1          43h

kubectl -n <registry ns> delete pod <nginx pod>


Note: Replace <nginx pod> with the name of the nginx pod returned by the previous command.

  1. Issue a command similar to the following to identify the IP address of the node on which the Private Image Registry registry agent pod is running:
kubectl -n vmware-system-registry get pod -o wide

Note: You will see output similar to the following:

NAME                                                READY   STATUS    RESTARTS   AGE   IP            NODE                               NOMINATED NODE   READINESS GATES
vmware-registry-controller-manager-8fd79b8b-mxcsn   2/2     Running   26         43d   10.244.0.66   420ea13e894835e4dc382f7e7733b09a   <none>           <none>


Note: In the previous output, the IP address of the node where the
Private Image Registry registry agent pod is running is 10.244.0.66.
  1. From the SSH session to the control plane node that was initiated in Step 8, SSH to the IP address noted in Step 13 as the root user using the password noted in Step 7.
  2. Issue the following command to identify the container running the Private Image Registry registry agent:
docker ps | grep admin-agent

Note: You will see output similar to the following:

482346669ea3        937c13fe9a44          "/registry-agent -te…"   19 hours ago        Up 19 hours                             k8s_admin-agent_vmware-registry-controller-manager-8fd79b8b-mxcsn_vmware-system-registry_332b2b4d-8b1e-422b-8dac-bb4a3e8227bb_13

Note: In the previous output, 482346669ea3 is the container ID for the container running the
Private Image Registry registry agent.
  1. Issue a command similar to the following to remove the existing Private Image Registry certificate from the Private Image Registry registry agent container:
docker exec -it <registry-agent-container-id> rm /etc/registry-agent/certs/harbor-ca.crt

Note: Replace <registry-agent-container-id> with the container ID value noted in Step 15

Note: The new certificate should now be updated to the Private Image Registry in vSphere 7 kubernetes cluster and will be for any new requests.

Comments

Popular posts from this blog

Error [403] The maximum number of sessions has been exceeded in the H5 client during login or logout

  Symptoms In virgo log, you see messages similar to: [2020-05-19T07:25:45.285Z] [ERROR] http-nio-5090-exec-130 72026859 142953 501051 com.vmware.vise.security.spring.DefaultAuthenticationProvider logout failed for sessionId 142953, clientId 501051 java.lang.IllegalStateException: The specified cardinality of 1..1 for osgi:reference implementing com.vmware.vcenter.apigw.api.ApiGatewaySessionManager in bundle com.vmware.h5ngc requires that exactly one OSGI service satisfies the filtering criteria but no such service was found.         at com.vmware.o6jia.context.ExternalServiceTargetSource.getTarget(ExternalServiceTargetSource.java:99)         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:192)         at com.sun.proxy.$Proxy159.logout(Unknown Source)         at com.vmware.vise.security.spring.DefaultAuthenticationProvider.logoutInternal(DefaultAuthenticationProvider.java:548)         at c

Investigating virtual machine file locks on ESXi

      Details Adding an existing virtual machine disk (VMDK) to a virtual machine that is already powered on fails.                 Failed to add disk scsi0:1. Failed to power on scsi0:1   Powering on the virtual machine results in the power on task remaining at 95% indefinitely. Cannot power on the virtual machine after deploying it from a template. Powering on a virtual machine fails with an error: Unable to open Swap File Unable to access a file since it is locked Unable to access a file <filename> since it is locked Unable to access Virtual machine configuration In the /var/log/vmkernel log file, you see entries similar to: WARNING: World: VM xxxx: xxx: Failed to open swap file <path>: Lock was not free WARNING: World: VM xxxx: xxx: Failed to initialize swap file <path>   When opening a console to the virtual machine, you may receive the error: Error connecting to <path><virtual machin

"Performance data is currently not available for this entity" viewing the performance tab

  Symptoms While accessing the performance tab and navigating to Overview, you see: No data available   The data for Real time, but fails to retrieve it for past 1 day, week, month or year.  While selecting the advance parameter in performance tab, you see: Performance data is currently not available for this entity Cause This issue is caused by the vCenter Server database (Postgress) containing a stale/future time stamp reference for the ESXi host when the data was collected. For vCenter Servers using SQL, see  "Performance data is currently not available for this entity" error after updating rollup in vSphere Resolution Backup the vCenter database. For more info