This commit fills out the JWT "kid" (KeyID) field on most
serviceaccount tokens we create. The KeyID value we use is derived
from the public key of keypair that backs the cluster's OIDC issuer.
OIDC verifiers use the KeyID to smoothly cope with key rotations:
* During a rotation, the verifier will have multiple keys cached
from the issuer, any of which could have signed the token being
verified. KeyIDs let the verifier pick the appropriate key
without having to try each one.
* Seeing a new KeyID is a trigger for the verifier to invalidate its
cached keys and fetch the new set of valid keys from the identity
provider.
The value we use for the KeyID is derived from the identity provider's
public key by serializing it in DER format, taking the SHA256 hash,
and then urlsafe base64-encoding it. This gives a value that is
strongly bound to the key, but can't be reversed to obtain the public
key, which keeps people from being tempted to derive the key from the
key ID and using that for verification.
Tokens based on jose OpaqueSigners are omitted for now --- I don't see
any way to actually run the API server that results in an OpaqueSigner
being used.
Currently, the character limit for the usernames set in the RunAsUserName is 20,
which is too low, considering that "ContainerAdministrator" is a valid username and
it is longer than 20 characters. A user should be able to run containers as
Administrator, if needed.
According to [1], Logon names can be up to 104 characters. The previous limit
only applies to local user accounts for the local system.
[1] https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/bb726984(v=technet.10)
This makes sub packages of e2e test framework to use log functions
of core framework instead for avoiding circular dependencies.
NOTE: test/e2e/framework/ssh will make circular dependencies if
updating it. It is necessary to solve the issue in advance
before this work.
The current mechanism for excluding "master" nodes based on node names
is fragile and should be fixed by using a label exclusion similar to
service load balancers. The legacy code path is preserved behind a
defaulted-on gate and will be removed in the future.
The service load balancer controller should honor the
LegacyNodeRoleBehavior feature gate for checks that use node-roles,
switch to using a non alpha annotation behind the gate, and prepare
to graduate to beta.
This gate will default to on in 1.16 to cover the behavior of the
existing system, and then in the future default to off and then be
removed once all consumers have migrated.
The status can be used by (Pre)Filter plugins to indicate that
preemption wouldn't change the decision of the filter.
Signed-off-by: Aldo Culquicondor <acondor@google.com>
The assumption so far was that all drivers support read/write
volumes. That might not necessarily be true, so we have to let the
test driver specify it and then test accordingly.
Another aspect that is worth testing is whether the driver correctly
creates a new volume for each pod even if the volume attributes are
the same. However, drivers are not required to do that, so again we
have to let the test driver specify that.
After deleting a pod, we need to be sure that it really is gone,
otherwise there is a race condition: if we remove the CSI driver that
is responsible for the volume used by the pod before the pod is
actually deleted, deleting the pod will fail.
