Allow cluster-signing-duration to be set in Shoot spec

[lotharbach]

How to categorize this issue?

/area security
/area usability
/kind enhancement

What would you like to be added:
Since #5096 gardener sets the kube-controller-manager flag --cluster-signing-duration to 720h. Even when a CertificateSigningRequest with a larger spec.expirationSeconds is given, the generated cert is only valid for 30d. Upstream default is 8760h (1y).

We would like to introduce a new field in the Shoot spec to make that configurable, and keep the default at 720h.

Why is this needed:
User is trying to generate certificate based kubeconfigs with their own RBAC by basically doing the steps from
https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user and don't want to renew that every 30 days. They feel limited by the gardener default compared to other kubernetes solutions they are using, and ask us to at least allow the upstream default of 1 year.

It appears to me the motivation of #5096 was to reduce the kubelets certificate lifetime as it is auto-renewing anyway, and there is no way for the kubelet to request a shorter expiration independent of this global "maximum" setting right now. So people would also change kubelet behavior even if they only care about their own CSRs. Arguably that is worse for security, but I would still let them make that decision.

[rfranzke]

Well summarized @lotharbach!

Indeed, the chosen default of 720h and the decision to not make it configurable was a conscious one. We didn't want people/end-users to tamper with this field - for security reasons - since it affects the validity of the kubelet server + client certificates which are managed by Gardener. As you wrote above, there is still no way for the kubelet to request a shorter expiration, even in today's master branch: https://github.com/kubernetes/kubernetes/blob/87fa400d9ddf4fa48ab32a7d745a3b60dc785e5d/pkg/kubelet/certificate/bootstrap/bootstrap.go#L350-L353 (see nil argument - this is the desired expiration, and if not set, the global KCM setting applies).

So people would also change kubelet behavior even if they only care about their own CSRs. Arguably that is worse for security, but I would still let them make that decision.

We could argue that this is in the responsibility of the end-user and indeed make it configurable, but I don't know whether everybody is in favour of this line of argumentation. @vlerenc @donistz - opinions? Personally, I like the status quo because this ensures that every certificate managed by Gardener has a short validity.

OTOH, the rotation of the certificate authorities is also in the responsibility of the end-user. While we don't care/enforce them to do it regularly, we at least control the validity/rotation of the certificate signed by these CAs. When making the --cluster-signing-duration configurable, we would loose this aspect.

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues 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 as fresh with /remove-lifecycle stale
• Mark this issue as rotten with /lifecycle rotten
• Close this issue with /close

/lifecycle stale