![]() * Rewrite vault core, orchestrate AppRoles for minions 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 * Fix linting for rewritten vault integration * Add pytest unit tests for utils.vault, fix found issues * Fix old vault runner tests * Rewrite vault sdb tests, migrate to pytests * Adapt vault ext_pillar tests * Adapt vault execution module tests, migrate to pytests * Add more vault execution module unit tests * Support python <3.7 (vault util), time-independent tests * Add/migrate vault runner unit tests (pytest) * Add vault state module pytests * Fix tests lint * Refactor Vault container fixture, move to session scope * Fix for existing vault execution/sdb module integration tests * Improve existing vault runner integration tests * Fix vault test support, add list policies * Add more functional execution module tests, fix deprecated warning * Refactor vault pytest support * Add integration tests, improve/fix caching/issue_params * Improve caching behavior, fix tests * Always use session cache as well * Also flush session cache when requested * Make KV metadata caching behavior configurable * Update tests to account for changes from prev commit * Allow to autodiscover platform default CA bundle * Remove runner approle param overrides There is no simple way to ensure they are kept. * Add clear_cache runner function * Also manage token metadata for issued secret IDs * Cleanup tests * Cleanup code, pylint logging suggestions * Do not always invalidate config when verify=default * Ensure concatted metadata lists are sorted * Add changelog (partly) * Work with legacy peer_run configuration as well * Consume a token use regardless of status code * Correct verify semantics * Refine token uses handling, add changelog/tests for old issues * Add changelog for main features * Add test for issue 58580 * Fix vault docs * Provide all old make_request functionality, add tests * Allow token use override, add docstrings to query funcs * Simplify config_location merge * Cleanup * Fix make_request warning * Attempt to fix memory issues during CI test run * Increase documented version * Improve lease handling * Refine lease ttl handling/add token lifecycle management * Fix docs build * Adapt formatting * assert what you get against what you expect * drop empty parentheses after wrapper * use `is` to compare against strictly boolean vars * Fix issue param overrides * during pillar rendering, they were always reset by the master (for AppRoles) * overrides were only respected for some settings (AppRoles) * old config syntax was using the old syntax internally (tech debt) * Introduce session-scoped cache * Tokens with a single use left are unrenewable * Allow override of flushing of cached leases during lookup * Refactor cache classes, save lease data * Rename session token cache key * Add lease management utility * Fix runner integration tests after renaming the token cache key * Do not overwrite data of cached leases after renewal * Pass token_lifecycle to minions * Do not fail syncing multiple approles/entities with pillar templates * Ensure config cache expiration can be disabled * Rename changelog files (.md) * Declare vaultpolicylexer as parallel read safe * Correct meta[data] payload key For tokens it is `meta`, but for secret IDs, `metadata`. * Reuse TCP connection * Refactor utils module * Ensure client is recreated after clearing cache * Always use unwrap_client config as expected server This should fix the test failure in the runner integration test TestAppRoleIssuance::test_server_switch_does_not_break_minion_auth * Ensure client is recreated after clearing cache 2 * Simulate patch for KV v1 or missing `patch` capability * Add `patch` option to Vault SDB driver * Reduce lease validity when revocation fails * Extract AppRole/Identity API from runner into utils * Revoke tokens, fire events, improve cache/exception handling * Tokens (and therefore associated leases) are revoked when cleared by default * It's possible to disable clearing cache when a perfectly valid token is available, but a PermissionDeniedError is encountered. * UnwrapExceptions always cause an event to be fired * It's possible to enable sending of events when a) cache is cleared b) a lease is requested from cache, but it is/will be invalid * A VaultAuthException does not immediately lead to clearing the connection cache * get_authd_client and others: multiple small enhancements and fixes * Allow updating cached config w/o closing session * Homogenize funcs, update docs, cleanup * Minor internal fixes `is_valid_for` is present on all lease-like objects, while `is_valid` specifically should account for more, e.g. the number of uses. The Vault API does not return 404 when a lookup fails. * Add release note * Address review remarks * Fix release notes * Remove loading minion_mods from factory * Address other review remarks * Add inline specification of trusted CA root cert * Small QoL additions * Fix lint * Fix lint for Python >=3.8 support * Add missing fixes * Fix unit tests In some cases, the `spec` calls were failing because the underlying object was already patched --------- Co-authored-by: Thomas Phipps <tphipps@vmware.com> |
||
---|---|---|
.github | ||
changelog | ||
cicd | ||
conf | ||
doc | ||
pkg | ||
requirements | ||
rfcs | ||
salt | ||
scripts | ||
templates | ||
tests | ||
tools | ||
.backportrc.json | ||
.bandit | ||
.codeclimate.yml | ||
.codecov.yml | ||
.coveragerc | ||
.editorconfig | ||
.git-blame-ignore-revs | ||
.gitattributes | ||
.gitignore | ||
.gitlab-ci.yml | ||
.mention-bot | ||
.pre-commit-config.yaml | ||
.pylintrc | ||
AUTHORS | ||
CHANGELOG.md | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.rst | ||
DEPENDENCIES.md | ||
Gemfile | ||
kitchen.yml | ||
LICENSE | ||
MANIFEST.in | ||
NOTICE | ||
noxfile.py | ||
pyproject.toml | ||
pytest.ini | ||
README.rst | ||
SECURITY.md | ||
setup.cfg | ||
setup.py | ||
SUPPORT.rst |

