Understanding DelegatingAuthenticationOptions in Kubernetes

[zhouhaibing089]

Kubernetes allows you to extend kube-apiserver by registering APIService to kube-aggregator.

Briefly, kube-aggregator knows all the registered APIGroups and its corresponding serving apiserver, for example:

1. A request to /api/v1/nodes will be handed to kube-apiserver.
2. A request to /apis/foo/v1alpha1/bars will be handled to the apiserver which serves on the foo API group.

I might write another blog to figure out the internals of this mechanisms, but let's start with something simple.

Problem

A general workflow involved in kube-apiserver goes through:

1. Authentication
2. Authorization
3. Admission
4. Storage

It makes sense to have different storage for each apiserver, after all, they all serve on different purpose and thus different api resources. Admission is also different in each apiserver, too.

It is a little bit tricky to have different authentication/authorization, though. In order to unify the authentication and authorization within all the apiservers, DelegatingAuthentication and DelegatingAuthorization are introduced.

DelegatingAuthentication

There are several options to figure out user identities in extension apiservers.

• TokenReview
• x509 client cert
• authenticating proxy

TokenReview

Token review is an API provided by kubernetes core. Extension apiserver sends a
tokenreview request which includes the bearer token to kube-apiserver, and then
extension apiserver can check the response to get user identity.

In order to send request to kube-apiserver, a kubeconfig is required, and that's
what --authentication-kubeconfig is used to. The flag specifies the kubeconfig
to talk with kube-apiserver.

x509 client cert

Clients can provide a certificate which is trusted(signed) by a configured CA to
the extension apiserver. Extension apiserver can then derive user information
from its CN(as username) and Org(as groups). We can configure the same CA file for
kube-apiserver and extension apiserver so they share the same authentication.

Optionally, if extension apiserver is running in the host kubernetes cluster, it
can use in-cluster kubeconfig to read configmap extension-apiserver-authentication
in namespace kube-system, and get the client CA file there. This can be disabled
by adding flag --authentication-skip-lookup.

authenticating proxy

The request might already be authenticated before extension apiserver handles it.
For example, the request can come to kube-aggregator first, and authenticated by
kube-aggregator, then the request is forwarded to extension apiserver. In this
case, kube-aggregator acts like an authenticating proxy and can pass down the
identity to extension apiserver directly.

At extension apiserver side, we can configure:

• A CA file to verify that the request comes from authenting proxy in real. In
  the case above. kube-aggregator should forward requests with a client certificate
  to identify itself. Flag --requestheader-client-ca-file is used for this. And
  furthermore, --requestheader-allowed-names restricts the client certificates
  the extension apiserver trusts.
• A list of headers to read the user identity set by authenticating proxy.

Here are the available flags to configure the headers names where apiserver can
read user identity:

• Flag --requestheader-username-headers specifies a list of headers to read
  username.
• Flag --requestheader-group-headers specifies a list of headers to read groups.
• Flag --requestheader-extra-headers-prefix specifies a list of header prefixes
  to readextras information as a map.

Optionally, if extension apiserver is running in the host kubernetes cluster, it
can use in-cluster kubeconfig to read configmap extension-apiserver-authentication
in namespace kube-system, and get the request header client CA file there. This
can be disabled by adding flag --authentication-skip-lookup.