Race Condition in Password Creation Results in Invalid Password

[mdgreenfield]

When generating Azure credentials using a role configured with an existing service principal, there is a race condition in the password creation logic which can result in a password being returned to the caller but not set on the Azure application.

The logic is as follows:

• List Passwords (note that keyIds are returned here, no actual passwords)
• [add/remove password from list}
• Update Passwords (if a keyId is not present, the password is removed)

As a result, it is possible for request A and request B to retrieve the same list of existing passwords (i.e. keyIds) but the last request from A or B to update the passwords will win.

Although, there is locking in place to prevent that, this does not handle the case where an existing service principal is configured on multiple Azure secret engine mounts or across multiple Vault clusters.

The current logic is using the deprecated Azure AD Graph API, however, the newer Microsoft Graph API has endpoints to atomically addPassword and removePassword.

Because the MS Graph API has a different set of permissions required for the plugin configuration, it is probably better to have a flag on the plugin configuration that defaults to the Azure AD Graph API but which allows users to upgrade to the MS Graph API once their permission changes have been added.