- Latest Salt Documentation
- Open an issue (bug report, feature request, etc.)
Salt is the world's fastest, most intelligent and scalable automation engine.
About Salt
Built on Python, Salt is an event-driven automation tool and framework to deploy, configure, and manage complex IT systems. Use Salt to automate common infrastructure administration tasks and ensure that all the components of your infrastructure are operating in a consistent desired state.
Salt has many possible uses, including configuration management, which involves:
- Managing operating system deployment and configuration.
- Installing and configuring software applications and services.
- Managing servers, virtual machines, containers, databases, web servers, network devices, and more.
- Ensuring consistent configuration and preventing configuration drift.
Salt is ideal for configuration management because it is pluggable, customizable, and plays well with many existing technologies. Salt enables you to deploy and manage applications that use any tech stack running on nearly any operating system, including different types of network devices such as switches and routers from a variety of vendors.
In addition to configuration management Salt can also:
- Automate and orchestrate routine IT processes, such as common required tasks for scheduled server downtimes or upgrading operating systems or applications.
- Create self-aware, self-healing systems that can automatically respond to outages, common administration problems, or other important events.
About our sponsors
Salt powers VMware's VMware Aria Automation Config (previously vRealize Automation SaltStack Config / SaltStack Enterprise), and can be found under the hood of products from Juniper, Cisco, Cloudflare, Nutanix, SUSE, and Tieto, to name a few.
The original sponsor of our community, SaltStack, was acquired by VMware in 2020. The Salt Project remains an open source ecosystem that VMware supports and contributes to. VMware ensures the code integrity and quality of the Salt modules by acting as the official sponsor and manager of the Salt project. Many of the core Salt Project contributors are also VMware employees. This team carefully reviews and enhances the Salt modules to ensure speed, quality, and security.
Download and install Salt
Salt is tested and packaged to run on CentOS, Debian, RHEL, Ubuntu, MacOS, Windows, and more. Download Salt and get started now. See supported operating systems for more information.
To download and install Salt, see: * The Salt install guide * Salt Project repository
Technical support
Report bugs or problems using Salt by opening an issue: https://github.com/saltstack/salt/issues
To join our community forum where you can exchange ideas, best practices, discuss technical support questions, and talk to project maintainers, join our Slack workspace: Salt Project Community Slack
Salt Project documentation
Installation instructions, tutorials, in-depth API and module documentation:
Security advisories
Keep an eye on the Salt Project Security Announcements landing page. Salt Project recommends subscribing to the Salt Project Security RSS feed to receive notification when new information is available regarding security announcements.
Other channels to receive security announcements include the Salt Community mailing list and the Salt Project Community Slack.
Responsibly reporting security vulnerabilities
When reporting security vulnerabilities for Salt or other SaltStack projects, refer to the SECURITY.md file found in this repository.
Join our community
Salt is built by the Salt Project community, which includes more than 3,000 contributors working in roles just like yours. This well-known and trusted community works together to improve the underlying technology and extend Salt by creating a variety of execution and state modules to accomplish the most common tasks or solve the most important problems that people in your role are likely to face.
If you want to help extend Salt or solve a problem with Salt, you can join our community and contribute today.
Please be sure to review our Code of Conduct. Also, check out some of our community resources including:
- Salt Project Community Wiki
- Salt Project Community Slack
- Salt Project: IRC on LiberaChat
- Salt Project YouTube channel
- Salt Project Twitch channel
There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Project Community Events Calendar on the main https://saltproject.io website.
If you have additional questions, email us at saltproject@vmware.com or reach out directly to the Community Manager, Jimmy Chunga via Slack. We'd be glad to have you join our community!
License
Salt is licensed under the Apache 2.0 license. Please see the LICENSE file for the full text of the Apache license, followed by a full summary of the licensing used by external modules.
A complete list of attributions and dependencies can be found here: salt/DEPENDENCIES.md