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.
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 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.
Once we have deleted the pod and the volume, we want to be sure that
NodeUnpublishVolume was called for it. The main motivation was to
check this for inline ephemeral volumes, but the same additional check
also makes sense for other volumes.
We need the 1.2.0 driver for that because that has support for
detecting the volume mode dynamically, and we need to deploy a
CSIDriver object which enables pod info (for the dynamic detection)
and both modes (to satisfy the new mode sanity check).
This ensures that the files are in sync with:
hostpath: v1.2.0-rc3
external-attacher: v2.0.1
external-provisioner: v1.3.0
external-resizer: v0.2.0
external-snapshotter: v1.2.0
driver-registrar/rbac.yaml is obsolete because only
node-driver-registrar is in use now and does not need RBAC rules.
mock/e2e-test-rbac.yaml was not used anywhere.
The README.md files were updated to indicate that these really are
files copied from elsewhere. To avoid the need to constantly edit
these files on each update, <version> is used as placeholder in the URL.
