Skip to content

Follow-up to Explain Impersonation (PR#2020) #2149

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ahardin-rh merged 1 commit into from
May 25, 2016
Merged

Follow-up to Explain Impersonation (PR#2020) #2149

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 22 additions & 15 deletions architecture/additional_concepts/authentication.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -88,22 +88,29 @@ 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 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 <username>`.
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
<username>`.

[[oauth]]

Expand Down