Azure ServicePrinciple secret type / continue support for individual credentials for withAzureKeyVault

[admalledd]

What feature do you want to see added?

Due to multiple compounding things, such as the lack of multi-key-vault and folder support, etc, we have a setup of a "Primary/System/Root" keyvault that is to contain (and scope) the minimal secrets required for inside a project's JenkinsFile to use withAzureKeyvault or azureKeyVault.

such an example

        withAzureKeyvault(
          keyVaultURLOverride: '....', 
          applicationIDOverride: "${AzureKV_AppID}",
          applicationSecretOverride: "${AzureKV_AppSecret}",
          tenantIdOverride: "${AzureKV_TenantID}",
          azureKeyVaultSecrets: [...]

However, doing this results in warnings:

Deprecated: Use a credential ID instead of individual values for the service principal.
If you can't then please raise an issue at https://github.com/jenkinsci/azure-keyvault-plugin/issues.
This will be removed at some point.

We for various reasons can't/don't want to store the Service Principle itself in Jenkins and prefer to pull it from our main KV.

Thus the ask of:

1. Continue to support the manual parameters/appId/appSec/tentantId until a viable alternate is officially supported (relates-to Add Folder Credentials Provider #97 )
2. Add a secret type that can hold/transform into an Azure Service Principal somehow.

Even if (1) is done, we would want the ASP/Credentials used to be pulled from our KV as well.

Upstream changes

No response

Are you interested in contributing this feature?

Due to my work contract, I am not allowed to work on external projects at this time. :(