[BUG] Using sdb.get from Vault in salt-cloud or salt-master config breaks Vault integration #59846
Comments
|
@garethgreenaway similar to #58897? |
sagetherage
added
severity-medium
|
Looks like something different. |
It does. |
|
@Arderos when you say :
What exact steps are you taking there, as the only output I'm getting at the moment is :
And there is no logging or indication of what is going on. |
The configuration for approle is in the issue description, in /etc/salt/master.d/vault.conf file. |
|
Turns out my issues is a known bug for how salt interacts with Vault enterprise (no passing of namespace) which is fixed and waiting for release in a future version. |
|
@JeremyHutchings is there any roadmap for this release you mentioned? |
Jeremy, can you please elaborate when this fix will be merged? It's still reproducing in version 3004 and basically is a blocker for us to use salt-cloud - corporate policy does not allow to store any kind of passwords in plain text |
|
I think this might be it : #58586 I don't know about which release it was supposed to be in |
I have tried 3004+0na.042b788 from git. Same error. |
|
Guys, any progress? |
This commit represents a fundamental rewrite in how Salt interacts with Vault. The master should still be compatible with minions running the old code. There should be no breaking changes to public interfaces and the old configuration format should still apply. Core: - Issue AppRoles to minions - Manage entities with templatable metadata for minions - Use inbuilt Salt cache - Separate config cache from token cache - Cache: introduce connection-scope vs global scope Utility module: - Support being imported (__utils__ deprecation) - Raise exceptions on queries to simplify response handling - Add classes to wrap complexity, especially regarding KV v2 - Lay some groundwork for renewing tokens Execution module: - Add patch_secret - Add version support to delete_secret - Allow returning listed keys only in list_secret - Add policy_[fetch/write/delete] and policies_list - Add query for arbitrary API queries State module: - Make use of execution module - Change output format Docs: - Update for new configuration format - Correct examples - Add configuration examples - Add required policies Fixes: saltstack/salt#62552 saltstack/salt#59827 saltstack/salt#62380 saltstack/salt#58174 Probably fixes: saltstack/salt#60779 saltstack/salt#57561 Might fix: saltstack/salt#59846
Description
If salt is configured with Hashicorp Vault integration via approle and 'sdb.get' is used in salt or salt-cloud configs an empty "salt_vault_token" file is placed in /var/cache/salt/master/ or /var/cache/salt/cloud/ respectively. With this file present, sdb.get runner stops returning information from Vault leading to salt-master start failure of salt-cloud failure to work with a provider in which the 'sdb.get' option is used.
Setup
/etc/salt/master.d/vault.conf:
/etc/salt/cloud.providers.d/vcenter.conf:
/etc/salt/master.d/rest.conf:
Steps to Reproduce the behavior
Install salt, salt-cloud and salt-api on a server
Configure vault integration via approle
Put a pointer to a secret in salt config file
Restart the salt-master.
Salt debug log:
Debug log from salt-cloud is the same.
Expected behavior
Salt and salt-cloud should get the data from Vault and use it to fill the relevant configuration variables.
Screenshots
Not applicable
Versions Report
salt --versions-report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: