bao-kms-providerSearch GitHub

Security

These pages cover trust boundaries, authentication, hardening, and the security view of decrypt validation. Use them when the question is about scope, trust, or a sensitive failure mode rather than a workflow step.

The security section documents the intended hardened posture for bao-kms-provider. For the current maturity statement see Reference: Support Policy , and for artifact verification see Getting Started: Install .

Topics

  • Threat Model for in-scope and out-of-scope threats, attacker capabilities, and mitigations.
  • Hardening for runtime hardening of the provider process under systemd and as a static pod.
  • Auth Model for JWT and certificate authentication, token lifecycle, and the rationale for avoiding a Kubernetes API circular dependency.
  • AAD And Decrypt Validation for the security view of how the provider rejects stale, unknown, or annotation-inconsistent ciphertexts.

Use Another Section If

  • the question is about CLI, config, or KMS v2 protocol behavior: go to Reference .
  • the question is about an operational runbook or incident response: go to Operations .
  • the question is about how the design satisfies these properties: go to Architecture .

Browse

In This Section

Threat Model Assets, trust boundaries, attacker capabilities, threats and controls, security properties provided and not provided by bao-kms-provider. Hardening Required and recommended hardening for bao-kms-provider deployments: OpenBao, plugin host, file permissions, auth material, logging, metrics, and Kubernetes-side. Auth Model Authentication design for bao-kms-provider: JWT auth, certificate auth, token lifecycle, role constraints, local validation, and renewal considerations. AAD And Decrypt Validation What Transit associated_data binds, how decrypt validation rejects unknown or tampered ciphertext, and which compatibility-mode actions are unsafe.