From a2d2a8805472ea466f44f74b9c80f517fd3c083f Mon Sep 17 00:00:00 2001 From: Sunil Singh Date: Mon, 26 Aug 2024 09:05:31 -0700 Subject: [PATCH 1/2] 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 2/2] 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.