assuming that kubernetes is almost always used with docker. In case other container solutions as lxc are integrated this section
will need further revision. Just using the bare etcl command is a bit too less, at least there should be a hint that you log in into the container.
The old text said that the authorizer is expected to determine group
memberships when the authenticator does not. This not true. It is
allowed, but not expected --- and none of the standard authorizers do
it. I tried composing a brief correct statement about this, but the
reviews were mainly aghast that internal details of some non-standard
authorizers were being injected into the discussion of authentictors.
I decided that the better part of valor is simply to delete the whole
topic from here. Besides, it is a conclusion that any reader would
normally draw --- since there is no statement forbidding it (nor
indeed any indication that there might be a reason to forbid it), any
reader would naturally conclude that an authorizer is free to derive
additional intermediate information of any sort and in any way it
likes.
Noted this where the relevance of api group is introduced, and
corrected the reference to what the empty string means ("core" api
group, which is the terminology used in the page that introduces api
group, rather than the old text "default").
Noted that every bearer token, in any of the four authentication
strategies that use bearer tokens, appears in an HTTP header
value without additional quotation/encoding (beyond that supported
by HTTP). Included a fully concrete example. Wrote this down once,
where the issue first arises, and referenced it from the other relevant
strategies.
This constraint was elicited in #sig-auth discussion
on Sep 21, and not previously stated explicitly and in a way that
clearly applied to all four kinds of bearer token --- leaving the
reader to wonder if some other encoding is expected.
Dominic001