Optional expiration metadata for credentials with administrative warnings

[loic-AMCS]

What feature do you want to see added?

The Jenkins Credentials Plugin currently provides a flexible and generic way to store credentials, but does not include lifecycle-related metadata such as expiration.

I would like to propose adding an optional expiration date field to credentials, along with non-intrusive administrative warnings in the UI.

Proposed behavior:

• Allow setting an optional expiration date when creating or updating a credential
• Display a warning in the Jenkins UI when:
  • the expiration date is approaching (configurable threshold)
  • the credential is expired
• Make this information available as read-only metadata via existing APIs

Design considerations:

• No enforcement: expired credentials remain usable
• No change in runtime behavior (lookup, binding, pipelines, etc.)
• Fully optional and backward compatible
• No performance impact (UI-level feature only)

Goal:

Provide better visibility for administrators regarding credential lifecycle, without introducing policy enforcement or altering the plugin’s core behavior.

Upstream changes

No response

Are you interested in contributing this feature?

No response

[timja]

I don’t think we would want it be UI only.

If it’s set then it should be enforced IMO

[loic-AMCS]

I agree that if an expiration date is introduced, it should have some meaningful behavior beyond UI indication.

To align with that, what about a hybrid approach:

Proposal: optional enforcement mode

• Add an optional expiration date field on credentials
• Add a configurable behavior controlled at system level (or credential domain level):
  • Warning mode (default):
    • expired / near-expiry credentials show UI warnings only
    • no impact on runtime behavior
  • Enforced mode (opt-in):
    • expired credentials are rejected at usage time (e.g. binding / lookup failure)
    • allows administrators to progressively adopt strict expiration policies

This also avoids making expiration purely cosmetic while still not forcing strict behavior on existing installations.

[timja]

I'm not sure there's much need for this optional enforcement.

Its only enforced if you set an expiration date. If you have one set you can update the expiry date...

[loic-AMCS]

Thanks, that makes sense. Keeping it simple and enforcing expiration only when the field is set sounds like a good approach.

I agree with this direction.