impersonator: add docs regarding limited serivce account
Signed-off-by: Monis Khan <mok@vmware.com>
This commit is contained in:
parent
87489da316
commit
addf632e7c
@ -11,7 +11,9 @@ The specifics of how it is implemented are of interest. The most novel detail
|
|||||||
about the implementation is that we use the "front-end" of the aggregated API
|
about the implementation is that we use the "front-end" of the aggregated API
|
||||||
server logic, mainly the DefaultBuildHandlerChain func, to handle how incoming
|
server logic, mainly the DefaultBuildHandlerChain func, to handle how incoming
|
||||||
requests are authenticated, authorized, etc. The "back-end" of the proxy is a
|
requests are authenticated, authorized, etc. The "back-end" of the proxy is a
|
||||||
reverse proxy that impersonates the user (instead of serving REST APIs).
|
reverse proxy that impersonates the user (instead of serving REST APIs). Since
|
||||||
|
impersonation fails open, we impersonate users via a secondary service account
|
||||||
|
that has no other permissions on the cluster.
|
||||||
|
|
||||||
In terms of authentication, we aim to handle every type of authentication that
|
In terms of authentication, we aim to handle every type of authentication that
|
||||||
the Kubernetes API server supports by delegating most of the checks to it. We
|
the Kubernetes API server supports by delegating most of the checks to it. We
|
||||||
|
Loading…
Reference in New Issue
Block a user