Using `RequiresRepublish` for rotation

[aramase]

When requiresRepublish: true is set in the CSIDriver spec

  requiresRepublish: true # added in Kubernetes 1.20, this field is beta as of Kubernetes 1.21

kubelet will periodically send NodePublishVolume to the driver.

• Investigate if we can use this feature with internal backoff logic for rotation

/assign

[aramase]

/kind feature

[tam7t]

Based on https://kubernetes-csi.github.io/docs/token-requests.html#feature-gate

• 1.19 does not have this (EOL: 2021-10-28)
• 1.20 adds this as optional (--feature-gates=CSIServiceAccountToken=true) (EOL: 2022-02-28)
• 1.21 enables this by default

We could emulate this behavior in the driver (give driver permission to act as any SA in the cluster, maintain token caches for republish).

[tam7t]

RequiresRepublish would help us delete the pkg/rotation/reconciler.go controller, but that controller is ALSO responsible for updating sync'd K8s secret values.

That may mean that we need to rethink some K8s secret syncing logic to:

• stay in existing controller rotation/reconciler controller
• add logic topkg/secrets-store/nodeserver.go
• expand secretproviderclasspodstatus_controller.go responsibilities to updates as well as initial creates

[nilekhc]

We are reviewing proposal with SIG-Auth. If we end up creating separate subproject then we can deprecate sync secret logic altogether from driver.

[tam7t]

We need a design on how to introduce this in a way thats:

• compatible with rotation
• compatible with sync

And backwards compatible for 1.19 + 1.20 where the cluster may not have this built in (or delay the feature until 1.20 is deprecated...)

@aramase specifically brings up keeping notes about auth token audience parameters like:

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: mycsidriver.example.com
spec:
  tokenRequests:
    - audience: "gcp"
    - audience: ""
      expirationSeconds: 3600
  requiresRepublish: true

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale