如何为现有IBM Cloud Private 2.1.0.2集群配置SSL证书及回滚方案

Great question! I’ve helped several teams with exactly this scenario on ICP 2.1.0.2, so let’s walk through the best approach, rollback steps, and wildcard certificate compatibility clearly.

The goal here is to replace self-signed or outdated certs with trusted ones so end-users don’t need flags like --tls or --insecure-registry. We’ll tackle each component one by one.

Prerequisites #

First, get your certs in order:

• You’ll need a valid SSL certificate (.crt), private key (.key), and any intermediate CA certs (merge intermediates into the main .crt by appending their content to the end of the file).
• Ensure the certificate’s Common Name (CN) or Subject Alternative Names (SANs) cover all relevant domains:
  • Your registry domain (e.g., registry.your-cluster-domain.com)
  • ICP Management Console domain (e.g., icp-console.your-cluster-domain.com)
  • Optional: Tiller’s service domain (tiller-deploy.kube-system.svc.cluster.local) if you want to use the wildcard cert for Tiller too.

1. Update Docker Registry SSL Certificate #

ICP’s registry uses a Kubernetes secret for TLS. Here’s how to update it:

1. Back up the existing secret (critical for rollback):

   kubectl get secret registry-tls -n kube-system -o yaml > original-registry-tls.yaml
   

2. Replace the secret with your new cert/key:

   kubectl create secret tls registry-tls --cert=/path/to/your/wildcard.crt --key=/path/to/your/wildcard.key -n kube-system --dry-run -o yaml | kubectl replace -f -
   

3. Restart the registry pod to apply the new cert:

   kubectl delete pod -l app=registry -n kube-system
   

4. Verify: Have an end-user test pulling an image without --insecure-registry:

   docker pull registry.your-cluster-domain.com/your-image:tag
   

2. Update ICP Management Console UI SSL Certificate #

The console uses the nginx-ingress controller, which relies on another TLS secret:

1. Back up the existing console secret:

   kubectl get secret icp-console-tls -n kube-system -o yaml > original-icp-console-tls.yaml
   

2. Replace the secret:

   kubectl create secret tls icp-console-tls --cert=/path/to/your/wildcard.crt --key=/path/to/your/wildcard.key -n kube-system --dry-run -o yaml | kubectl replace -f -
   

3. Restart nginx-ingress pods:

   kubectl delete pod -l app=nginx-ingress -n kube-system
   

4. Verify: Access https://icp-console.your-cluster-domain.com in a browser—no "untrusted" warnings should appear.

3. Update Tiller SSL Certificate #

Tiller (Helm’s server component) uses TLS to communicate with Helm clients. To avoid users needing --tls on every command:

1. Decide on cert usage:
   • If your wildcard cert includes tiller-deploy.kube-system.svc.cluster.local as a SAN, you can use it. Otherwise, use the cluster’s internal CA (simpler for internal-only Tiller access).
2. Back up the existing Tiller secret:

   kubectl get secret tiller-secret -n kube-system -o yaml > original-tiller-secret.yaml
   

3. Replace the secret with your new cert/key:

   kubectl create secret tls tiller-secret --cert=/path/to/tiller.crt --key=/path/to/tiller.key -n kube-system --dry-run -o yaml | kubectl replace -f -
   

4. Update Tiller deployment to use the new cert:
   Edit the deployment to ensure it references the secret:

   kubectl edit deployment tiller-deploy -n kube-system
   

   Confirm these args exist in spec.template.spec.containers[0].args:

   --tls-cert-file=/etc/tiller-certs/tls.crt
   --tls-private-key-file=/etc/tiller-certs/tls.key
   

   And that the volume mount for tiller-secret is present.
5. Restart Tiller:

   kubectl delete pod -l app=tiller -n kube-system
   

6. Configure Helm clients:
   Distribute the Tiller cert and CA cert to end-users, then have them initialize Helm with TLS enabled by default:

   helm init --client-only --tls --tls-ca-cert=~/.helm/ca.pem --tls-cert=~/.helm/cert.pem --tls-key=~/.helm/key.pem
   

   Now users can run helm commands without adding --tls each time.

Absolutely—this is actually the preferred approach for external-facing components! Just make sure:

• The wildcard covers your registry and console domains (e.g., *.your-cluster-domain.com).
• If you want to use it for Tiller, add tiller-deploy.kube-system.svc.cluster.local as a SAN in the cert (most wildcard certs don’t include internal cluster domains by default, so you may need to request an update to your cert).
• For internal Tiller traffic, using the cluster’s built-in CA is often simpler since it’s trusted by all cluster nodes and clients without extra setup.

Always back up secrets before making changes—here’s how to revert:

Docker Registry Rollback #

1. Restore the original secret:

   kubectl apply -f original-registry-tls.yaml
   

2. Restart the registry pod:

   kubectl delete pod -l app=registry -n kube-system
   

ICP Console Rollback #

1. Restore the original console secret:

   kubectl apply -f original-icp-console-tls.yaml
   

2. Restart nginx-ingress pods:

   kubectl delete pod -l app=nginx-ingress -n kube-system
   

Tiller Rollback #

1. Restore the original Tiller secret:

   kubectl apply -f original-tiller-secret.yaml
   

2. Restart Tiller:

   kubectl delete pod -l app=tiller -n kube-system
   

3. Have users revert their Helm client configuration to use the original certificates.

内容的提问来源于stack exchange，提问作者Aaron Cohen