diff --git a/content/rancher/v2.0-v2.4/en/installation/resources/update-rancher-cert/_index.md b/content/rancher/v2.0-v2.4/en/installation/resources/update-rancher-cert/_index.md index 6b2b4eaee09..2e77d4bf12d 100644 --- a/content/rancher/v2.0-v2.4/en/installation/resources/update-rancher-cert/_index.md +++ b/content/rancher/v2.0-v2.4/en/installation/resources/update-rancher-cert/_index.md @@ -148,18 +148,7 @@ https://gist.github.com/superseb/b14ed3b5535f621ad3d2aa6a4cd6443b # Updating from a Private CA Certificate to a Common Certificate ->It is possible to perform the opposite procedure as shown above: you may change from a private certificate to a common, or non-private, certificate. The steps involved are very similar to the above, with some exceptions. The changes to these steps are shown at the bottom of each step below as they apply. - -Follow these steps to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation]({{}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/) or to switch from the default self-signed certificate to a custom certificate. - -A summary of the steps is as follows: - -1. Create or update the `tls-rancher-ingress` Kubernetes secret resource with the new certificate and private key. -2. Create or update the `tls-ca` Kubernetes secret resource with the root CA certificate (only required when using a private CA). -3. Update the Rancher installation using the Helm CLI. -4. Reconfigure the Rancher agents to trust the new CA certificate. - -The details of these instructions are below. +>It is possible to perform the opposite procedure as shown above: you may change from a private certificate to a common, or non-private, certificate. The steps involved are very similar to the above, with some exceptions. ## 1. Create/update the certificate secret resource @@ -182,39 +171,22 @@ $ kubectl -n cattle-system create secret tls tls-rancher-ingress \ --dry-run --save-config -o yaml | kubectl apply -f - ``` ->**NOTE:** No changes in this step. +## 2. Delete the CA certificate secret resource -## 2. Create/update the CA certificate secret resource +You will delete the `tls-ca secret` in the `cattle-system` namespace as it is no longer needed. You may also optionally save a copy of the `tls-ca secret` if desired. -If the new certificate was signed by a private CA, you will need to copy the corresponding root CA certificate into a file named `cacerts.pem` and create or update the `tls-ca secret` in the `cattle-system` namespace. If the certificate was signed by an intermediate CA, then the `cacerts.pem` must contain both the intermediate and root CA certificates (in this order). - -To create the initial secret: +To save the existing secret: ``` -$ kubectl -n cattle-system create secret generic tls-ca \ - --from-file=cacerts.pem +kubectl -n cattle-system get secret tls-ca -o yaml > tls-ca.yaml ``` -To update an existing `tls-ca` secret: +To delete the existing `tls-ca` secret: ``` -$ kubectl -n cattle-system create secret generic tls-ca \ - --from-file=cacerts.pem \ - --dry-run --save-config -o yaml | kubectl apply -f - +kubectl -n cattle-system delete secret tls-ca ``` ->**CHANGE:** Delete the `tls-ca` secret as it is no longer needed. Note that you may optionally save a copy of the `tls-ca` secret if desired. -> -**To save:** - ``` - kubectl -n cattle-system get secret tls-ca -o yaml > tls-ca.yaml - ``` -> -**To delete:** - ``` - kubectl -n cattle-system delete secret tls-ca - ``` - ## 3. Reconfigure the Rancher deployment > Before proceeding, generate an API token in the Rancher UI (User > API & Keys) and save the Bearer Token which you might need in step 4. @@ -235,80 +207,24 @@ Also get the version string of the currently deployed Rancher chart: $ helm ls -A ``` -Upgrade the Helm application instance using the original configuration values and making sure to specify `ingress.tls.source=secret` as well as the current chart version to prevent an application upgrade. +Upgrade the Helm application instance using the original configuration values and making sure to specify the current chart version to prevent an application upgrade. -If the certificate was signed by a private CA, add the `set privateCA=true` argument as well. Also make sure to read the documentation describing the initial installation using custom certificates. +Also make sure to read the documentation describing the initial installation using custom certificates. ``` helm upgrade rancher rancher-stable/rancher \ --namespace cattle-system \ --version \ --set hostname=rancher.my.org \ - --set ingress.tls.source=secret \ --set ... ``` -When the upgrade is completed, navigate to `https:///v3/settings/cacerts` to verify that the value matches the CA certificate written in the `tls-ca` secret earlier. - ->**CHANGE:** On Rancher upgrade, the `privateCA` parameter must be either removed or set to `false` because the CA is valid: -> - ``` - set privateCA=false - ``` - -## 4. Reconfigure Rancher agents to trust the private CA - -This section covers three methods to reconfigure Rancher agents to trust the private CA. This step is required if either of the following is true: - -- Rancher was initially configured to use the Rancher self-signed certificate (`ingress.tls.source=rancher`) or with a Let's Encrypt issued certificate (`ingress.tls.source=letsEncrypt`) -- The root CA certificate for the new custom certificate has changed - -### Why is this step required? - -When Rancher is configured with a certificate signed by a private CA, the CA certificate chain is downloaded into Rancher agent containers. Agents compare the checksum of the downloaded certificate against the `CATTLE_CA_CHECKSUM` environment variable. This means that, when the private CA certificate is changed on Rancher server side, the environvment variable `CATTLE_CA_CHECKSUM` must be updated accordingly. - -### Which method should I choose? - -Method 1 is the easiest one but requires all clusters to be connected to Rancher after the certificates have been rotated. This is usually the case if the process is performed right after updating the Rancher deployment (Step 3). - -If the clusters have lost connection to Rancher but you have [Authorized Cluster Endpoints](https://rancher.com/docs/rancher/v2.0-v2.4/en/cluster-admin/cluster-access/ace/) enabled, then go with method 2. - -Method 3 can be used as a fallback if method 1 and 2 are unfeasible. - -### Method 1: Kubectl command - -For each cluster under Rancher management (including `local`) run the following command using the Kubeconfig file of the Rancher management cluster (RKE or K3S). +After upgrade is completed, the `privateCA` parameter must be either removed or set to `false` because the CA is valid: ``` -kubectl patch clusters -p '{"status":{"agentImage":"dummy"}}' --type merge +set privateCA=false ``` -This command will cause all Agent Kubernetes resources to be reconfigured with the checksum of the new certificate. +## 4. Reconfigure Rancher agents for the non-private/common certificate - -### Method 2: Manually update checksum - -Manually patch the agent Kubernetes resources by updating the `CATTLE_CA_CHECKSUM` environment variable to the value matching the checksum of the new CA certificate. Generate the new checksum value like so: - -``` -$ curl -k -s -fL /v3/settings/cacerts | jq -r .value > cacert.tmp -$ sha256sum cacert.tmp | awk '{print $1}' -``` - -Using a Kubeconfig for each downstream cluster update the environment variable for the two agent deployments. - -``` -$ kubectl edit -n cattle-system ds/cattle-node-agent -$ kubectl edit -n cattle-system deployment/cluster-agent -``` - -### Method 3: Recreate Rancher agents - -With this method you are recreating the Rancher agents by running a set of commands on a controlplane node of each downstream cluster. - -First, generate the agent definitions as described here: https://gist.github.com/superseb/076f20146e012f1d4e289f5bd1bd4971 - -Then, connect to a controlplane node of the downstream cluster via SSH, create a Kubeconfig and apply the definitions: -https://gist.github.com/superseb/b14ed3b5535f621ad3d2aa6a4cd6443b - ->**CHANGE:** `CATTLE_CA_CHECKSUM` environment variable on the downstream cluster agents should be removed or set to "" (an empty string). \ No newline at end of file +`CATTLE_CA_CHECKSUM` environment variable on the downstream cluster agents should be removed or set to "" (an empty string). \ No newline at end of file diff --git a/content/rancher/v2.5/en/installation/resources/update-rancher-cert/_index.md b/content/rancher/v2.5/en/installation/resources/update-rancher-cert/_index.md index f8ba73d1747..09485cf47dd 100644 --- a/content/rancher/v2.5/en/installation/resources/update-rancher-cert/_index.md +++ b/content/rancher/v2.5/en/installation/resources/update-rancher-cert/_index.md @@ -160,19 +160,7 @@ Fleet agents in Rancher managed clusters store kubeconfig that is used to connec # Updating from a Private CA Certificate to a Common Certificate ->It is possible to perform the opposite procedure as shown above: you may change from a private certificate to a common, or non-private, certificate. The steps involved are very similar to the above, with some exceptions. The changes to these steps are shown at the bottom of each step below as they apply. - -Follow these steps to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation]({{}}/rancher/v2.5/en/installation/install-rancher-on-k8s/) or to switch from the default self-signed certificate to a custom certificate. - -A summary of the steps is as follows: - -1. Create or update the `tls-rancher-ingress` Kubernetes secret resource with the new certificate and private key. -2. Create or update the `tls-ca` Kubernetes secret resource with the root CA certificate (only required when using a private CA). -3. Update the Rancher installation using the Helm CLI. -4. Reconfigure the Rancher agents to trust the new CA certificate. -5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher. - -The details of these instructions are below. +>It is possible to perform the opposite procedure as shown above: you may change from a private certificate to a common, or non-private, certificate. The steps involved are outlined below. ## 1. Create/update the certificate secret resource @@ -195,39 +183,22 @@ $ kubectl -n cattle-system create secret tls tls-rancher-ingress \ --dry-run --save-config -o yaml | kubectl apply -f - ``` ->**NOTE:** No changes in this step. +## 2. Delete the CA certificate secret resource -## 2. Create/update the CA certificate secret resource +You will delete the `tls-ca secret` in the `cattle-system` namespace as it is no longer needed. You may also optionally save a copy of the `tls-ca secret` if desired. -If the new certificate was signed by a private CA, you will need to copy the corresponding root CA certificate into a file named `cacerts.pem` and create or update the `tls-ca secret` in the `cattle-system` namespace. If the certificate was signed by an intermediate CA, then the `cacerts.pem` must contain both the intermediate and root CA certificates (in this order). - -To create the initial secret: +To save the existing secret: ``` -$ kubectl -n cattle-system create secret generic tls-ca \ - --from-file=cacerts.pem +kubectl -n cattle-system get secret tls-ca -o yaml > tls-ca.yaml ``` -To update an existing `tls-ca` secret: +To delete the existing `tls-ca` secret: ``` -$ kubectl -n cattle-system create secret generic tls-ca \ - --from-file=cacerts.pem \ - --dry-run --save-config -o yaml | kubectl apply -f - +kubectl -n cattle-system delete secret tls-ca ``` ->**CHANGE:** Delete the `tls-ca` secret as it is no longer needed. Note that you may optionally save a copy of the `tls-ca` secret if desired. -> -**To save:** - ``` - kubectl -n cattle-system get secret tls-ca -o yaml > tls-ca.yaml - ``` -> -**To delete:** - ``` - kubectl -n cattle-system delete secret tls-ca - ``` - ## 3. Reconfigure the Rancher deployment > Before proceeding, generate an API token in the Rancher UI (User > API & Keys) and save the Bearer Token which you might need in step 4. @@ -248,83 +219,27 @@ Also get the version string of the currently deployed Rancher chart: $ helm ls -A ``` -Upgrade the Helm application instance using the original configuration values and making sure to specify `ingress.tls.source=secret` as well as the current chart version to prevent an application upgrade. +Upgrade the Helm application instance using the original configuration values and making sure to specify the current chart version to prevent an application upgrade. -If the certificate was signed by a private CA, add the `set privateCA=true` argument as well. Also make sure to read the documentation describing the initial installation using custom certificates. +Also make sure to read the documentation describing the initial installation using custom certificates. ``` helm upgrade rancher rancher-stable/rancher \ --namespace cattle-system \ --version \ --set hostname=rancher.my.org \ - --set ingress.tls.source=secret \ --set ... ``` -When the upgrade is completed, navigate to `https:///v3/settings/cacerts` to verify that the value matches the CA certificate written in the `tls-ca` secret earlier. - ->**CHANGE:** On Rancher upgrade, the `privateCA` parameter must be either removed or set to `false` because the CA is valid: -> - ``` - set privateCA=false - ``` - -## 4. Reconfigure Rancher agents to trust the private CA - -This section covers three methods to reconfigure Rancher agents to trust the private CA. This step is required if either of the following is true: - -- Rancher was initially configured to use the Rancher self-signed certificate (`ingress.tls.source=rancher`) or with a Let's Encrypt issued certificate (`ingress.tls.source=letsEncrypt`) -- The root CA certificate for the new custom certificate has changed - -### Why is this step required? - -When Rancher is configured with a certificate signed by a private CA, the CA certificate chain is downloaded into Rancher agent containers. Agents compare the checksum of the downloaded certificate against the `CATTLE_CA_CHECKSUM` environment variable. This means that, when the private CA certificate is changed on Rancher server side, the environvment variable `CATTLE_CA_CHECKSUM` must be updated accordingly. - -### Which method should I choose? - -Method 1 is the easiest one but requires all clusters to be connected to Rancher after the certificates have been rotated. This is usually the case if the process is performed right after updating the Rancher deployment (Step 3). - -If the clusters have lost connection to Rancher but you have [Authorized Cluster Endpoints](https://rancher.com/docs/rancher/v2.5/en/cluster-admin/cluster-access/ace/) enabled, then go with method 2. - -Method 3 can be used as a fallback if method 1 and 2 are unfeasible. - -### Method 1: Kubectl command - -For each cluster under Rancher management (except the `local` Rancher management cluster) run the following command using the Kubeconfig file of the Rancher management cluster (RKE or K3S). +After upgrade is completed, the `privateCA` parameter must be either removed or set to `false` because the CA is valid: ``` -kubectl patch clusters.management.cattle.io -p '{"status":{"agentImage":"dummy"}}' --type merge +set privateCA=false ``` -This command will cause all Agent Kubernetes resources to be reconfigured with the checksum of the new certificate. +## 4. Reconfigure Rancher agents for the non-private/common certificate - -### Method 2: Manually update checksum - -Manually patch the agent Kubernetes resources by updating the `CATTLE_CA_CHECKSUM` environment variable to the value matching the checksum of the new CA certificate. Generate the new checksum value like so: - -``` -$ curl -k -s -fL /v3/settings/cacerts | jq -r .value > cacert.tmp -$ sha256sum cacert.tmp | awk '{print $1}' -``` - -Using a Kubeconfig for each downstream cluster update the environment variable for the two agent deployments. - -``` -$ kubectl edit -n cattle-system ds/cattle-node-agent -$ kubectl edit -n cattle-system deployment/cattle-cluster-agent -``` - -### Method 3: Recreate Rancher agents - -With this method you are recreating the Rancher agents by running a set of commands on a controlplane node of each downstream cluster. - -First, generate the agent definitions as described here: https://gist.github.com/superseb/076f20146e012f1d4e289f5bd1bd4971 - -Then, connect to a controlplane node of the downstream cluster via SSH, create a Kubeconfig and apply the definitions: -https://gist.github.com/superseb/b14ed3b5535f621ad3d2aa6a4cd6443b - ->**CHANGE:** `CATTLE_CA_CHECKSUM` environment variable on the downstream cluster agents should be removed or set to "" (an empty string). +`CATTLE_CA_CHECKSUM` environment variable on the downstream cluster agents should be removed or set to "" (an empty string). ## 5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher diff --git a/content/rancher/v2.6/en/installation/resources/update-rancher-cert/_index.md b/content/rancher/v2.6/en/installation/resources/update-rancher-cert/_index.md index 71834965eaa..c9bdf724e3a 100644 --- a/content/rancher/v2.6/en/installation/resources/update-rancher-cert/_index.md +++ b/content/rancher/v2.6/en/installation/resources/update-rancher-cert/_index.md @@ -157,19 +157,7 @@ Fleet agents in Rancher managed clusters store kubeconfig that is used to connec # Updating from a Private CA Certificate to a Common Certificate ->It is possible to perform the opposite procedure as shown above: you may change from a private certificate to a common, or non-private, certificate. The steps involved are very similar to the above, with some exceptions. The changes to these steps are shown at the bottom of each step below as they apply. - -Follow these steps to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation]({{}}/rancher/v2.6/en/installation/install-rancher-on-k8s/) or to switch from the default self-signed certificate to a custom certificate. - -A summary of the steps is as follows: - -1. Create or update the `tls-rancher-ingress` Kubernetes secret resource with the new certificate and private key. -2. Create or update the `tls-ca` Kubernetes secret resource with the root CA certificate (only required when using a private CA). -3. Update the Rancher installation using the Helm CLI. -4. Reconfigure the Rancher agents to trust the new CA certificate. -5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher. - -The details of these instructions are below. +>It is possible to perform the opposite procedure as shown above: you may change from a private certificate to a common, or non-private, certificate. The steps involved are outlined below. ## 1. Create/update the certificate secret resource @@ -192,39 +180,22 @@ $ kubectl -n cattle-system create secret tls tls-rancher-ingress \ --dry-run --save-config -o yaml | kubectl apply -f - ``` ->**NOTE:** No changes in this step. +## 2. Delete the CA certificate secret resource -## 2. Create/update the CA certificate secret resource +You will delete the `tls-ca secret` in the `cattle-system` namespace as it is no longer needed. You may also optionally save a copy of the `tls-ca secret` if desired. -If the new certificate was signed by a private CA, you will need to copy the corresponding root CA certificate into a file named `cacerts.pem` and create or update the `tls-ca secret` in the `cattle-system` namespace. If the certificate was signed by an intermediate CA, then the `cacerts.pem` must contain both the intermediate and root CA certificates (in this order). - -To create the initial secret: +To save the existing secret: ``` -$ kubectl -n cattle-system create secret generic tls-ca \ - --from-file=cacerts.pem +kubectl -n cattle-system get secret tls-ca -o yaml > tls-ca.yaml ``` -To update an existing `tls-ca` secret: +To delete the existing `tls-ca` secret: ``` -$ kubectl -n cattle-system create secret generic tls-ca \ - --from-file=cacerts.pem \ - --dry-run --save-config -o yaml | kubectl apply -f - +kubectl -n cattle-system delete secret tls-ca ``` ->**CHANGE:** Delete the `tls-ca` secret as it is no longer needed. Note that you may optionally save a copy of the `tls-ca` secret if desired. -> -**To save:** - ``` - kubectl -n cattle-system get secret tls-ca -o yaml > tls-ca.yaml - ``` -> -**To delete:** - ``` - kubectl -n cattle-system delete secret tls-ca - ``` - ## 3. Reconfigure the Rancher deployment > Before proceeding, generate an API token in the Rancher UI (User > API & Keys) and save the Bearer Token which you might need in step 4. @@ -245,83 +216,27 @@ Also get the version string of the currently deployed Rancher chart: $ helm ls -A ``` -Upgrade the Helm application instance using the original configuration values and making sure to specify `ingress.tls.source=secret` as well as the current chart version to prevent an application upgrade. +Upgrade the Helm application instance using the original configuration values and making sure to specify the current chart version to prevent an application upgrade. -If the certificate was signed by a private CA, add the `set privateCA=true` argument as well. Also make sure to read the documentation describing the initial installation using custom certificates. +Also make sure to read the documentation describing the initial installation using custom certificates. ``` helm upgrade rancher rancher-stable/rancher \ --namespace cattle-system \ --version \ --set hostname=rancher.my.org \ - --set ingress.tls.source=secret \ --set ... ``` -When the upgrade is completed, navigate to `https:///v3/settings/cacerts` to verify that the value matches the CA certificate written in the `tls-ca` secret earlier. - ->**CHANGE:** On Rancher upgrade, the `privateCA` parameter must be either removed or set to `false` because the CA is valid: -> - ``` - set privateCA=false - ``` - -## 4. Reconfigure Rancher agents to trust the private CA - -This section covers three methods to reconfigure Rancher agents to trust the private CA. This step is required if either of the following is true: - -- Rancher was initially configured to use the Rancher self-signed certificate (`ingress.tls.source=rancher`) or with a Let's Encrypt issued certificate (`ingress.tls.source=letsEncrypt`) -- The root CA certificate for the new custom certificate has changed - -### Why is this step required? - -When Rancher is configured with a certificate signed by a private CA, the CA certificate chain is downloaded into Rancher agent containers. Agents compare the checksum of the downloaded certificate against the `CATTLE_CA_CHECKSUM` environment variable. This means that, when the private CA certificate is changed on Rancher server side, the environvment variable `CATTLE_CA_CHECKSUM` must be updated accordingly. - -### Which method should I choose? - -Method 1 is the easiest one but requires all clusters to be connected to Rancher after the certificates have been rotated. This is usually the case if the process is performed right after updating the Rancher deployment (Step 3). - -If the clusters have lost connection to Rancher but you have [Authorized Cluster Endpoints](https://rancher.com/docs/rancher/v2.6/en/cluster-admin/cluster-access/ace/) enabled, then go with method 2. - -Method 3 can be used as a fallback if method 1 and 2 are unfeasible. - -### Method 1: Kubectl command - -For each cluster under Rancher management (except the `local` Rancher management cluster) run the following command using the Kubeconfig file of the Rancher management cluster (RKE or K3S). +After upgrade is completed, the `privateCA` parameter must be either removed or set to `false` because the CA is valid: ``` -kubectl patch clusters.management.cattle.io -p '{"status":{"agentImage":"dummy"}}' --type merge +set privateCA=false ``` -This command will cause all Agent Kubernetes resources to be reconfigured with the checksum of the new certificate. +## 4. Reconfigure Rancher agents for the non-private/common certificate - -### Method 2: Manually update checksum - -Manually patch the agent Kubernetes resources by updating the `CATTLE_CA_CHECKSUM` environment variable to the value matching the checksum of the new CA certificate. Generate the new checksum value like so: - -``` -$ curl -k -s -fL /v3/settings/cacerts | jq -r .value > cacert.tmp -$ sha256sum cacert.tmp | awk '{print $1}' -``` - -Using a Kubeconfig for each downstream cluster update the environment variable for the two agent deployments. - -``` -$ kubectl edit -n cattle-system ds/cattle-node-agent -$ kubectl edit -n cattle-system deployment/cattle-cluster-agent -``` - -### Method 3: Recreate Rancher agents - -With this method you are recreating the Rancher agents by running a set of commands on a controlplane node of each downstream cluster. - -First, generate the agent definitions as described here: https://gist.github.com/superseb/076f20146e012f1d4e289f5bd1bd4971 - -Then, connect to a controlplane node of the downstream cluster via SSH, create a Kubeconfig and apply the definitions: -https://gist.github.com/superseb/b14ed3b5535f621ad3d2aa6a4cd6443b - ->**CHANGE:** `CATTLE_CA_CHECKSUM` environment variable on the downstream cluster agents should be removed or set to "" (an empty string). +`CATTLE_CA_CHECKSUM` environment variable on the downstream cluster agents should be removed or set to "" (an empty string). ## 5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher