From bf382897c9a89ffbc0de3562b5eab016f3807b1c Mon Sep 17 00:00:00 2001 From: martyav Date: Fri, 23 Aug 2024 16:53:51 -0400 Subject: [PATCH 01/10] Update versions table - v2.9.1 --- src/pages/versions.md | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) diff --git a/src/pages/versions.md b/src/pages/versions.md index 08101635102..66d7c3d8b4d 100644 --- a/src/pages/versions.md +++ b/src/pages/versions.md @@ -18,12 +18,12 @@ Here you can find links to supporting documentation for the current released ver Community - v2.9.0 + v2.9.1 Documentation - Release Notes -
N/A
+ Release Notes
N/A
✓
+
✓
@@ -90,6 +90,30 @@ Here you can find links to supporting documentation for the current released ver Here you can find links to supporting documentation for previous versions of Rancher v2.8, and their availability for [Rancher Prime](/v2.8/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher: + + + + + + + + + + + + + + + + + + + + +
VersionDocumentationRelease NotesSupport MatrixPrimeCommunity
v2.9.0DocumentationRelease Notes
N/A
N/A
✓
+ +Here you can find links to supporting documentation for previous versions of Rancher v2.8, and their availability for [Rancher Prime](/v2.8/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher: + From 382447e1e12eb9aaaa4b273be9c4425e1e562fd3 Mon Sep 17 00:00:00 2001 From: martyav Date: Mon, 26 Aug 2024 06:49:21 -0400 Subject: [PATCH 02/10] [v2.9.1] Update Webhook Table --- docs/reference-guides/rancher-webhook.md | 1 + versioned_docs/version-2.9/reference-guides/rancher-webhook.md | 1 + 2 files changed, 2 insertions(+) diff --git a/docs/reference-guides/rancher-webhook.md b/docs/reference-guides/rancher-webhook.md index 2dcfd257e29..81afd495fb0 100644 --- a/docs/reference-guides/rancher-webhook.md +++ b/docs/reference-guides/rancher-webhook.md @@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w | Rancher Version | Webhook Version | Availability in Prime | Availability in Community | |-----------------|-----------------|-----------------------|---------------------------| +| v2.9.1 | v0.5.1 | ✓ | ✓ | | v2.9.0 | v0.5.0 | ✗ | ✓ | ## Why Do We Need It? diff --git a/versioned_docs/version-2.9/reference-guides/rancher-webhook.md b/versioned_docs/version-2.9/reference-guides/rancher-webhook.md index 2dcfd257e29..81afd495fb0 100644 --- a/versioned_docs/version-2.9/reference-guides/rancher-webhook.md +++ b/versioned_docs/version-2.9/reference-guides/rancher-webhook.md @@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w | Rancher Version | Webhook Version | Availability in Prime | Availability in Community | |-----------------|-----------------|-----------------------|---------------------------| +| v2.9.1 | v0.5.1 | ✓ | ✓ | | v2.9.0 | v0.5.0 | ✗ | ✓ | ## Why Do We Need It? From 93a4f795127f8f7adeab52d6d81fb8f6f39092d5 Mon Sep 17 00:00:00 2001 From: martyav Date: Mon, 26 Aug 2024 07:33:42 -0400 Subject: [PATCH 03/10] [v2.9.1] Update CSP Adapter Table --- .../cloud-marketplace/aws-cloud-marketplace/install-adapter.md | 3 ++- .../cloud-marketplace/aws-cloud-marketplace/install-adapter.md | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md b/docs/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md index 3cf3e0426d5..94f31fa0aa1 100644 --- a/docs/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md +++ b/docs/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md @@ -19,7 +19,8 @@ In order to deploy and run the adapter successfully, you need to ensure its vers | Rancher Version | Adapter Version | |-----------------|:----------------:| -| v2.9.0 | v104.0.0+up4.0.0 | +| v2.9.1 | v104.0.0+up4.0.0 | +| v2.9.0 | v104.0.0+up4.0.0 | ### 1. Gain Access to the Local Cluster diff --git a/versioned_docs/version-2.9/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md b/versioned_docs/version-2.9/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md index 3cf3e0426d5..94f31fa0aa1 100644 --- a/versioned_docs/version-2.9/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md +++ b/versioned_docs/version-2.9/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md @@ -19,7 +19,8 @@ In order to deploy and run the adapter successfully, you need to ensure its vers | Rancher Version | Adapter Version | |-----------------|:----------------:| -| v2.9.0 | v104.0.0+up4.0.0 | +| v2.9.1 | v104.0.0+up4.0.0 | +| v2.9.0 | v104.0.0+up4.0.0 | ### 1. Gain Access to the Local Cluster From 8a7de06bb89d8b4b04b0a4ebfee3b323ffc1ea7a Mon Sep 17 00:00:00 2001 From: martyav Date: Mon, 26 Aug 2024 08:06:39 -0400 Subject: [PATCH 04/10] [v2.9.1] Update Deprecations Table --- docs/faq/deprecated-features.md | 1 + versioned_docs/version-2.9/faq/deprecated-features.md | 1 + 2 files changed, 2 insertions(+) diff --git a/docs/faq/deprecated-features.md b/docs/faq/deprecated-features.md index 71961aa7dba..59f44ff1d3b 100644 --- a/docs/faq/deprecated-features.md +++ b/docs/faq/deprecated-features.md @@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https:// | Patch Version | Release Date | |---------------|---------------| +| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | August 26, 2024 | | [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | July 31, 2024 | ### What can I expect when a feature is marked for deprecation? diff --git a/versioned_docs/version-2.9/faq/deprecated-features.md b/versioned_docs/version-2.9/faq/deprecated-features.md index 71961aa7dba..59f44ff1d3b 100644 --- a/versioned_docs/version-2.9/faq/deprecated-features.md +++ b/versioned_docs/version-2.9/faq/deprecated-features.md @@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https:// | Patch Version | Release Date | |---------------|---------------| +| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | August 26, 2024 | | [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | July 31, 2024 | ### What can I expect when a feature is marked for deprecation? From a7e5e2b9cdd6c7c3e528e5c765761ecd33ce77f5 Mon Sep 17 00:00:00 2001 From: martyav Date: Mon, 26 Aug 2024 08:10:10 -0400 Subject: [PATCH 05/10] consistently using 3 char month --- docs/faq/deprecated-features.md | 4 ++-- versioned_docs/version-2.9/faq/deprecated-features.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/faq/deprecated-features.md b/docs/faq/deprecated-features.md index 59f44ff1d3b..3671baec4ee 100644 --- a/docs/faq/deprecated-features.md +++ b/docs/faq/deprecated-features.md @@ -16,8 +16,8 @@ Rancher will publish deprecated features as part of the [release notes](https:// | Patch Version | Release Date | |---------------|---------------| -| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | August 26, 2024 | -| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | July 31, 2024 | +| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | Aug 26, 2024 | +| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | Jul 31, 2024 | ### What can I expect when a feature is marked for deprecation? diff --git a/versioned_docs/version-2.9/faq/deprecated-features.md b/versioned_docs/version-2.9/faq/deprecated-features.md index 59f44ff1d3b..3671baec4ee 100644 --- a/versioned_docs/version-2.9/faq/deprecated-features.md +++ b/versioned_docs/version-2.9/faq/deprecated-features.md @@ -16,8 +16,8 @@ Rancher will publish deprecated features as part of the [release notes](https:// | Patch Version | Release Date | |---------------|---------------| -| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | August 26, 2024 | -| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | July 31, 2024 | +| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | Aug 26, 2024 | +| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | Jul 31, 2024 | ### What can I expect when a feature is marked for deprecation? From db25cc87a5d91aa3e6ab3135611fa11296e2e939 Mon Sep 17 00:00:00 2001 From: Marty Hernandez Avedon Date: Mon, 26 Aug 2024 10:03:00 -0400 Subject: [PATCH 06/10] [v2.9.1] Update from main to keep working branch PRs less messy to review (#1442) * Use crds.enabled to install cert-manager Signed-off-by: Dharmit Shah * versioned * reverted changes to earliest versions and slightly modified comment * spacing issue --------- Signed-off-by: Dharmit Shah Co-authored-by: Dharmit Shah Co-authored-by: Billy Tat --- .../install-upgrade-on-a-kubernetes-cluster.md | 4 ++-- .../install-upgrade-on-a-kubernetes-cluster.md | 4 ++-- .../install-upgrade-on-a-kubernetes-cluster.md | 4 ++-- .../install-upgrade-on-a-kubernetes-cluster.md | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md b/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md index a8fa6fd51cc..8ccdb43d1bf 100644 --- a/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md +++ b/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md @@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases ::: ``` -# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart: +# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download//cert-manager.crds.yaml # Add the Jetstack Helm repository @@ -161,7 +161,7 @@ helm repo update helm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ - --set installCRDs=true + --set crds.enabled=true ``` Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods: diff --git a/versioned_docs/version-2.7/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md b/versioned_docs/version-2.7/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md index 8d367774725..cede46f04d0 100644 --- a/versioned_docs/version-2.7/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md +++ b/versioned_docs/version-2.7/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md @@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases ::: ``` -# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart: +# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download//cert-manager.crds.yaml # Add the Jetstack Helm repository @@ -161,7 +161,7 @@ helm repo update helm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ - --set installCRDs=true + --set crds.enabled=true ``` Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods: diff --git a/versioned_docs/version-2.8/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md b/versioned_docs/version-2.8/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md index 2ca5266315e..885c00f81dd 100644 --- a/versioned_docs/version-2.8/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md +++ b/versioned_docs/version-2.8/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md @@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases ::: ``` -# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart: +# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download//cert-manager.crds.yaml # Add the Jetstack Helm repository @@ -161,7 +161,7 @@ helm repo update helm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ - --set installCRDs=true + --set crds.enabled=true ``` Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods: diff --git a/versioned_docs/version-2.9/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md b/versioned_docs/version-2.9/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md index a8fa6fd51cc..8ccdb43d1bf 100644 --- a/versioned_docs/version-2.9/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md +++ b/versioned_docs/version-2.9/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md @@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases ::: ``` -# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart: +# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download//cert-manager.crds.yaml # Add the Jetstack Helm repository @@ -161,7 +161,7 @@ helm repo update helm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ - --set installCRDs=true + --set crds.enabled=true ``` Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods: From 7df7b91fc44abdc830a90df7bcd9ed825067df9f Mon Sep 17 00:00:00 2001 From: Marty Hernandez Avedon Date: Mon, 26 Aug 2024 11:38:36 -0400 Subject: [PATCH 07/10] Apply suggestions from code review Co-authored-by: Sunil Singh --- src/pages/versions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pages/versions.md b/src/pages/versions.md index 66d7c3d8b4d..6d87b0c8483 100644 --- a/src/pages/versions.md +++ b/src/pages/versions.md @@ -88,7 +88,7 @@ Here you can find links to supporting documentation for the current released ver ### Past Versions -Here you can find links to supporting documentation for previous versions of Rancher v2.8, and their availability for [Rancher Prime](/v2.8/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher: +Here you can find links to supporting documentation for previous versions of Rancher v2.9, and their availability for [Rancher Prime](/v2.9/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
Version
From a2d2a8805472ea466f44f74b9c80f517fd3c083f Mon Sep 17 00:00:00 2001 From: Sunil Singh Date: Mon, 26 Aug 2024 09:05:31 -0700 Subject: [PATCH 08/10] Adding in known issues warning to Impersonation section for v2.9.1. Signed-off-by: Sunil Singh --- .../communicating-with-downstream-user-clusters.md | 6 ++++++ .../communicating-with-downstream-user-clusters.md | 6 ++++++ .../communicating-with-downstream-user-clusters.md | 6 ++++++ .../communicating-with-downstream-user-clusters.md | 6 ++++++ 4 files changed, 24 insertions(+) diff --git a/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index 381c4baee7d..aa18647ed76 100644 --- a/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -89,6 +89,12 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can ## Impersonation +:::caution Known Issues + +Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked. + +::: + Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster. When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr). diff --git a/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index 8abfd0c9f6c..626298136b5 100644 --- a/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -81,6 +81,12 @@ You will need to use a context defined in this kubeconfig file to access the clu ## Impersonation +:::caution Known Issues + +Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked. + +::: + Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster. When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr). diff --git a/versioned_docs/version-2.8/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.8/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index 08639d4b819..977a51dc633 100644 --- a/versioned_docs/version-2.8/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.8/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -90,6 +90,12 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can ## Impersonation +:::caution Known Issues + +Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked. + +::: + Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster. When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr). diff --git a/versioned_docs/version-2.9/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.9/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index 381c4baee7d..aa18647ed76 100644 --- a/versioned_docs/version-2.9/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.9/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -89,6 +89,12 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can ## Impersonation +:::caution Known Issues + +Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked. + +::: + Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster. When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr). From c4802f036d2e81cf9a533fa326b898ef851f6492 Mon Sep 17 00:00:00 2001 From: Sunil Singh Date: Mon, 26 Aug 2024 09:37:35 -0700 Subject: [PATCH 09/10] Editing Known Issues to singular Signed-off-by: Sunil Singh --- .../communicating-with-downstream-user-clusters.md | 2 +- .../communicating-with-downstream-user-clusters.md | 2 +- .../communicating-with-downstream-user-clusters.md | 2 +- .../communicating-with-downstream-user-clusters.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index aa18647ed76..ebdbd0526eb 100644 --- a/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -89,7 +89,7 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can ## Impersonation -:::caution Known Issues +:::caution Known Issue Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked. diff --git a/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index 626298136b5..9797a377796 100644 --- a/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -81,7 +81,7 @@ You will need to use a context defined in this kubeconfig file to access the clu ## Impersonation -:::caution Known Issues +:::caution Known Issue Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked. diff --git a/versioned_docs/version-2.8/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.8/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index 977a51dc633..617236638e5 100644 --- a/versioned_docs/version-2.8/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.8/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -90,7 +90,7 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can ## Impersonation -:::caution Known Issues +:::caution Known Issue Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked. diff --git a/versioned_docs/version-2.9/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.9/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index aa18647ed76..ebdbd0526eb 100644 --- a/versioned_docs/version-2.9/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.9/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -89,7 +89,7 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can ## Impersonation -:::caution Known Issues +:::caution Known Issue Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked. From 5608d3a7e995fb590d3322fb84afa2622fa9decf Mon Sep 17 00:00:00 2001 From: Sunil Singh Date: Mon, 26 Aug 2024 11:29:54 -0700 Subject: [PATCH 10/10] Adding note to v2.6 Signed-off-by: Sunil Singh --- .../communicating-with-downstream-user-clusters.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index d1fd5b1cad1..591bcccdd67 100644 --- a/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -82,6 +82,12 @@ You will need to use a context defined in this kubeconfig file to access the clu ## Impersonation +:::caution Known Issue + +Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked. + +::: + Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster. When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).