Welcome to the Chocolatey Community Package Repository! The packages found in this section of the site are provided, maintained, and moderated by the community.
Every version of each package undergoes a rigorous moderation process before it goes live that typically includes:
- Security, consistency, and quality checking
- Installation testing
- Virus checking through VirusTotal
- Human moderators who give final review and sign off
If you are an organization using Chocolatey, we want your experience to be fully reliable. Due to the nature of this publicly offered repository, reliability cannot be guaranteed. Packages offered here are subject to distribution rights, which means they may need to reach out further to the internet to the official locations to download files at runtime.
Fortunately, distribution rights do not apply for internal use. With any edition of Chocolatey (including the free open source edition), you can host your own packages and cache or internalize existing community packages.
Your use of the packages on this site means you understand they are not supported or guaranteed in any way. Learn more...
Downloads of v 0.8.0:
24 Aug 2017
- Mitchell Hashimoto
This is not the latest version of Vault available.
To edit the metadata for a package, please upload an updated version of the package.
Chocolatey's Community Package Repository currently does not allow updating package metadata on the website. This helps ensure that the package itself (and the source used to build the package) remains the one true source of package metadata.
This does require that you increment the package version.
This is not the latest version of Vault available.
All Checks are Passing
2 Passing Test
Validation Testing Passed
Verification Testing PassedDetails
This package was approved as a trusted package on 24 Aug 2017.
Vault is a tool for securely accessing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, certificates, and more. Vault provides a unified interface to any secret, while providing tight access control and recording a detailed audit log.
A modern system requires access to a multitude of secrets: database credentials, API keys for external services, credentials for service-oriented architecture communication, etc. Understanding who is accessing what secrets is already very difficult and platform-specific. Adding on key rolling, secure storage, and detailed audit logs is almost impossible without a custom solution. This is where Vault steps in.
The key features of Vault are:
- Secure Secret Storage: Arbitrary key/value secrets can be stored in Vault. Vault encrypts these secrets prior to writing them to persistent storage, so gaining access to the raw storage isn't enough to access your secrets. Vault can write to disk, Consul, and more.
- Dynamic Secrets: Vault can generate secrets on-demand for some systems, such as AWS or SQL databases. For example, when an application needs to access an S3 bucket, it asks Vault for credentials, and Vault will generate an AWS keypair with valid permissions on demand. After creating these dynamic secrets, Vault will also automatically revoke them after the lease is up.
- Data Encryption: Vault can encrypt and decrypt data without storing it. This allows security teams to define encryption parameters and developers to store encrypted data in a location such as SQL without having to design their own encryption methods.
- Leasing and Renewal: All secrets in Vault have a lease associated with it. At the end of the lease, Vault will automatically revoke that secret. Clients are able to renew leases via built-in renew APIs.
- Revocation: Vault has built-in support for secret revocation. Vault can revoke not only single secrets, but a tree of secrets, for example all secrets read by a specific user, or all secrets of a particular type. Revocation assists in key rolling as well as locking down systems in the case of an intrusion.
For more information, see the introduction section of the Vault website.
$checksum = '5dfb575f7d93b9a44a6ba0be9f0bb35604c7f7636303e2ebc27007b97aa44713' $checksum64 = 'dc9e9fda4cc89050b7a6ff9068acd548db52501be8028bd2f832ad3ef754ef9c' $url = 'https://releases.hashicorp.com/vault/0.8.0/vault_0.8.0_windows_386.zip' $url64bit = 'https://releases.hashicorp.com/vault/0.8.0/vault_0.8.0_windows_amd64.zip' $unzipLocation = "$(Split-Path -parent $MyInvocation.MyCommand.Definition)" Install-ChocolateyZipPackage -PackageName "vault" -Url "$url" -UnzipLocation "$unzipLocation" -Url64 "$url64bit" -ChecksumType 'sha256' -Checksum "$checksum" -Checksum64 "$checksum64"
Log in or click on link to see number of positives.
- vault.0.8.0.nupkg (088f55dde3bc) - ## / 58
- vault_0.8.0_windows_amd64.zip (dc9e9fda4cc8) - ## / 61
- vault_0.8.0_windows_386.zip (5dfb575f7d93) - ## / 61
- vault.exe (a5a49038d146) - ## / 64
- vault.exe (a84ea42c9208) - ## / 64
In cases where actual malware is found, the packages are subject to removal. Software sometimes has false positives. Moderators do not necessarily validate the safety of the underlying software, only that a package retrieves software from the official distribution point and/or validate embedded software against official distribution point (where distribution rights allow redistribution).
Chocolatey Pro provides runtime protection from possible malware.
|Vault 1.6.2||1842||Monday, February 1, 2021||Approved|
|Vault 1.6.1||614||Thursday, January 21, 2021||Approved|
|Vault 1.5.5||3175||Friday, October 23, 2020||Approved|
|Vault 1.5.4||1591||Thursday, October 22, 2020||Approved|
|Vault 1.5.3||230||Thursday, October 22, 2020||Approved|
|Vault 1.5.2||2210||Wednesday, August 26, 2020||Approved|
|Vault 1.5.0||1490||Wednesday, July 22, 2020||Approved|
|Vault 1.4.3||784||Friday, July 3, 2020||Approved|
|Vault 1.4.1||1628||Monday, May 4, 2020||Approved|
|Vault 1.4.0||1269||Thursday, April 9, 2020||Approved|
|Vault 1.3.4||135||Wednesday, April 8, 2020||Approved|
|Vault 1.3.3||796||Monday, March 9, 2020||Approved|
|Vault 1.3.2||1361||Friday, January 24, 2020||Approved|
|Vault 1.3.1||1493||Friday, December 20, 2019||Approved|
|Vault 1.3.0||393||Wednesday, December 11, 2019||Approved|
|Vault 1.2.4||935||Tuesday, November 12, 2019||Approved|
|Vault 1.2.3||3316||Monday, September 16, 2019||Approved|
|Vault 1.2.2||2258||Friday, August 16, 2019||Approved|
|Vault 1.2.1||73||Thursday, August 8, 2019||Approved|
|Vault 1.2.0||855||Wednesday, July 31, 2019||Approved|
|Vault 1.1.1||4935||Tuesday, April 16, 2019||Approved|
|Vault 1.1.0||894||Tuesday, March 19, 2019||Approved|
|Vault 1.0.3||589||Friday, March 1, 2019||Approved|
|Vault 0.10.0||3003||Monday, April 16, 2018||Approved|
|Vault 0.10.0-rc1||207||Saturday, April 7, 2018||Approved|
|Vault 0.9.6||378||Saturday, April 7, 2018||Approved|
|Vault 0.9.5||189||Saturday, April 7, 2018||Approved|
|Vault 0.9.4||240||Saturday, April 7, 2018||Approved|
|Vault 0.9.3||189||Saturday, April 7, 2018||Approved|
|Vault 0.9.2||192||Saturday, April 7, 2018||Approved|
|Vault 0.9.1||895||Saturday, January 13, 2018||Approved|
|Vault 0.9.0||239||Saturday, January 13, 2018||Approved|
|Vault 0.8.3||833||Wednesday, September 20, 2017||Approved|
|Vault 0.8.2||272||Wednesday, September 20, 2017||Approved|
|Vault 0.8.1||350||Thursday, August 24, 2017||Approved|
|Vault 0.8.0||317||Thursday, August 24, 2017||Approved|
|Vault 0.7.3||467||Thursday, June 8, 2017||Approved|
|Vault 0.7.2||318||Wednesday, June 7, 2017||Approved|
|Vault 0.7.1||281||Wednesday, June 7, 2017||Approved|
|Vault 0.7.0||295||Wednesday, June 7, 2017||Approved|
|Vault 0.6.5||805||Wednesday, February 8, 2017||Approved|
|Vault 0.6.4||419||Thursday, December 22, 2016||Approved|
|Vault 0.6.3||312||Wednesday, December 14, 2016||Approved|
|Vault 0.6.2||381||Tuesday, October 25, 2016||Approved|
|Vault 0.6.1||372||Tuesday, August 30, 2016||Approved|
0.8.0 (August 9th, 2017)
- We've added a note to the docs about the way the GitHub auth backend works as it may not be readily apparent that GitHub personal access tokens, which are used by the backend, can be used for unauthorized access if they are stolen from third party services and access to Vault is public.
- Database Plugin Backends: Passwords generated for these backends now enforce stricter password requirements, as opposed to the previous behavior of returning a randomized UUID. Passwords are of length 20, and have a
A1a-characters prepended to ensure stricter requirements. No regressions are expected from this change. (For database backends that were previously substituting underscores for hyphens in passwords, this will remain the case.)
- Lease Endpoints: The endpoints
sys/revoke-forcehave been deprecated and relocated under
sys/leases. Additionally, the deprecated path
sys/revoke-forcenow requires the
- Response Wrapping Lookup Unauthenticated: The
sys/wrapping/lookupendpoint is now unauthenticated. This allows introspection of the wrapping info by clients that only have the wrapping token without then invalidating the token. Validation functions/checks are still performed on the token.
- Cassandra Storage: Cassandra can now be used for Vault storage
- CockroachDB Storage: CockroachDB can now be used for Vault storage
- CouchDB Storage: CouchDB can now be used for Vault storage
- SAP HANA Database Plugin: The
databasesbackend can now manage users for SAP HANA databases
- Plugin Backends: Vault now supports running secret and auth backends as plugins. Plugins can be mounted like normal backends and can be developed independently from Vault.
- PROXY Protocol Support Vault listeners can now be configured to honor PROXY protocol v1 information to allow passing real client IPs into Vault. A list of authorized addresses (IPs or subnets) can be defined and accept/reject behavior controlled.
- Lease Lookup and Browsing in the Vault Enterprise UI: Vault Enterprise UI now supports lookup and listing of leases and the associated actions from the
sys/leasesendpoints in the API. These are located in the new top level navigation item "Leases".
- Filtered Mounts for Performance Mode Replication: Whitelists or blacklists of mounts can be defined per-secondary to control which mounts are actually replicated to that secondary. This can allow targeted replication of specific sets of data to specific geolocations/datacenters.
- Disaster Recovery Mode Replication (Enterprise Only): There is a new replication mode, Disaster Recovery (DR), that performs full real-time replication (including tokens and leases) to DR secondaries. DR secondaries cannot handle client requests, but can be promoted to primary as needed for failover.
- Manage New Replication Features in the Vault Enterprise UI: Support for Replication features in Vault Enterprise UI has expanded to include new DR Replication mode and management of Filtered Mounts in Performance Replication mode.
- Vault Identity (Enterprise Only): Vault's new Identity system allows correlation of users across tokens. At present this is only used for MFA, but will be the foundation of many other features going forward.
- Duo Push, Okta Push, and TOTP MFA For All Authenticated Paths (Enterprise Only): A brand new MFA system built on top of Identity allows MFA (currently Duo Push, Okta Push, and TOTP) for any authenticated path within Vault. MFA methods can be configured centrally, and TOTP keys live within the user's Identity information to allow using the same key across tokens. Specific MFA method(s) required for any given path within Vault can be specified in normal ACL path statements.
- api: Add client method for a secret renewer background process [GH-2886]
- api: Add
- api: Client timeout can now be adjusted with the
VAULT_CLIENT_TIMEOUTenv var or with a new API function [GH-2956]
- api/cli: Client will now attempt to look up SRV records for the given Vault hostname [GH-3035]
- audit/socket: Enhance reconnection logic and don't require the connection to be established at unseal time [GH-2934]
- audit/file: Opportunistically try re-opening the file on error [GH-2999]
- auth/approle: Add role name to token metadata [GH-2985]
- auth/okta: Allow specifying
max_ttlinside the mount [GH-2915]
- cli: Client timeout can now be adjusted with the
VAULT_CLIENT_TIMEOUTenv var [GH-2956]
- command/auth: Add
vault auththat returns only the token on stdout and does not store it via the token helper [GH-2855]
- core: CORS allowed origins can now be configured [GH-2021]
- core: Add metrics counters for audit log failures [GH-2863]
- cors: Allow setting allowed headers via the API instead of always using wildcard [GH-3023]
- secret/ssh: Allow specifying the key ID format using template values for CA type [GH-2888]
- server: Add
tls_client_ca_fileoption for specifying a CA file to use for client certificate verification when
tls_require_and_verify_client_certis enabled [GH-3034]
- storage/cockroachdb: Add CockroachDB storage backend [GH-2713]
- storage/couchdb: Add CouchhDB storage backend [GH-2880]
- storage/mssql: Add
- storage/postgresql: Add
- storage/postgresql: Improve listing speed [GH-2945]
- storage/s3: More efficient paging when an object has a lot of subobjects [GH-2780]
- sys/wrapping: Make
- sys/wrapping: Wrapped tokens now store the original request path of the data [GH-3100]
- telemetry: Add support for DogStatsD [GH-2490]
- api/health: Don't treat standby
429codes as an error [GH-2850]
- api/leases: Fix lease lookup returning lease properties at the top level
- audit: Fix panic when audit logging a read operation on an asymmetric
- auth/approle: Fix panic when secret and cidr list not provided in role [GH-3075]
- auth/aws: Look up proper account ID on token renew [GH-3012]
- auth/aws: Store IAM header in all cases when it changes [GH-3004]
- auth/ldap: Verify given certificate is PEM encoded instead of failing silently [GH-3016]
- auth/token: Don't allow using the same token ID twice when manually specifying [GH-2916]
- cli: Fix issue with parsing keys that start with special characters [GH-2998]
- core: Relocated
sys/leases/renewreturns same payload as original
- secret/ssh: Fix panic when signing with incorrect key type [GH-3072]
- secret/totp: Ensure codes can only be used once. This makes some automated workflows harder but complies with the RFC. [GH-2908]
- secret/transit: Fix locking when creating a key with unsupported options [GH-2974]
For more information on previous releases, check out the changelog on GitHub.
This package has no dependencies.
- This discussion is only about Vault and the Vault package. If you have feedback for Chocolatey, please contact the Google Group.
- This discussion will carry over multiple versions. If you have a comment about a particular version, please note that in your comments.
- The maintainers of this Chocolatey Package will be notified about new comments that are posted to this Disqus thread, however, it is NOT a guarantee that you will get a response. If you do not hear back from the maintainers after posting a message below, please follow up by using the link on the left side of this page or follow this link to contact maintainers. If you still hear nothing back, please follow the package triage process.
- Tell us what you love about the package or Vault, or tell us what needs improvement.
- Share your experiences with the package, or extra configuration or gotchas that you've found.
- If you use a url, the comment will be flagged for moderation until you've been whitelisted. Disqus moderated comments are approved on a weekly schedule if not sooner. It could take between 1-5 days for your comment to show up.