All notable changes to this project will be documented in this file. This change log follows the conventions of keepachangelog.com.
...
clj-http to 3.7.0.digest library.digest instead of transitive apache lib for hashing.
362f1abVAULT_WRAP_TOKEN.VAULT_ROLE_ID and VAULT_SECRET_ID.read-secret method supports a :force-read flag which will ignore valid
leases and always re-read the path.
#22read-secret method now returns the response body on 200 status codes
to plumb through important information. 204 writes still return true.
#17
#18:type :vault.client.http/api-error
in their ex-data.:http-opts property which will be
merged into the clj-http requests to the Vault server. This provides a way
to set custom timeouts, TLS settings, and more.
#10read-secret method supports a :not-found option which will be returned
if set and a secret path is not present. Otherwise, clients consistently throw
exceptions. #7:revoke-on-stop? option to control
the outstanding lease revocation.THIS RELEASE CONTAINS BREAKING CHANGES!
Most of the code in the library has been refactored and rewritten with the goal of providing a more fully-featured client for the Vault API. The HTTP client is now a proper system component which manages a background thread to track, renew, and rotate leased secrets. This enables the usage of dynamic secret backends like AWS, PostgreSQL, and more!
Additionally, the mock client implementation has been enhanced to implement most of the API methods and provides a URL-based constructor to load mock secret data in at runtime. This makes testing code without a Vault instance much simpler.
amperity/envoy to define the environment variables used by the
environment-based client constructor.HTTPClient record implements the Lifecycle protocol from the
component library to manage an internal lease maintenance thread.vault.core/new-client multimethod which constructs a client based
on the given URI scheme. This makes environment-driven construction simpler.vault.env/config-client constructor which builds a client based on
the VAULT_ADDR config and authenticates it based on the available
credentials. Currently supports VAULT_TOKEN and
VAULT_APP_ID/VAULT_USER_ID.vault.cache namespace renamed to vault.lease, significant functionality
added for dealing with lease information.vault.client namespace renamed to vault.core, with the single Client
protocol split into a number of more focused protocols.vault.client.mock and
vault.client.http.clj-http to the stable 2.3.0 version to simplify dependency
management.vault.env/init-app-client constructor.create-token! API support in the Client protocol. Tokens can be returned
as wrapped responses.unwrap! API support in the Client protocol.vault.env/init-app-client uses VAULT_ADDR as the primary configuration
variable, falling back to VAULT_URL for compatibility.307 redirects from clustered Vault instances will be followed up to two
times in order to connect to the correct master node.delete-secret! API support in the Client protocol.memory-client returns a mock in-memory client implementation for testing.vault.cache namespace.With this version, the project has been forked to the Amperity organization.
authenticate! now supports the
userpass auth backend.write-secret! protocol method.vault.env/load! function. This
takes a map of env vars with some potential secret values as Vault paths.
Listed variables of the form vault:<path> are resolved as secret values.authenticate! takes an auth-type keyword and a map of credentials now
instead of only supporting the :app-id auth type.:token and credentials of the
token string.Can you improve this documentation? These fine people already did:
Greg Look, Colin Lappala & Chuck SakodaEdit on GitHub
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |