Kratix Promises and Secret Managers: A Great 'AND' Story
- Christopher Hedley
- 4h
- 3 min read
Platform engineering is full of trade-offs. Cost, speed, or reduced risk. Developer autonomy or governance and compliance. We hear it all the time: “We can’t have both.” But that’s not true. When you combine Kratix Promises with a Secrets Manager, you get both.
This isn’t an either / or story. It’s a great AND story that brings together your developer experience and enterprise-grade security.
Promises define the platform
Kratix Promises are how platform teams describe and deliver what they offer to their users.
A Promise defines what a developer can ask for: a database, a message queue, an environment, and what they’ll receive in return. It’s a clear, reusable contract between the platform and its users.
Promise contracts replace tribal knowledge and ticket queues with something better: a repeatable, transparent interface that anyone can use. Developers get self-service and faster delivery. Platform teams gain consistency, reliability, and control.
When Promises become the foundation of your platform, delivery gets easier and safer. You stop firefighting and start operating with confidence, knowing every service request follows the same
Secret Managers secure the foundation
Every platform needs to handle secrets: credentials, tokens, keys, and no-one wants to get that wrong. Secret managers such as HashiCorp Vault, Google Cloud Secret Manager, and AWS Secrets Manager, and Azure Key Vault are tools that handle this critical job. They generate credentials, rotate and revoke them, and enforce who has access and when. Instead of insecurely scattering passwords and tokens across pipelines and repos, everything flows through a single, trusted system.
These tools bring structure and policy to an area that’s often an afterthought. Whether you’re running Vault in your cluster, using a managed service from Google, AWS or Microsoft, or a mix of both, a Secret Manager gives your platform a secure backbone and your teams a clear boundary of responsibility.
Promise installation: Creates a Vault policy defining allowed paths and capabilities (read, write, etc.). Kratix then requests Vault to issue a scoped token bound to this policy, ensuring the Promise operates with least privilege. This avoids reusing global or root tokens and ensures each Promise operates with the principle of least privilege.

User requests a Promise instance (e.g. “Datab
ase”): Creates a Vault role and associated token policy.Kratix provisions the resource (e.g. database) and creates a database superuser credential with the required permissions to generate application-specific users and tokens. If Vault’s database secrets engine is used, Vault securely connects to the target database to generate these credentials

Applications and Secret delivery: An authentication token is injected into the Destination cluster via application-scoped Kubernetes ServiceAccounts. The Kubernetes auth method maps the ServiceAccount identity to the corresponding Vault role, granting scoped access to the relevant secret paths. The application authenticates using Vault’s Kubernetes auth method, typically through a Vault Agent, CSI driver, or framework integration (e.g. Spring Vault). It retrieves the secrets directly from Vault, short-lived and automatically rotated, without embedding credentials into insecure configs or manifests.
Resource deletion and cleanup: Kratix triggers secret revocation. Vault invalidates the lease, removes dynamic credentials (e.g. database users), and deletes any associated tokens or roles. When the Promise is deleted, Kratix cleans up the Vault policy and token, removing all related artefacts.
Developers never see the secrets. Platform teams keep visibility and control. Security teams don’t have to choose between compliance and speed. It’s autonomy and safety. Velocity and governance. Freedom and control.
Platform Orchestration == Security Orchestration
Kratix Promises and Secret Managers work seamlessly together. A Promise defines what to deliver, and a Secret Manager defines how to deliver it securely.
Take a “Database” Promise as an example. In this case, Kratix deploys a dedicated database instance for the developer or team that requested it. Each instance is created with its own isolated credentials, managed through the organisation’s chosen Secret Manager. This approach gives every user their own secured database, governed by consistent policies and automated workflows, without manual setup or credential handling.
Aligned lifecycles
Kratix and Secret Managers align naturally because both manage lifecycles. A Promise manages the lifecycle of a service: creation, update, deletion. A Secret Manager manages the lifecycle of credentials: issuance, rotation, revocation When these lifecycles move together, you don’t just automate provisioning, you deliver trust. Every change to a resource can trigger a corresponding update to its credentials reducing attack surface area. That’s how platforms become secure by default, not secure by enforcement.
Benefits for platform teams
Reduced risk surface: Secrets are short-lived, traceable, and never exposed to end users or pipelines.
Consistent policy enforcement: Access controls and credential lifecycles are managed by code, not convention, ensuring consistent application across teams and environments.
Improved compliance: Every credential issuance, rotation, and revocation is logged and auditable. Proving compliance becomes part of normal operations, not a separate process.
Operational resilience: Integrated lifecycles and automation reduce dependency on individual knowledge and manual steps—strengthening both security and reliability.


Comments