explain impersonation

architecture/additional_concepts/authentication.adoc

@@ -88,6 +88,23 @@ 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 <username>`.
+
 [[oauth]]
 
 == OAuth