-
Notifications
You must be signed in to change notification settings - Fork 334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
azure_rm_keyvaultsecret doesn't reliably allow specified credentials #1009
Comments
The same problem appears in these modules:
This fixes the issue (assuming you are using a virtual environment and it's in
|
@markscottwright You are welcome to provide PR to fix this problem. Thank you very much! |
When service principals are specified in the module arguments (subscription_id, tenant, client_id, secret) and auth_type is auto, azure_rm_keyvaultkey, azure_rm_keyvaultkey_info, azure_rm_keyvaultsecret, azure_rm_keyvaultsecret_info first attempted to use credentials from env and the disk and only use the specified credentials if not found. To reproduce, specify a service principal in `cloud-config-azure.ini` and run: `ansible-test integration azure_rm_keyvaultsecret --allow-destructive` The test will succeed. Then, do an `az login` and re-run the above command. The test will fail. Delete your cached credentials: `rm ~/.azure/msal_token_cache.json` Run the test again. The test will succeed. c.f. ansible-collections#1009
@markscottwright auth_source specifies the priority of obtaining the credentials in azure_rm_common. All modules are common (azure_rm_.py), while the azure_rm_keyvault module specifies that 'cli' and 'auto' are used to obtain the cli login configuration. Thanks! |
@Fred-sun Are you saying this is as designed? If auth_source is 'auto' and credentials are specified, but cli credentials are present, then specified credentials will be ignored and the cli credentials used? If so, we can't use this module, since we do not want to use cli credentials (and only discovered this issue when running a playbook on localhost after I had run some unrelated commands using the az cli client). It means playbooks can't reliably be run in parallel (since they will pick up each other's credentials). And of course, it means that sensitive information is persisted to the disk. The auth_source behavior used in other modules seems much better. |
@markscottwright Maybe we'll follow the logic of azure_rm_common.py here as well. get_keyvault_client can be obtained using env, credentials_file or az login. Will this meet your needs? Thanks! |
My understanding of azure_rm_common.py is that it goes "module parameters -> env -> credential_file -> cli" (this is what the azure_rm_keyvaultsecret docs say too). We need to use module parameters. Credentials file and cli are of no interest (since they persist the secrets to disk). We could, if necessary, use env, but would definitely prefer that azure_rm_keyvaultsecret be consistent with the rest of the azure modules. |
When service principals are specified in the module arguments (subscription_id, tenant, client_id, secret) and auth_type is auto, azure_rm_keyvaultkey, azure_rm_keyvaultkey_info, azure_rm_keyvaultsecret, azure_rm_keyvaultsecret_info first attempted to use credentials from env and the disk and only use the specified credentials if not found. To reproduce, specify a service principal in `cloud-config-azure.ini` and run: `ansible-test integration azure_rm_keyvaultsecret --allow-destructive` The test will succeed. Then, do an `az login` and re-run the above command. The test will fail. Delete your cached credentials: `rm ~/.azure/msal_token_cache.json` Run the test again. The test will succeed. c.f. #1009 Co-authored-by: Mark Wright <mark.wright@primekey.com>
SUMMARY
If credentials are explicitly specified for azure_rm_keyvaultsecret, but it is possible to retrieve credentials from the environment, the explicitly specified credentials are ignored. In other words, the (default) auth_source of "auto" does not act as documented "When set to auto (the default) the precedence is module parameters -> env -> credential_file -> cli." Instead, the precedence is "env -> credential_file -> cli -> module parameters".
This means that there is no way to be certain that specified module parameters will be used.
The error is in line 207:
azure/plugins/modules/azure_rm_keyvaultsecret.py
Line 210 in 950f64d
The code on that line should probably be something like:
"if self.module.params['auth_source'] == 'cli' or (self.module.params['auth_source'] == 'auto' and self.credentials['client_id'] is None and self.credentials['secret'] is None):"
ISSUE TYPE
COMPONENT NAME
azure_rm_keyvaultsecret
ANSIBLE VERSION
COLLECTION VERSION
CONFIGURATION
STEPS TO REPRODUCE
EXPECTED RESULTS
The secret is set.
ACTUAL RESULTS
I get this error. Note that
04b07795-8ddb-461a-bbee-02f9e1bf7b46
is not the app id that I specified (or that I know about).The user, group or application 'appid=04b07795-8ddb-461a-bbee-02f9e1bf7b46;oid=480ab1d9-a1a7-4a53-a509-15185d58d9a0;numgroups=1;iss=https://sts.windows.net/PRIVATE/' does not have secrets set permission on key vault 'PRIVATE;location=centralus'. For help resolving this issue, please see https://go.microsoft.com/fwlink/?linkid=2125287\n",
(Note that private information below has be replaced)
The text was updated successfully, but these errors were encountered: