SecretManagerSecret's nextRotationTime should take a duration relative to now()

[DWSR]

Describe the feature or resource
For SecretManagerSecret, it's awkward to specify a time in the future because "the future" at the time of writing and opening a Pull Request might be "the past" by the time the PR is merged and the resource is applied to the cluster.

Ideally, as a KCC user, I'd be able to specify something like this:

apiVersion: secretmanager.cnrm.cloud.google.com/v1beta1
kind: SecretManagerSecret
metadata:
  name: days-of-future-past
spec:
  rotation:
    nextRotationTime:
      relative: 5m
    rotationPeriod: 3600

which would cause KCC to create a SecretManagerSecret with a nextRotationTime of 5 minutes from the time that it creates the GCP resource

Importance
This is a pain point that almost entirely stops us from using automatic rotation of secrets. Ideally, we'd be able to populate the secret with some bootstrap value, then (almost) immediately rotate it. This is useful for things like CloudSQL user passwords.

[jcanseco]

Thanks @DWSR. I think this request makes sense. I'll forward it to the Secret Manager team internally since it seems this would need to be a change on the Secret Manager API.

[DWSR]

Thanks @DWSR. I think this request makes sense. I'll forward it to the Secret Manager team internally since it seems this would need to be a change on the Secret Manager API.

I don't think it does, to be honest. You can store generated properties in the status fields on the K8s object, or use an admission webhook to mutate the existing object as it's submitted to the API.

Ideally the API would be updated to support this functionality, but I can see at least a few ways around that in KCC specifically.

[jcanseco]

I see what you mean, though generally speaking, we try not to implement resource-specific behavior in KCC to resolve API limitations due to maintenance costs which would be difficult to scale as we support 10-100X more GCP resources.

A change on the API side also means that customers on other client tools (Terraform, gcloud) would also benefit.

A possible approach (if this use-case is valuable enough for you and you cannot wait for an API change) is to build a higher-level layer on top of SecretManagerSecret in K8s (kinda like how Deployments manage Pods). Part of KCC's value proposition is to make it easier for users to build such automation in K8s to automate the management of their KCC (and thus GCP) resources. While we'd like to build such a layer for you, we unfortunately can't due to lack of capacity, but we'd be willing to drive changes to KCC and the K8s ecosystem if building such a layer proves difficult.