From b0b4d913c4e9b8bcd65a30ad57f735e50854a59e Mon Sep 17 00:00:00 2001 From: Alex Dellapenta Date: Wed, 15 Jun 2016 17:14:07 -0400 Subject: [PATCH 1/3] Revert "Follow-up to Explain Impersonation (PR#2020)" This reverts commit 043e055d7a55d1291afab902273d56f44f600719. --- .../additional_concepts/authentication.adoc | 37 ++++++++----------- 1 file changed, 15 insertions(+), 22 deletions(-) diff --git a/architecture/additional_concepts/authentication.adoc b/architecture/additional_concepts/authentication.adoc index 0674c769db2b..3f6c411a810c 100644 --- a/architecture/additional_concepts/authentication.adoc +++ b/architecture/additional_concepts/authentication.adoc @@ -88,29 +88,22 @@ the `system:anonymous` virtual user and the `system:unauthenticated` virtual group to the request. This allows the authorization layer to determine which requests, if any, an anonymous user is allowed to make. -[[authentication-impersonation]] === Impersonation -A request to the {product-title} API may include an *Impersonate-User* header, -which indicates that the requester wants to have the request handled as though -it came from the specified user. This can be done on the command line by passing -the `*--as=username*` flag. - -Before User A is allowed to impersonate User B, User A is first authenticated. -Then, an authorization check occurs to ensure that User A is allowed to -impersonate the user named User B. If User A is requesting to impersonate a -service account (*system:serviceaccount:namespace:name*), {product-title} checks -to ensure that User A can impersonate the *serviceaccount* named *name* in -*namespace*. If the check fails, the request fails with a 403 (Forbidden) error -code. - -By default, project administrators and editors are allowed to impersonate -service accounts in their namespace. The *sudoers* role allows a user to -impersonate *system:admin*, which in turn has cluster administrator permissions. -This grants some protection against typos (but not security) for someone -administering the cluster. For example, `oc delete nodes --all` would be -forbidden, but `oc delete nodes --all --as=system:admin` would be allowed. You -can add a user to that group using `oadm policy add-cluster-role-to-user sudoer -`. +A request the OpenShift API may include an `"Impersonate-User"` header, which indicates that requester wants +to have request handled as though it came from the specified user. This can be done on the command line +by passing the `--as=username` flag. + +Before UserA is allowed to impersonate UserB, UserA is first authenticated and then an authorization +check is made to be sure UserA is allowed to "impersonate" the "user" named "UserB". If UserA is requesting to +impersonate a service account (`system:serviceaccount:namespace:name`), we check to make sure that UserA can +"impersonate" the "serviceaccount" named "name" in "namespace". If he is disallowed, a 403 will be returned. + +By default, project admins and editors are allowed impersonate service accounts in their namespace. There is +also a new group called `sudoers`. That role allows a user to impersonate `system:admin`, which in turn has +cluster-admin permissions. This grants some protection against typos (but *not* security) for someone administering +the cluster. For example, `oc delete nodes --all` would be forbidden, but `oc delete nodes --all --as=system:admin` +would be allowed. You still have the power, but you have to mean it. You can add a user to that group using +`oadm policy add-cluster-role-to-user sudoer `. [[oauth]] From 951056e8ab9d1bacd7e4eb2be932a3332ab30d72 Mon Sep 17 00:00:00 2001 From: Alex Dellapenta Date: Wed, 15 Jun 2016 17:14:20 -0400 Subject: [PATCH 2/3] Revert "explain impersonation" This reverts commit 527abd236a98fa15710d3a815b4f40a724bf23f8. --- .../additional_concepts/authentication.adoc | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/architecture/additional_concepts/authentication.adoc b/architecture/additional_concepts/authentication.adoc index 3f6c411a810c..05f35473ed09 100644 --- a/architecture/additional_concepts/authentication.adoc +++ b/architecture/additional_concepts/authentication.adoc @@ -88,23 +88,6 @@ the `system:anonymous` virtual user and the `system:unauthenticated` virtual group to the request. This allows the authorization layer to determine which requests, if any, an anonymous user is allowed to make. -=== Impersonation -A request the OpenShift API may include an `"Impersonate-User"` header, which indicates that requester wants -to have request handled as though it came from the specified user. This can be done on the command line -by passing the `--as=username` flag. - -Before UserA is allowed to impersonate UserB, UserA is first authenticated and then an authorization -check is made to be sure UserA is allowed to "impersonate" the "user" named "UserB". If UserA is requesting to -impersonate a service account (`system:serviceaccount:namespace:name`), we check to make sure that UserA can -"impersonate" the "serviceaccount" named "name" in "namespace". If he is disallowed, a 403 will be returned. - -By default, project admins and editors are allowed impersonate service accounts in their namespace. There is -also a new group called `sudoers`. That role allows a user to impersonate `system:admin`, which in turn has -cluster-admin permissions. This grants some protection against typos (but *not* security) for someone administering -the cluster. For example, `oc delete nodes --all` would be forbidden, but `oc delete nodes --all --as=system:admin` -would be allowed. You still have the power, but you have to mean it. You can add a user to that group using -`oadm policy add-cluster-role-to-user sudoer `. - [[oauth]] == OAuth From f8dec2369e476a4d89eeb519c1132035c493201b Mon Sep 17 00:00:00 2001 From: Alex Dellapenta Date: Wed, 15 Jun 2016 17:16:14 -0400 Subject: [PATCH 3/3] Revhistory for OSE 3.2 Impersonation revert --- architecture/revhistory_architecture.adoc | 17 ++++++++++++++++- welcome/revhistory_full.adoc | 4 ++++ 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/architecture/revhistory_architecture.adoc b/architecture/revhistory_architecture.adoc index 154e622aa676..2ac3e17f5be7 100644 --- a/architecture/revhistory_architecture.adoc +++ b/architecture/revhistory_architecture.adoc @@ -6,6 +6,21 @@ :experimental: // do-release: revhist-tables +== Wed Jun 15 2016 + +// tag::architecture_wed_jun_15_2016[] +[cols="1,3",options="header"] +|=== + +|Affected Topic |Description of Change +//Wed Jun 15 2016 +|link:../architecture/additional_concepts/authentication.html[Additional Concepts -> Authentication] +|Removed the Impersonation section, which does not apply to {product-title} 3.2. + +|=== + +// end::architecture_wed_jun_15_2016[] + == Fri Jun 10 2016 // tag::architecture_fri_jun_10_2016[] @@ -37,7 +52,7 @@ |Affected Topic |Description of Change //Mon May 30 2016 |link:../architecture/additional_concepts/authentication.html[Additional Concepts -> Authentication] -|Added the link:../architecture/additional_concepts/authentication.html#authentication-impersonation[Impersonation] section. +|Added the Impersonation section. |link:../architecture/core_concepts/routes.html[Core Concepts -> Routes] |Added the link:../architecture/core_concepts/routes.html#router-sharding[Router Sharding] section. diff --git a/welcome/revhistory_full.adoc b/welcome/revhistory_full.adoc index 1f4e1f7cb2da..7c3434213fd5 100644 --- a/welcome/revhistory_full.adoc +++ b/welcome/revhistory_full.adoc @@ -9,6 +9,10 @@ The following sections aggregate the revision histories of each guide by publish date. // do-release: revhist-tables +== Wed Jun 15 2016 +.Architecture +include::architecture/revhistory_architecture.adoc[tag=architecture_wed_jun_15_2016] + == Tue Jun 14 2016 .Installation and Configuration include::install_config/revhistory_install_config.adoc[tag=install_config_tue_jun_14_2016]