Blog

Polarising Website

Infrastructure First Secrets Management for UK Teams Backed by NCSC

Operator revoking a compromised credential

Secrets management centralises, controls and automates the lifecycle of credentials rather than leaving API keys, passwords and certificates scattered across code and config files. The single most important action is to adopt a KMS-backed platform that issues short-lived credentials under least privilege, then immediately scan every repository for exposed secrets, revoke anything found and switch on rotation.

TL;DR:

  • Using a centralized, KMS-backed secrets platform with short-lived credentials significantly reduces the risk of leaks, especially when enforced with automated scanning and revocation.
  • Secrets should never be stored in source control or baked into images; instead, they must be injected at runtime via volumes or in-memory agents to minimize exposure.
  • Dynamic secrets with automatic rotation, supported by external secrets operators in Kubernetes, limit the window of opportunity if credentials are leaked.
  • For multi-cloud or hybrid setups, centralize secret storage and federate access to ensure consistent audit logging and reduce operational complexity.
  • Immediate revocation of compromised secrets is critical, followed by issuing replacements and confirming no unsanctioned activity occurred during the exposure window.
Polarising
Build More Secure Connected Systems
Polarising helps enterprises integrate AI and complex systems with governance and accountability built into the architecture.

Explore Polarising

Table of Contents

What secrets management covers and why it matters

A “secret” is any credential that grants access: API keys, database passwords, TLS certificates, OAuth tokens, SSH keys and service account credentials all qualify. Each one is a target, and each one tends to leak through the same handful of routes.

  • Hardcoded values committed to source control, often in a config file nobody thought to check.
  • CI/CD logs that print environment variables during a failed build.
  • Container images that bake in credentials at build time instead of injecting them at runtime.
  • Developer laptops with cached cloud credentials or local .env files.
  • Terraform state files, which store resource attributes, including secrets, in plain text by default.

NCSC guidance on securing HTTP-based APIs recommends moving away from weak authentication such as static API keys or basic authentication, in favour of signed JWTs or certificates managed through a dedicated secrets manager or cloud KMS integration. That shift, from static values to managed, auditable credentials, is the thread running through everything that follows.

Core principles and best practices for operators

Most secrets incidents trace back to a small number of missed basics rather than exotic attacks. The following order reflects where effort pays off fastest.

  1. Enforce least privilege and role-based access control on every secret, scoped to the specific service or function that needs it, not the whole environment.
  2. Audit privileged bindings and roles on a fixed schedule, at least quarterly, and remove access that nobody has used.
  3. Prohibit secrets in source control outright and enforce it with automated secret scanning in every CI pipeline, failing builds that trip a detector.
  4. Prefer a provider-managed, KMS-backed secrets service over a self-built store wherever the platform supports it, since it gives you encryption, audit logging and access control without custom code.
  5. Keep audit logs for every secret read and write, and make rotation a scheduled, automated process rather than a manual one that only happens after an incident.
  6. Watch for anomalous access patterns and keep a rehearsed, fast revocation path ready so a compromised credential can be killed within minutes, not days.

The Home Office engineering standards on managing secrets describe this as defence-in-depth: prohibiting secrets in source control, enforcing scanning, and applying least-privilege access together, rather than relying on any single control.

Pro Tip: Treat a secret scanning alert with the same urgency as a production incident; a secret that sat in a public commit for even an hour should be assumed compromised and rotated, not just deleted from the latest revision.

Technical patterns: dynamic secrets, injection and rotation mechanics

Static, long-lived credentials are the biggest single risk in most estates, because a leak anywhere in their lifetime remains exploitable until someone notices. Dynamic secrets flip that: a vault or secrets manager issues a credential on demand with a short time-to-live, so a leaked token expires before an attacker can make much use of it. This shrinks the blast radius of a leak from “until someone rotates it” to “a few minutes”.

How a secret reaches a running workload matters just as much as how it was generated.

  • Environment variables are simple and widely supported, but they tend to leak into process dumps, crash logs and child processes.
  • Mounted volumes or files (via a CSI driver, for example) keep the secret out of the process environment and let the platform control file permissions directly.
  • In-memory agents or sidecars fetch secrets at runtime and hold them only in memory, avoiding disk or environment exposure entirely, at the cost of extra operational complexity.

