Description
When adding a Git repository to an Azure DevTest Lab, the service internally creates a secret in the associated Azure Key Vault to store the repository authentication information.
The issue is that the secret is created without an expiration date.
Many organizations enforce Azure governance and compliance policies that require all Key Vault secrets to have an expiration date. As a result, these automatically created secrets are flagged as non-compliant, even though they are managed by the DevTest Labs service.
Additionally, Azure DevTest Labs currently does not support referencing an existing Key Vault secret through a Key Vault Secret URL (or similar mechanism). This prevents customers from managing the secret lifecycle themselves while remaining compliant with organizational policies.
Expected behavior
One or both of the following capabilities should be supported:
Automatically set an expiration date on the Key Vault secret created by Azure DevTest Labs.
Allow customers to reference an existing Key Vault secret (for example, via a Key Vault Secret URL or secret reference) instead of having DevTest Labs create and manage the secret internally.
Actual behavior
Azure DevTest Labs creates a new Key Vault secret without an expiration date.
The expiration cannot be configured during repository creation.
Existing Key Vault secrets cannot be referenced instead of creating a new one.
Impact
Organizations with Azure Policy or internal security/compliance requirements that enforce expiration dates on Key Vault secrets cannot use the repository integration without generating policy violations.
Feature request
Please add support for either:
Configuring the expiration date for service-created Key Vault secrets, or
Using an existing Azure Key Vault secret/reference instead of automatically creating a new secret.
This would enable customers to remain compliant with organizational governance and security policies while continuing to use Azure DevTest Labs repository integration.
Description
When adding a Git repository to an Azure DevTest Lab, the service internally creates a secret in the associated Azure Key Vault to store the repository authentication information.
The issue is that the secret is created without an expiration date.
Many organizations enforce Azure governance and compliance policies that require all Key Vault secrets to have an expiration date. As a result, these automatically created secrets are flagged as non-compliant, even though they are managed by the DevTest Labs service.
Additionally, Azure DevTest Labs currently does not support referencing an existing Key Vault secret through a Key Vault Secret URL (or similar mechanism). This prevents customers from managing the secret lifecycle themselves while remaining compliant with organizational policies.
Expected behavior
One or both of the following capabilities should be supported:
Automatically set an expiration date on the Key Vault secret created by Azure DevTest Labs.
Allow customers to reference an existing Key Vault secret (for example, via a Key Vault Secret URL or secret reference) instead of having DevTest Labs create and manage the secret internally.
Actual behavior
Azure DevTest Labs creates a new Key Vault secret without an expiration date.
The expiration cannot be configured during repository creation.
Existing Key Vault secrets cannot be referenced instead of creating a new one.
Impact
Organizations with Azure Policy or internal security/compliance requirements that enforce expiration dates on Key Vault secrets cannot use the repository integration without generating policy violations.
Feature request
Please add support for either:
Configuring the expiration date for service-created Key Vault secrets, or
Using an existing Azure Key Vault secret/reference instead of automatically creating a new secret.
This would enable customers to remain compliant with organizational governance and security policies while continuing to use Azure DevTest Labs repository integration.