[KeyVault] az keyvault secret set --expires flag silently accepts invalid date format

[notyashhh]

Describe the bug

az keyvault secret set --expires "2025-13-45" does not validate the date and silently passes the invalid value to the API, resulting in a confusing 400 Bad Request from the service.

Steps to reproduce

az keyvault secret set --vault-name myvault --name mysecret --value test --expires "2025-13-45"

Current behavior

(BadParameter) Property expires in value "2025-13-45" is not a valid UTC datetime.

The error comes from the service, not from the CLI. The CLI should catch this before sending the request.

Expected behavior

The CLI should validate --expires locally and return a clear error:

ERROR: Invalid date format for --expires: "2025-13-45". Expected format: YYYY-MM-DD or ISO 8601 datetime.

Environment

• az cli version: 2.85.0
• OS: macOS 14.5
• Shell: zsh

---

This is a test issue for demonstrating the Sentinel triage agent.

[yonzhan]

Thank you for opening this issue, we will look into it.

[microsoft-github-policy-service]

🔔 Routing this issue to @act-identity-squad.

[microsoft-github-policy-service]

🔔 Routing this issue to @act-identity-squad.

[notyashhh]

⚠️ Sentinel was unable to complete the analysis for this issue. This may be due to a timeout or an issue with accessing the repository. Please try again or triage manually.

[notyashhh]

🔍 Sentinel Analysis

Category: bug | Severity: P3-low | Component: KeyVault

Thank you for filing this issue.

I investigated the --expires parameter validation path and found that the datetime_type validator in keyvault/_validators.py (line 503) already validates date formats before sending the request. It tries four accepted formats (%Y-%m-%dT%H:%M:%SZ, %Y-%m-%dT%H:%MZ, %Y-%m-%dT%HZ, %Y-%m-%d) and raises a ValueError if none match.

Python's datetime.strptime correctly rejects 2025-13-45 because month 13 is invalid, so the CLI should catch this client-side with the message:

Input '2025-13-45' not valid. Valid example: 2000-12-31T12:59:59Z

Could you confirm whether you can reproduce this on CLI version 2.85.0? If the service error is returned instead of a client-side validation error, there may be a code path bypassing the validator.

That said, the existing error message could be improved — e.g., explicitly stating "Expected format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ" — which aligns with the expected behavior you described.

---

Verdict: ⚠️ ActionRequired

Root Cause Analysis:
The --expires parameter for az keyvault secret set is defined in src/azure-cli/azure/cli/command_modules/keyvault/_params.py (line 529) with type=datetime_type. The datetime_type function is implemented in _validators.py (lines 503-513) and tries parsing the input against four accepted formats: %Y-%m-%dT%H:%M:%SZ, %Y-%m-%dT%H:%MZ, %Y-%m-%dT%HZ, and %Y-%m-%d. If none match, it raises ValueError("Input '...' not valid. Valid example: 2000-12-31T12:59:59Z"). Python's datetime.strptime correctly rejects '2025-13-45' with the %Y-%m-%d format because month 13 is invalid. This means the CLI should already catch this invalid input before sending the request. The reported behavior (400 Bad Request from the service) is likely not reproducible with the current codebase (v2.85.0). However, the error message raised by the validator could be improved for clarity — it currently says 'Input X not valid. Valid example: 2000-12-31T12:59:59Z' rather than a more user-friendly format explanation. Note: The issue body explicitly states 'This is a test issue for demonstrating the Sentinel triage agent.'

Duplicate Check:
No duplicate issues found. Searched for 'keyvault expires date format', 'keyvault date validation', 'expires invalid date keyvault', and 'keyvault secret set expires' — only this issue (#33233) was returned.

Scope: in-scope — KeyVault commands (az keyvault) are owned by the Identity Squad. The --expires parameter validation is in the keyvault module's _validators.py.

Fix Feasibility: easy
Fix Description: If the bug is confirmed reproducible, investigate whether the type=datetime_type is being bypassed in some code path. If it's just an error message improvement, update the ValueError message in datetime_type() in _validators.py (line 513) to be more descriptive: e.g., "Invalid date format for input '{}'. Expected format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ (e.g., 2000-12-31T12:59:59Z)".

Use /sentinel fix to generate a PR with this fix.

---

💬 Available commands

Command	Description
/sentinel analyze	Re-run triage analysis
/sentinel fix	Generate a PR with a fix
/sentinel similar	Search for duplicate/related issues
/sentinel status	Show Sentinel's knowledge of this issue
/sentinel <any text>	Ask follow-up questions or request changes to the analysis

[microsoft-github-policy-service]

🔔 Routing this issue to @act-identity-squad.