Struct SecretsConfig 

#[non_exhaustive]
pub struct SecretsConfig {

    pub backend: Option<SecretBackend>,
    pub seed: Option<String>,
    pub aws_secret_name: Option<String>,
    pub aws_region: Option<String>,
    pub gcp_project: Option<String>,
    pub gcp_secret_name: Option<String>,
    pub azure_vault_url: Option<String>,
    pub azure_secret_name: Option<String>,
    pub keyring_service: String,
    pub vault_addr: Option<String>,
    pub vault_kv_mount: String,
    pub vault_secret_path: Option<String>,
    pub vault_secret_key: String,
    pub vault_namespace: Option<String>,
    pub vault_auth_method: String,
    pub vault_k8s_role: Option<String>,
    pub vault_k8s_mount: String,
    pub vault_k8s_jwt_path: String,
    pub vault_token: Option<String>,
    pub vault_approle_role_id: Option<String>,
    pub vault_approle_secret_id: Option<String>,
    pub vault_approle_mount: String,
    pub vault_skip_verify: bool,
    pub k8s_secret_name: Option<String>,
    pub k8s_namespace: Option<String>,
    pub k8s_secret_key: String,
    pub allow_plaintext: bool,
    pub cache_ttl_secs: u64,
}

#[non_exhaustive]: this struct has grown a field per backend since it was introduced and will keep growing. Marking it here makes a future field an additive change rather than a breaking one — at the cost of forbidding struct-literal (and functional-update) construction outside this crate. Build one with SecretsConfig::default and assign the fields you need.

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

backend: Option<SecretBackend>

Explicit backend selector. When set it wins outright: create_seed_store builds exactly this backend and validates its required fields, rather than inferring the backend from whichever selector field happens to be populated.

Omit to keep the legacy implicit priority chain. Setting it is the only way to reach a backend that sits below a compiled-in one in that chain — plaintext in particular is unreachable implicitly on any build with keyring compiled in (the default), because the keyring arm matches unconditionally.

seed: Option<String>

Hex-encoded BIP-32 seed (config-seed feature)

aws_secret_name: Option<String>

AWS Secrets Manager secret name (aws-secrets feature)

aws_region: Option<String>

AWS region override (aws-secrets feature)

gcp_project: Option<String>

GCP project ID (gcp-secrets feature)

gcp_secret_name: Option<String>

GCP secret name (gcp-secrets feature)

azure_vault_url: Option<String>

Azure Key Vault URL (azure-secrets feature)

azure_secret_name: Option<String>

Azure Key Vault secret name (azure-secrets feature)

keyring_service: String

OS keyring service name (keyring feature). Change this to run multiple VTA instances on the same machine.

vault_addr: Option<String>

HashiCorp Vault server URL (vault-secrets feature). Setting this activates the Vault backend.

vault_kv_mount: String

KV v2 mount path (vault-secrets feature). Default secret.

vault_secret_path: Option<String>

KV v2 secret path under the mount, e.g. vta/master-seed (vault-secrets feature).

vault_secret_key: String

Field name within the KV v2 secret that holds the hex-encoded seed (vault-secrets feature). Default seed.

vault_namespace: Option<String>

Vault Enterprise namespace, if any (vault-secrets feature).

vault_auth_method: String

Auth method: kubernetes (default), token, or approle (vault-secrets feature).

vault_k8s_role: Option<String>

Kubernetes auth role name (vault-secrets feature, kubernetes auth method).

vault_k8s_mount: String

Kubernetes auth mount path (vault-secrets feature). Default kubernetes.

vault_k8s_jwt_path: String

File holding the ServiceAccount JWT presented to Vault (vault-secrets feature, kubernetes auth method). Default is the kubelet-mounted projected volume path.

vault_token: Option<String>

Static token (vault-secrets feature, token auth method). Prefer the VAULT_TOKEN env var over hard-coding here.

vault_approle_role_id: Option<String>

AppRole role_id (vault-secrets feature, approle auth method).

vault_approle_secret_id: Option<String>

AppRole secret_id (vault-secrets feature, approle auth method).

vault_approle_mount: String

AppRole mount path (vault-secrets feature). Default approle.

vault_skip_verify: bool

Skip TLS certificate verification — dev/test only (vault-secrets feature).

k8s_secret_name: Option<String>

Kubernetes Secret name holding the hex-encoded seed (k8s-secrets feature). Setting this activates the Kubernetes backend.

k8s_namespace: Option<String>

Kubernetes namespace the Secret lives in (k8s-secrets feature). When unset, the in-cluster ServiceAccount namespace (or the kubeconfig context namespace) is used, falling back to default.

k8s_secret_key: String

Key within the Secret’s data map that holds the hex-encoded seed (k8s-secrets feature). Default seed.

allow_plaintext: bool

Opt in to the plaintext file seed-store fallback. Off by default: when no secure backend (keyring / cloud / Vault / config-seed) is compiled-in and configured, create_seed_store errors rather than silently writing the BIP-32 master seed to a file in clear. Set true only for dev/test where that is acceptable. (P0.9 — closes the “one wrong TOML key → master seed on disk in cleartext” footgun.)

cache_ttl_secs: u64

How long a successfully-read seed may be reused from memory before the backend is consulted again, in seconds. 0 disables caching entirely — every read hits the backend, which is how this crate behaved before the cache existed.

Why this exists: the seed is read on every key-touching request (load_seed_bytes, ~25 call sites, including every signature), and on the cloud backends each read is a remote call — for AWS one GetSecretValue, which is in turn one billed KMS Decrypt. Uncached, KMS request volume scales with request volume; cached, it scales with wall-clock time.

Why a bounded TTL rather than load-once: the seed for a generation is immutable, and the only writer is in-process rotation (which invalidates the cache explicitly), so a stale read is already near-impossible. The TTL is the outer bound for anything that gets past that, and it caps how long the master seed sits resident in process memory (P0.7).

Trait Implementations

impl Clone for SecretsConfig

fn clone(&self) -> SecretsConfig

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for SecretsConfig

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for SecretsConfig

fn default() -> Self

Returns the “default value” for a type.

impl<'de> Deserialize<'de> for SecretsConfig

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Serialize for SecretsConfig

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.