KEP-4412: Projected Service Account Tokens for Kubelet Image Credential Providers

[aramase]

• One-line PR description: Add Projected Service Account Tokens for Kubelet Image Credential Providers alpha KEP

• Issue link: Projected service account tokens for Kubelet image credential providers #4412

[aramase]

/cc @enj

[aramase]

cc @mikebrow @SergeyKanzhelev @ndixita @ruiwen-zhao @harche @haircommander

as per #4412 (comment). PTAL!

[aramase]

/assign @deads2k
for PRR review

/assign enj liggitt haircommander

[enj]

First pass.

[SergeyKanzhelev]

will the token be time-bound? If so - how long?

[SergeyKanzhelev]

will it work nicely with things like stargz snapshotter where secret can be stored for a long time like: https://github.com/containerd/stargz-snapshotter/blob/main/docs/overview.md#cri-based-authentication?

cc: @samuelkarp

[aramase]

will the token be time-bound? If so - how long?

Yes, the token will be time-bound. The duration will be fixed at 1h (?). If the cloud provider associates this token duration to the credential lifetime, we don't want it to be too short-lived. 1h seems reasonable to cover those scenarios to prevent frequent calls to cloud provider for token exchange.

[aramase]

will it work nicely with things like stargz snapshotter where secret can be stored for a long time like: https://github.com/containerd/stargz-snapshotter/blob/main/docs/overview.md#cri-based-authentication?

IIUC, the stargz snapshotter in CRI-based authentication gets the same registry credentials as the CRI from kubelet, so that wouldn't change here? The credentials could now be short-lived if the lifetime is tied to the KSA token lifetime but otherwise should work the same way. Please correct me if I'm wrong.

[SergeyKanzhelev]

stargz is not downloading the whole image in one go. So it may keep streaming pieces after 1h. So it will end up with the stale credentials

[aramase]

stargz is not downloading the whole image in one go. So it may keep streaming pieces after 1h. So it will end up with the stale credentials

The credential provider plugin gets the PSAT and exchanges that for a registry credential. The registry credential is the one that stargz uses and it's not the PSAT right?

[haircommander]

correct. I think this can be compared to current behavior without specific PSAT: if a node wide credential expires while the image is being pulled with stargz, what does the runtime do? I'd expect the same here.

[SergeyKanzhelev]

oh, ok. So we are not giving time limited token to runtime. If this is the case, it will work

[SergeyKanzhelev]

I wonder if there is any test we can write that will validate that and ensure we are not breaking this scenario?

[aramase]

The tests in kubelet credential provider wouldn't validate this because it fetches the registry credentials and passes it to CRI (no change in behavior).

Tests in stargz would be good to confirm it works as expected when the registry credentials expire/it updates its cache when the credentials for the image change.
@SergeyKanzhelev do you know who can confirm if there are tests for this in stargz?

[deads2k]

some updates for beta criteria and PRR please.

[enj]

Looks inverted?

[deads2k]

PRR lgtm. KEP also lgtm, but I'll leave lgtm to @enj and whoever is looking from node.

/approve

[enj]

typo

[enj]

SIG node LGTM: #4846 (comment)

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aramase, deads2k, enj

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• keps/prod-readiness/OWNERS [deads2k]
• keps/sig-auth/OWNERS [deads2k,enj]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment