All notable changes to this project will be documented in this file. This change log follows the conventions of keepachangelog.com.
...
This release contains a number of potentially breaking changes, though they should only require minor updates.
vault.client/config-wrapped-client
has been changed slightly and is now
vault.client/authenticate-wrapped!
, which acts on an existing client
instead of constructing one.kv.v1
and kv.v2
secret engines attach metadata to :not-found
values
if they support metadata, similar to normal responses.vault.client/config-client
accepts options for configuring the Vault
client, as in new-client
.vault.util/sha-256
function.This is a major release which completely rewrites the library code. New
releases will be under the com.amperity/vault-clj
coordinate. See the
Upgrading from 1.x document for details on the changes.
:wrap-info
payload when creating tokens with a
wrapper.create-orphan-token!
method to support the
/auth/token/create-orphan
endpoint.
#61cljstyle
and clj-kondo
for style and linting.THIS RELEASE CONTAINS SOME BREAKING CHANGES!
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, Daniel Rassaby & Chuck SakodaEdit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close