1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
//! HashiCorp Vault KV v2 secret resolution — `vault://path#field`.
//!
//! `path` is the logical KV v2 path exactly as used by `vault kv get path`
//! (e.g. `secret/myapp/db`) — the first path segment is the mount name, and
//! `data/` is inserted right after it to build the actual HTTP API path
//! (`/v1/secret/data/myapp/db`), matching the same convention the Vault CLI
//! itself applies so users don't have to think in terms of the KV v2 API's
//! own path shape.
//!
//! Configured via the same environment variables the official `vault` CLI
//! and client libraries use, so an already-Vault-integrated environment
//! needs no new variables:
//! - `VAULT_ADDR` — defaults to `http://127.0.0.1:8200` (the Vault CLI's own
//! default, e.g. a local dev server or an in-cluster Vault Agent sidecar).
//! - `VAULT_TOKEN` — required, no default.
//!
//! Only token auth is implemented (a static `X-Vault-Token` header) — no
//! AppRole, Kubernetes auth, or token renewal. A short-lived token from one
//! of those methods can still be placed directly in `VAULT_TOKEN` by
//! whatever process starts `rws`.
use SecretsError;
use crateClient;
use crate;
pub