From 2134a96f7019619f0c822f3fd95b0dac68f07d82 Mon Sep 17 00:00:00 2001 From: Silvio Moioli Date: Thu, 18 Sep 2025 10:23:23 +0200 Subject: [PATCH] Feature was implemented, remove unimplemented notice Signed-off-by: Silvio Moioli --- .../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 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 96126da4a6f..c47655c0497 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,12 +89,6 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can ## 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). diff --git a/versioned_docs/version-2.10/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.10/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index e3dd9cb475e..ad311566b03 100644 --- a/versioned_docs/version-2.10/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.10/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -89,12 +89,6 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can ## 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). diff --git a/versioned_docs/version-2.11/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.11/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index e3dd9cb475e..ad311566b03 100644 --- a/versioned_docs/version-2.11/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.11/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -89,12 +89,6 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can ## 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). diff --git a/versioned_docs/version-2.12/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.12/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index 96126da4a6f..c47655c0497 100644 --- a/versioned_docs/version-2.12/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.12/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -89,12 +89,6 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can ## 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).