Rotation is where most teams underestimate the work involved. Updating a secret in a manager does not guarantee that a running pod or process picks up the new value; according to a gov.uk infrastructure decision note on external secrets, solving this requires application logic that re-reads secrets on change, or orchestration tooling that triggers a rollout or restart. Vault-side rotation without a consumer-side refresh mechanism just creates stale credentials sitting next to valid ones.

NCSC guidance on using cloud platforms securely states that providers should offer KMS-backed protection and automated alerts for anomalous access, and that suspicious activity should trigger immediate invalidation or rotation rather than waiting for a scheduled cycle. For Kubernetes workloads specifically, the External Secrets Operator and the Secrets Store CSI Driver are the two operators worth knowing: the former reconciles cluster objects against an external secrets service, the latter mounts secrets as files without persisting them as native Kubernetes Secrets.

Platform-specific checklist: Kubernetes and cloud provider notes

Kubernetes native Secrets are base64-encoded, not encrypted, and sit in etcd where a cluster compromise can expose them wholesale. Cloud platforms have their own equivalent blind spots. A short platform checklist closes most of the gap.

  • Kubernetes: encrypt etcd at rest, never rely on native Secrets for your most sensitive material, and route high-value credentials through External Secrets Operator or the Secrets Store CSI Driver instead.
  • Cloud providers: prefer the managed secrets service over a homegrown store, use envelope encryption via the provider’s KMS, and assign workload identities so services authenticate without holding static credentials.
  • Development environments: assume a developer laptop can be compromised; require multifactor authentication and short-lived credentials for any workflow that touches production, per NCSC guidance on securing development environments.

The Home Office standards frame all of this as lifecycle control: minimise how many persistent copies of a secret exist, mount via CSI drivers where you can, and use workload identity so applications never hold a long-term credential in the first place.

How to evaluate and choose a secrets management approach

Choosing between a managed service and a self-hosted vault comes down to a short set of questions, asked in roughly this order.

  1. Does the deployment model fit your estate: a single cloud provider, multi-cloud, or a mix of cloud and on-premises systems?
  2. Does it support dynamic, short-lived secrets natively, or only static storage with manual rotation?
  3. What does the audit trail look like: can you see every read and write, and does it integrate with your existing logging stack?
  4. How automated is rotation, and does it include a mechanism for notifying or restarting consumers?
  5. How cleanly does it integrate with your CI/CD pipelines and orchestration layer, Kubernetes included?

A managed service generally costs less in engineering time and comes with KMS integration out of the box, at the price of being tied to that provider’s ecosystem. A self-hosted vault gives more control across heterogeneous environments but demands real operational investment to run well. Treat missing audit logs, no rotation support or a fragile, manual injection process as disqualifying red flags regardless of which model you pick.

Practitioner perspective: operationalising secrets management in complex estates

Tooling solves half the problem; governance solves the rest. Enterprise estates need documented secret lifecycles, incident playbooks and runbooks that specify who can request, approve and revoke a credential. The pattern that scales best splits ownership cleanly: a platform team runs the secrets infrastructure itself, while service teams request and consume credentials through a defined interface rather than touching the vault directly. We have applied this split-ownership model across integration-heavy engagements where credential sprawl, not a single weak control, was the real risk.

Handling secrets in multi-cloud or hybrid environments

Multi-cloud and hybrid estates multiply the number of places a secret can live: one cloud provider’s KMS, another’s native secrets service, an on-premises vault, and whatever a legacy system still expects in a flat file. The practical fix is not to force every platform onto one vendor’s tool, but to pick a single source of truth and federate access to it.

Central vault federating access across environments

A central vault or secrets manager, synced outward to each platform’s native integration, tends to work better than trying to run the same tool identically everywhere. On Kubernetes, the External Secrets Operator can reconcile cluster secrets against that central store regardless of which cloud the cluster runs in, which keeps the operational pattern consistent even when the underlying infrastructure is not. The same principle applies to on-premises systems bridging into cloud workloads: those systems should request short-lived credentials from the central store rather than holding long-lived ones locally just because they sit outside the cloud boundary.

