Skip to content

BaseHarbor v0.4.5

Choose a tag to compare

View all tags
@github-actions github-actions released this 19 Sep 07:34
· 601 commits to main since this release
v0.4.5
3e18f4c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

BaseHarbor v0.4.5

BaseHarbor v0.4.5 adds a shared secure-binding and workload-identity foundation for capability providers.

Why this matters

BaseHarbor already had strong security primitives in the Compose/OpenBao path: application-scoped OpenBao access, a runtime broker, mTLS, protected binding files, required/generated secrets, identity rotation and revocation behavior.

Until now, those pieces existed mainly as implementation-specific runtime behavior. v0.4.5 extracts the stable security semantics into the shared capability/provider domain so later SQL, S3, messaging, vector, AI and MCP providers do not each invent their own credential and trust plumbing.

Added

  • secure-binding/v1, a provider-neutral binding specification for workload identity, credential references, trust material, authorization metadata, secret references and security lifecycle declarations.
  • Secure binding metadata on the shared capability Binding model used below CLI-specific code.
  • SPIFFE workload identity mapping for the existing Compose/OpenBao runtime identity: spiffe://baseharbor/apps/<application>/<environment>.
  • Machine-readable security diagnostics and explicit renewal/rotation/revocation support declarations.
  • WorkloadBinding.security in baseharbor.provider/v1 so future external gRPC/Protocol Buffer providers consume the same security model.

Changed

  • Managed secrets/v1 bindings now expose their existing identity, trust, authorization and required-secret semantics through provider-neutral references.
  • Secure binding validation now happens during plan construction, before provider preflight and before any mutation.
  • Credential, trust and secret references must be opaque baseharbor:// references; credential-bearing URLs and plaintext values are not valid binding references.

Security

  • OpenBao AppRole names, RoleIDs, SecretIDs, policies, KV paths and PKI internals remain provider state.
  • Tokens, passwords, private keys and secret values do not enter the secure-binding model, provider diagnostics or portable application intent.
  • Application and environment identity remain isolated; different applications/environments receive distinct logical identity and credential references.
  • Shared provider infrastructure does not imply shared authorization.
  • Least-privilege authorization metadata is explicit and currently maps managed-secret workloads to read-only secret consumption.

Compatibility

  • Manifest version remains 1 and no new application-facing security fields are required.
  • Existing OpenBao, runtime-broker, mTLS, required/generated-secret and restore behavior remains authoritative and compatible.
  • Compose remains the complete current runtime provider.
  • Existing v0.4.4 exposure behavior is unchanged.

Intentionally deferred

  • Human login, OIDC, RBAC, MFA, JIT elevation and breakglass remain v0.6 work.
  • Full cross-provider zero-downtime credential/certificate rotation remains tracked separately.
  • Managed public certificate issuance/renewal remains outside this release.
  • A dynamic external provider loader is still not introduced.
Assets 5
Loading