Improve SecretManager Secret TTL

[yuwenma]

Checklist

• I did not find a related open enhancement request.
• I understand that enhancement requests filed in the GitHub repository are by default low priority.
• If this request is time-sensitive, I have submitted a corresponding issue with GCP support.

Describe the feature or resource

Problem

SecretManager Secret has a configurable TTL field, which defines the time-to-live for a Secret from its last update time. However, this implementation can cause inconsistencies and drift between the Secret's state in Config Connector and the actual GCP service.

Current Behavior

• TTL is based on the Secret creation in the GCP. It does not count the created/updated time in Config Connector.
• Changing an existing Secret TTL won't reset its TTL to the new update time (different from gcloud)
• Changing another Secret field won't trigger a TTL reset also (different from gcloud)

Proposed solutions

While TTL is generally discouraged for managing time-based permissions in Secret Manager (IAM Conditions are recommended), we need to address the existing ttl functionality to ensure consistency and avoid unexpected behavior. Here are some options:

Option 1: Introduce initTTL

Rename the existing ttl field to initTTL to clarify that it only applies during initial Secret creation.
This improves API readability and avoids ambiguity, but it limits the functionality of the TTL feature and requires an API change (which might be reserved for a major version update).

Option 2: Deprecate ttl

Mark the ttl field as deprecated and emit errors if it's configured.
This solution encourages users to adopt IAM Conditions for time-based permissions and prevents further issues with TTL drift (users can still use the spec.expireTime). However, it could potentially break existing users who rely on the current (albeit flawed) TTL behavior.

Option 3: "Reset" TTL on All Updates

Modify the Config Connector implementation to "reset" the TTL timer whenever the Secret is created or updated in GCP.
This aligns the behavior most closely with the GCP service and gcloud, but it might not be the most intuitive behavior for a declarative configuration tool. Users might not expect that changing unrelated fields will also reset the TTL.

Decision

We need to carefully weigh the pros and cons of each option and consider the potential impact on existing users. We will update this issue. Please share your thoughts and the use of this resource.