Skip to content

Introduction to Secrets Management

Secrets management is the practice of securely storing, controlling access to, and delivering sensitive credentials — such as API keys, database passwords, service tokens, and configuration values — to the systems and applications that need them. Without a centralised secrets management solution, credentials are frequently embedded in source code, stored in configuration files, or shared informally, creating significant security and operational risk.

The Zaita platform provides a built-in secrets management capability that integrates natively with its existing identity, access control, and cryptographic infrastructure. Secrets are stored encrypted in the platform's Secured Back Control Plane, delivered to applications via encrypted channels, and protected by the same ECDH + AES-256-GCM cryptographic model used throughout the platform. Plaintext secret values never traverse the network and are never stored unencrypted.

Core Concepts

Vault

A Vault is the top-level secrets container for your organisation. Each tenant has exactly one Vault. The Vault is initialised automatically and acts as the namespace within which all Lockers and Secrets are managed.

Locker

A Locker is a named collection of secrets within your Vault. Lockers are used to organise secrets by application, environment, team, or any grouping that makes sense for your organisation. Each Locker has its own access control list, allowing you to grant specific Couriers, Bridges, and Workloads access on a per-Locker basis.

Examples of how organisations typically structure Lockers:

Locker Name Purpose
production-api API keys and tokens for the production API layer
database-credentials Database usernames and passwords per environment
ci-cd-tokens Tokens used by CI/CD pipelines
monitoring-integrations Keys for external monitoring and observability platforms

Secret

A Secret is a single name/value pair stored within a Locker. Each Secret has a name, an optional description, and an encrypted value. The platform stores only the encrypted ciphertext — the Secured Back Control Plane holds the keys required to decrypt and re-encrypt secrets for delivery.

Encryption Model

All secrets are protected end-to-end using ECDH (Elliptic Curve Diffie-Hellman) key exchange over EC P-521 curves, with AES-256-GCM symmetric encryption. The key properties of this model are:

  • Secrets at rest — stored in the Secured Back Control Plane as AES-256-GCM ciphertext. The FCP (web portal and API layer) never holds plaintext values.
  • Secrets in transit — the protection applied depends on the delivery method. Couriers and Bridges provide an EC P-521 public key with each request; the BCP performs ECDH key exchange and re-encrypts the secrets bundle so that only the requesting party can decrypt it. Workloads retrieve secrets as plaintext JSON over a mutually-authenticated TLS connection — the TLS channel provides confidentiality and integrity without an additional encryption layer.
  • Forward secrecy — because a fresh ephemeral key pair is generated per delivery, compromise of one delivery bundle does not expose others.
  • Memory safety — in Bridge deployments, secret values are held in memory using zeroing-on-drop primitives, ensuring secrets are not recoverable from process memory dumps after use.

For a full description of the Secured Back Control Plane and its cryptographic guarantees, see Architecture.

Delivery Methods

Zaita supports four ways to deliver secrets from your Vault to consuming systems:

Courier

A Courier is a lightweight command-line utility that authenticates with the platform and downloads a Locker's secrets to a local file. Couriers are suitable for:

  • Applications that read secrets from environment files at startup
  • Systems managed by cron jobs or configuration management tooling
  • CI/CD pipelines that need secrets injected at build or deploy time

The Courier generates an ephemeral key pair, sends the public key to the platform, and receives an encrypted secrets bundle it decrypts locally. The output is written as a .env file or JSON object with mode 0600.

See Delivering Secrets with Couriers.

Bridge

A Bridge is a persistent on-premises agent that caches assigned Lockers in memory and makes them available to local systems without requiring direct connectivity to the Zaita platform. Bridges are suitable for:

  • High-availability environments where secrets must be available even if connectivity to the platform is interrupted
  • On-premises deployments where latency to the platform may be a concern
  • Environments where secrets are consumed by many local processes

The Bridge receives encrypted Locker bundles from the platform and decrypts them using its own rotating key. The cache is refreshed automatically when the platform signals that Locker contents have changed.

See Caching Secrets on Bridges.

Workload

A Workload is a registered application or service that authenticates directly with the platform's API to access secrets. Workloads support modern, credential-less authentication methods and are suitable for:

  • Cloud-native applications running in Azure, AWS, or Kubernetes
  • Services with SPIFFE/SPIRE-based identity
  • Applications that need to access secrets dynamically at runtime

See Workloads.

Service Account API

Service Accounts can be granted programmatic access to manage Lockers and Secrets via the REST API. This is the primary path for secrets rotation — Zaita does not generate new values automatically; rotation is driven externally and the updated value is stored via the API. This delivery path is suitable for:

  • Automation scripts that create or rotate secrets
  • Configuration management tooling such as Ansible, Puppet, or Chef
  • Infrastructure-as-code tooling such as Terraform
  • Custom integrations that need to manage secrets programmatically

See Service Account API.

Access Control

Access to each Locker is controlled independently. Couriers, Bridges, and Workloads must be explicitly granted access to a Locker before they can download secrets from it. Access grants are managed through the Locker's access control panel in the web portal, or via the Service Account API.

This per-Locker, per-entity access model ensures that:

  • A Courier can only access the Lockers it needs for its specific workload.
  • A Bridge caches only the Lockers assigned to it.
  • A Workload can only read secrets from Lockers its administrator has approved.

Audit Logging

All secrets management operations generate audit log entries. This includes Locker and Secret creation and deletion, access grants and revocations, and every download attempt — whether successful, failed, or unauthorised. Audit logs are accessible under Admin → Audit Log to users with the appropriate role.

Next Steps