mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-04-27 16:55:02 +00:00
Update CA steps and adjust wording
This commit is contained in:
dkeightley
+124
-142
@@ -4,259 +4,241 @@ title: Updating the Rancher Certificate
|
||||
|
||||
## Updating a Private CA Certificate
|
||||
|
||||
Follow these steps to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md) or to switch from the default self-signed certificate to a custom certificate.
|
||||
Follow these steps to rotate an SSL certificate and private CA used by Rancher [installed on a Kubernetes cluster](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md), or migrate to an SSL certificate signed by a private CA.
|
||||
|
||||
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.
|
||||
1. Create or update the `tls-rancher-ingress` Kubernetes secret object with the new certificate and private key.
|
||||
1. Create or update the `tls-ca` Kubernetes secret object with the root CA certificate (only required when using a private CA).
|
||||
1. Update the Rancher installation using the Helm CLI.
|
||||
1. Reconfigure the Rancher agents to trust the new CA certificate.
|
||||
1. Select Force Update of Fleet clusters to connect fleet-agent to Rancher.
|
||||
|
||||
The details of these instructions are below.
|
||||
|
||||
### 1. Create/update the certificate secret resource
|
||||
### 1. Create/update the certificate secret object
|
||||
|
||||
First, concatenate the server certificate followed by any intermediate certificate(s) to a file named `tls.crt` and provide the corresponding certificate key in a file named `tls.key`.
|
||||
|
||||
If you are switching the install from using the Rancher self-signed certificate or Let’s Encrypt issued certificates, use the following command to create the `tls-rancher-ingress` secret resource in your Rancher HA cluster:
|
||||
Use the following command to create the `tls-rancher-ingress` secret object in the Rancher (local) management cluster:
|
||||
|
||||
```
|
||||
$ kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
```bash
|
||||
kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
--cert=tls.crt \
|
||||
--key=tls.key
|
||||
```
|
||||
|
||||
Alternatively, to update an existing certificate secret:
|
||||
Alternatively, to update an existing `tls-rancher-ingress` secret:
|
||||
|
||||
```
|
||||
$ kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
```bash
|
||||
kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
--cert=tls.crt \
|
||||
--key=tls.key \
|
||||
--dry-run --save-config -o yaml | kubectl apply -f -
|
||||
```
|
||||
|
||||
### 2. Create/update the CA certificate secret resource
|
||||
### 2. Create/update the CA certificate secret object
|
||||
|
||||
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).
|
||||
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 create the initial `tls-ca` secret:
|
||||
|
||||
```
|
||||
$ kubectl -n cattle-system create secret generic tls-ca \
|
||||
```bash
|
||||
kubectl -n cattle-system create secret generic tls-ca \
|
||||
--from-file=cacerts.pem
|
||||
```
|
||||
|
||||
To update an existing `tls-ca` secret:
|
||||
|
||||
```
|
||||
$ kubectl -n cattle-system create secret generic tls-ca \
|
||||
```bash
|
||||
kubectl -n cattle-system create secret generic tls-ca \
|
||||
--from-file=cacerts.pem \
|
||||
--dry-run --save-config -o yaml | kubectl apply -f -
|
||||
```
|
||||
|
||||
### 3. Reconfigure the Rancher deployment
|
||||
|
||||
:::note
|
||||
This step is required if the certificate source is changing. If Rancher was previously configured to use the default self-signed certificate (`ingress.tls.source=rancher`) or Let's Encrypt (`ingress.tls.source=letsEncrypt`), and is now using a certificate signed by a private CA (`ingress.tls.source=secret`).
|
||||
|
||||
Before proceeding, generate an API token in the Rancher UI (<b>User > API & Keys</b>) and save the Bearer Token which you might need in step 4.
|
||||
The below steps update the Helm values for the Rancher chart, so the Rancher pods and ingress are reconfigured to use the new private CA certificate created in Step 1 & 2.
|
||||
|
||||
:::
|
||||
1. Adjust the values that were used during initial installation, store the current values with:
|
||||
```bash
|
||||
helm get values rancher -n cattle-system -o yaml > values.yaml
|
||||
```
|
||||
1. Retrieve the version string of the currently deployed Rancher chart to use below:
|
||||
```bash
|
||||
helm ls -n cattle-system
|
||||
```
|
||||
1. Update the current Helm values in the `values.yaml` file to contain:
|
||||
```yaml
|
||||
ingress:
|
||||
tls:
|
||||
source: secret
|
||||
privateCA: true
|
||||
```
|
||||
:::note Important:
|
||||
As the certificate is signed by a private CA, it is important to ensure [`privateCA: true`](https://docs.ranchermanager.rancher.io/getting-started/installation-and-upgrade/installation-references/helm-chart-options#common-options) is set in the `values.yaml` file.
|
||||
:::
|
||||
1. Upgrade the Helm application instance using the `values.yaml` file and the current chart version. The version must match to prevent an upgrade of Rancher.
|
||||
```bash
|
||||
helm upgrade rancher rancher-stable/rancher \
|
||||
--namespace cattle-system \
|
||||
-f values.yaml \
|
||||
--version <DEPLOYED_RANCHER_VERSION>
|
||||
```
|
||||
|
||||
This step is required if Rancher was initially installed with self-signed certificates (`ingress.tls.source=rancher`) or with a Let's Encrypt issued certificate (`ingress.tls.source=letsEncrypt`).
|
||||
|
||||
It ensures that the Rancher pods and ingress resources are reconfigured to use the new server and optional CA certificate.
|
||||
|
||||
To update the Helm deployment you will need to use the same (`--set`) options that were used during initial installation. Check with:
|
||||
|
||||
```
|
||||
$ helm get values rancher -n cattle-system
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
```
|
||||
helm upgrade rancher rancher-stable/rancher \
|
||||
--namespace cattle-system \
|
||||
--version <DEPLOYED_CHART_VERSION> \
|
||||
--set hostname=rancher.my.org \
|
||||
--set ingress.tls.source=secret \
|
||||
--set ...
|
||||
```
|
||||
|
||||
When the upgrade is completed, navigate to `https://<Rancher_SERVER>/v3/settings/cacerts` to verify that the value matches the CA certificate written in the `tls-ca` secret earlier.
|
||||
When the change is completed, navigate to `https://<RANCHER_SERVER_URL>/v3/settings/cacerts` to verify that the value matches the CA certificate written in the `tls-ca` secret earlier. The CA `cacerts` value may not update until all Rancher pods start.
|
||||
|
||||
### 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
|
||||
- Rancher was previously 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 certificate was signed by a different private CA
|
||||
|
||||
#### 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.
|
||||
When Rancher is configured with a certificate signed by a private CA, the CA certificate chain is trusted by 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 used by Rancher has changed, 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).
|
||||
Method 1 is the easiest, 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.
|
||||
If the clusters have lost connection to Rancher but [Authorized Cluster Endpoint](https://docs.ranchermanager.rancher.io/how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint) (ACE) is enabled on all clusters, then go with method 2.
|
||||
|
||||
Method 3 can be used as a fallback if method 1 and 2 are unfeasible.
|
||||
Method 3 can be used as a fallback if method 1 and 2 are not possible.
|
||||
|
||||
#### Method 1: Kubectl command
|
||||
#### Method 1: Force a redeploy of the Rancher agents
|
||||
|
||||
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).
|
||||
For each downstream cluster run the following command using the Kubeconfig file of the Rancher (local) management cluster.
|
||||
|
||||
```
|
||||
kubectl patch clusters.management.cattle.io <REPLACE_WITH_CLUSTERID> -p '{"status":{"agentImage":"dummy"}}' --type merge
|
||||
```bash
|
||||
kubectl annotate clusters.management.cattle.io <CLUSTER_ID> io.cattle.agent.force.deploy=true
|
||||
```
|
||||
|
||||
This command will cause all Agent Kubernetes resources to be reconfigured with the checksum of the new certificate.
|
||||
:::note
|
||||
Locate the cluster ID (c-xxxxx) for the downstream cluster, this can be seen in the browser URL bar when viewing the cluster in the Rancher UI, under Cluster Management
|
||||
:::
|
||||
|
||||
This command will cause the agent manifest to be reapplied with the checksum of the new certificate.
|
||||
|
||||
#### Method 2: Manually update checksum
|
||||
#### Method 2: Manually update the checksum environment variable
|
||||
|
||||
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:
|
||||
Manually patch the agent Kubernetes objects 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 <RANCHER_SERVER>/v3/settings/cacerts | jq -r .value > cacert.tmp
|
||||
$ sha256sum cacert.tmp | awk '{print $1}'
|
||||
```bash
|
||||
curl -k -s -fL <RANCHER_SERVER_URL>/v3/settings/cacerts | jq -r .value | sha256sum cacert.tmp | awk '{print $1}'
|
||||
```
|
||||
|
||||
Using a Kubeconfig for each downstream cluster update the environment variable for the two agent deployments.
|
||||
Using a Kubeconfig for each downstream cluster update the environment variable for the two agent deployments. If the [ACE](https://docs.ranchermanager.rancher.io/how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint) is enabled for the cluster, [the kubectl context can be adjusted](https://docs.ranchermanager.rancher.io/how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig#authenticating-directly-with-a-downstream-cluster) to connect directly to the downstream cluster.
|
||||
|
||||
```
|
||||
$ kubectl edit -n cattle-system ds/cattle-node-agent
|
||||
$ kubectl edit -n cattle-system deployment/cattle-cluster-agent
|
||||
```bash
|
||||
kubectl edit -n cattle-system ds/cattle-node-agent
|
||||
kubectl edit -n cattle-system deployment/cattle-cluster-agent
|
||||
```
|
||||
|
||||
#### Method 3: Recreate Rancher agents
|
||||
#### Method 3: Manually redeploy the 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.
|
||||
With this method the Rancher agents are reapplied by running a set of commands on a control plane node of each downstream cluster.
|
||||
|
||||
First, generate the agent definitions as described here: https://gist.github.com/superseb/076f20146e012f1d4e289f5bd1bd4971
|
||||
Repeat the below steps for each downstream cluster:
|
||||
|
||||
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
|
||||
1. Retrieve the agent registration kubectl command:
|
||||
1. Locate the cluster ID (c-xxxxx) for the downstream cluster, this can be seen in the URL when viewing the cluster in the Rancher UI under Cluster Management
|
||||
1. Add the Rancher server URL and cluster ID to the following URL: `https://<RANCHER_SERVER_URL>/v3/clusterregistrationtokens?clusterId=<CLUSTER_ID>`
|
||||
1. Copy the command from the `insecureCommand` field, this command is used because a private CA is un use
|
||||
|
||||
### 5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher
|
||||
2. Run the kubectl command from the previous step using a kubeconfig for the downstream cluster with one of the following methods:
|
||||
1. If the [ACE](https://docs.ranchermanager.rancher.io/how-to-guides/new-user-guides/manage-clusters/access-clusters/authorized-cluster-endpoint) is enabled for the cluster, [the context can be adjusted](https://docs.ranchermanager.rancher.io/how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig#authenticating-directly-with-a-downstream-cluster) to connect directly to the downstream cluster
|
||||
1. Alternatively, SSH into the control plane node:
|
||||
1. RKE: Use the [steps in the document here](https://github.com/rancherlabs/support-tools/tree/master/how-to-retrieve-kubeconfig-from-custom-cluster) to generate a kubeconfig
|
||||
1. RKE2/K3s: Use the kubeconfig populated during installation
|
||||
|
||||
### 5. Force Update Fleet clusters to reconnect the fleet-agent to Rancher
|
||||
|
||||
Select 'Force Update' for the clusters within the [Continuous Delivery](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.
|
||||
|
||||
#### Why is this step required?
|
||||
|
||||
Fleet agents in Rancher managed clusters store kubeconfig that is used to connect to the Rancher proxied kube-api in the fleet-agent secret of the fleet-system namespace. The kubeconfig contains a certificate-authority-data block containing the Rancher CA. When changing the Rancher CA, this block needs to be updated for a successful connection of the fleet-agent to Rancher.
|
||||
Fleet agents in Rancher managed clusters store a kubeconfig that is used to connect to Rancher. The kubeconfig contains a `certificate-authority-data` field containing the CA for the certificate used by Rancher. When changing the CA, this block needs to be updated to allow the fleet-agent to trust the certificate used by Rancher.
|
||||
|
||||
## Updating from a Private CA Certificate to a Common Certificate
|
||||
## Updating from a Private CA Certificate to a Public CA Certificate
|
||||
|
||||
:::note
|
||||
Follow these steps to perform the opposite procedure as shown above, to change from a certificate issued by a private CA, to a public or self-signed CA.
|
||||
|
||||
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
|
||||
### 1. Create/update the certificate secret object
|
||||
|
||||
First, concatenate the server certificate followed by any intermediate certificate(s) to a file named `tls.crt` and provide the corresponding certificate key in a file named `tls.key`.
|
||||
|
||||
If you are switching the install from using the Rancher self-signed certificate or Let’s Encrypt issued certificates, use the following command to create the `tls-rancher-ingress` secret resource in your Rancher HA cluster:
|
||||
Use the following command to create the `tls-rancher-ingress` secret object in thr Rancher (local) management cluster:
|
||||
|
||||
```
|
||||
$ kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
```bash
|
||||
kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
--cert=tls.crt \
|
||||
--key=tls.key
|
||||
```
|
||||
|
||||
Alternatively, to update an existing certificate secret:
|
||||
Alternatively, to update an existing `tls-rancher-ingress` secret:
|
||||
|
||||
```
|
||||
$ kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
```bash
|
||||
kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
--cert=tls.crt \
|
||||
--key=tls.key \
|
||||
--dry-run --save-config -o yaml | kubectl apply -f -
|
||||
```
|
||||
|
||||
### 2. Delete the CA certificate secret resource
|
||||
### 2. Delete the CA certificate secret object
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
To save the existing secret:
|
||||
To save the existing `tls-ca` secret:
|
||||
|
||||
```
|
||||
```bash
|
||||
kubectl -n cattle-system get secret tls-ca -o yaml > tls-ca.yaml
|
||||
```
|
||||
|
||||
To delete the existing `tls-ca` secret:
|
||||
|
||||
```
|
||||
```bash
|
||||
kubectl -n cattle-system delete secret tls-ca
|
||||
```
|
||||
|
||||
### 3. Reconfigure the Rancher deployment
|
||||
|
||||
:::note Important:
|
||||
This step is required if the certificate source is changing. In this scenario it's likely only changing because Rancher was previously configured to use the default self-signed certificate (`ingress.tls.source=rancher`).
|
||||
|
||||
Before proceeding, [generate an API token in the Rancher UI](../../../reference-guides/user-settings/api-keys.md#creating-an-api-key) (<b>User > API & Keys</b>).
|
||||
The below steps update the Helm values for the Rancher chart, so the Rancher pods and ingress are reconfigured to use the new certificate created in Step 1.
|
||||
|
||||
:::
|
||||
|
||||
This step is required if Rancher was initially installed with self-signed certificates (`ingress.tls.source=rancher`) or with a Let's Encrypt issued certificate (`ingress.tls.source=letsEncrypt`).
|
||||
|
||||
It ensures that the Rancher pods and ingress resources are reconfigured to use the new server and optional CA certificate.
|
||||
|
||||
To update the Helm deployment you will need to use the same (`--set`) options that were used during initial installation. Check with:
|
||||
|
||||
```
|
||||
$ helm get values rancher -n cattle-system
|
||||
```
|
||||
|
||||
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 the current chart version to prevent an application upgrade.
|
||||
|
||||
Also make sure to read the documentation describing the initial installation using custom certificates.
|
||||
|
||||
```
|
||||
helm upgrade rancher rancher-stable/rancher \
|
||||
--namespace cattle-system \
|
||||
--version <DEPLOYED_CHART_VERSION> \
|
||||
--set hostname=rancher.my.org \
|
||||
--set ...
|
||||
```
|
||||
|
||||
On upgrade, you can either
|
||||
|
||||
- remove `--set ingress.tls.source=secret \` from the Helm upgrade command, as shown above, or
|
||||
|
||||
- remove the `privateCA` parameter or set it to `false` because the CA is valid:
|
||||
|
||||
```
|
||||
set privateCA=false
|
||||
```
|
||||
1. Adjust the values that were used during initial installation, store the current values with:
|
||||
```bash
|
||||
helm get values rancher -n cattle-system -o yaml > values.yaml
|
||||
```
|
||||
1. Also get the version string of the currently deployed Rancher chart:
|
||||
```bash
|
||||
helm ls -n cattle-system
|
||||
```
|
||||
1. Update the current Helm values in the `values.yaml` file:
|
||||
1. As a private CA is no longer being used, remove the `privateCA: true` field, or set this to `false`
|
||||
1. Adjust the `ingress.tls.source` field as necessary. Please [refer to the chart options](https://docs.ranchermanager.rancher.io/getting-started/installation-and-upgrade/installation-references/helm-chart-options#common-options) for more details. Here are some examples:
|
||||
1. If using a public CA continue with a value of: `secret`
|
||||
1. If using Let's Encrypt update the value to: `letsEncrypt`
|
||||
1. Update the Helm values for the Rancher chart using the `values.yaml` file, and the current chart version to prevent an upgrade:
|
||||
```bash
|
||||
helm upgrade rancher rancher-stable/rancher \
|
||||
--namespace cattle-system \
|
||||
-f values.yaml \
|
||||
--version <DEPLOYED_RANCHER_VERSION>
|
||||
```
|
||||
|
||||
### 4. Reconfigure Rancher agents for the non-private/common certificate
|
||||
|
||||
`CATTLE_CA_CHECKSUM` environment variable on the downstream cluster agents should be removed or set to "" (an empty string).
|
||||
As a private CA is no longer being used, the `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
|
||||
### 5. Force Update Fleet clusters to reconnect the fleet-agent to Rancher
|
||||
|
||||
Select 'Force Update' for the clusters within the [Continuous Delivery](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md#accessing-fleet-in-the-rancher-ui) view of the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.
|
||||
|
||||
#### Why is this step required?
|
||||
|
||||
Fleet agents in Rancher managed clusters store kubeconfig that is used to connect to the Rancher proxied kube-api in the fleet-agent secret of the fleet-system namespace. The kubeconfig contains a certificate-authority-data block containing the Rancher CA. When changing the Rancher CA, this block needs to be updated for a successful connection of the fleet-agent to Rancher.
|
||||
Fleet agents in Rancher managed clusters store a kubeconfig that is used to connect to Rancher. The kubeconfig contains a `certificate-authority-data` field containing the CA for the certificate used by Rancher. When changing the CA, this block needs to be updated to allow the fleet-agent to trust the certificate used by Rancher.
|
||||
Reference in New Issue
Block a user