Identity federation matters as much as the vault itself. Workload identity federation lets a service in one cloud authenticate to a secrets store in another without a static cross-cloud credential ever existing, which removes one of the highest-value targets an attacker could find. Hybrid estates that skip this step usually end up with a long-lived service account key copied between environments, exactly the kind of credential that dynamic secrets and short TTLs are meant to eliminate.

Audit logging needs the same federation treatment: if each platform logs access separately with no shared format or timeline, correlating a suspicious access pattern across clouds during an incident becomes guesswork. Centralising the audit trail, even if the secrets themselves stay distributed across providers, is usually the difference between a fast investigation and a slow one.

Incident response and remediation when secrets are exposed

The first action after discovering an exposed secret is revocation, not rotation: kill the credential’s ability to authenticate before worrying about issuing a replacement. A rotated secret that coexists with a still-valid leaked one buys an attacker nothing less.

NCSC guidance on securing the build and deployment pipeline ties secrets exposure directly to supply chain risk: machine and service credentials need monitoring for anomalous use precisely because a leaked one can be the entry point for a vendor or pipeline compromise rather than a direct attack on your own systems. Treat a leaked CI token with the same seriousness as a leaked production database password.

A workable remediation sequence looks like this: revoke the exposed credential immediately, identify every system or service that consumed it, issue replacement credentials through your normal managed flow, and only then investigate how and when the leak happened. Rehearsing this sequence before an incident matters more than most teams assume. NCSC’s guidance on identifying suspicious credential usage recommends pairing RBAC audits with anomaly alerting and rehearsing the workflow so a team can revoke and reissue secrets with minimal downtime, rather than improvising under pressure.

Four-step exposed credential remediation sequence

Recovery planning extends beyond the secret itself. Once access is restored, check whether the exposure window allowed any unauthorised changes to data or infrastructure, since a compromised credential that sat valid for days may have been used for more than reading values. Backup and recovery practices that cover ransomware and data-loss scenarios are worth reviewing alongside secrets incident response, since both rely on the same underlying discipline of knowing exactly what state to restore to; Courimo’s website backup strategy guide covers this from the resilience-planning side.

Common mistakes, realistic priorities and a short roadmap

Most teams chase rotation automation before fixing the basics. Triage in this order: eliminate secrets from source control and turn on scanning first, then add rotation for your highest-value credentials, not every credential at once. Avoid building features you cannot measure. Audit access quarterly and actually rehearse your incident response for a leaked secret before you need it.

— Polarising Team

How Polarising can help you implement this

Secrets management rarely fails on tooling choice. It fails on the integration work between the vault, the pipeline and the applications that need to consume credentials without manual intervention, and that is where most engineering time disappears. We bring senior nearshore engineering teams to exactly that kind of work, including in regulated sectors such as finance, healthcare and telecommunications.

Polarising

A few engagement shapes tend to fit this problem well:

  • A short assessment of your current secret sprawl, leak vectors and rotation gaps across cloud and on-premises systems.
  • Runbook and incident playbook development so revocation and reissue are rehearsed processes, not improvised ones.
  • Hands-on integration work connecting your KMS, orchestration layer and CI/CD pipelines so rotation actually reaches running services.

If you need hands-on delivery rather than another internal backlog item, our enterprise integration services page is the right place to start a conversation.

FAQ

What does “secrets management” mean?

Secrets management is the practice of centrally storing, controlling access to and automating the lifecycle of credentials such as API keys, passwords, certificates and tokens. It covers generation, rotation, injection into runtimes, and revocation, rather than leaving credentials scattered across code, config files and tickets.

How much does Secrets Manager cost per month?

Pricing for managed secrets services varies by provider and is set directly by each cloud vendor, so check the specific provider’s current pricing page for an exact figure. We have not listed a figure here because none of our sources states one that holds across providers.

Which secrets management tool is the best?

There is no single best tool; the right choice depends on whether your estate is single-cloud, multi-cloud or hybrid, and whether you need dynamic secrets, deep Kubernetes integration or a fully managed service. Evaluate any candidate against audit logging, rotation automation and how cleanly it injects secrets into your runtimes before comparing price.

How do I access Google Secret Manager?

Access to a cloud provider’s secret manager is granted through that provider’s own identity and access management system, typically scoped to a specific service account or workload identity rather than a shared credential. Check the specific provider’s documentation for the exact console, CLI or API steps, since these change over time.

Sources