Notifications
Clear all
Topic starter
17/08/2026 4:41 pm
TL;DR: Platform engineering improves developer self-service, but it also concentrates secrets, credentials, and access paths across GitHub Actions, Kubernetes, Argo CD, and internal portals, according to Akeyless. The real security question is no longer whether teams can move faster, but whether they can govern short-lived and long-lived credentials without creating new NHI exposure windows.
NHIMG editorial — based on content published by Akeyless: Introduction to Platform Engineering
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams implement dynamic secrets in platform engineering workflows?
A: Start by tying secret issuance to workload or pipeline identity, then limit the credential to the shortest practical task window.
Q: Why do CI/CD runners and build tools increase NHI risk?
A: They often hold cloud tokens, publishing credentials, SSH keys, and database secrets that behave like non-human identities.
Q: What breaks when secret zero is stored in code or pipeline variables?
A: The entire bootstrap chain becomes recoverable by anyone who can read the repository, job logs, or pipeline configuration.
Practitioner guidance
- Map the bootstrap trust chain Document how GitHub Actions, Kubernetes, Argo CD, and any portal authenticate before they can request secrets, then eliminate static secret zero paths where a federated identity can replace them.
- Classify every platform identity by lifecycle Separate human users, pipeline identities, service accounts, and workload credentials, then assign ownership for creation, renewal, and revocation to the right control owner.
- Bind secret TTLs to runtime need Set secret expiry to match the actual duration of jobs and application sessions, and verify that expired credentials fail safely without forcing teams to reuse longer-lived values.
What's in the full article
Akeyless's full blog post covers the operational detail this post intentionally leaves for the source:
- GitHub Actions pipeline steps for creating repositories, namespaces, and deployment wiring.
- Demo-specific configuration for Port, Argo CD, and Kubernetes integration across the workflow.
- A look at how the platform handles dynamic MySQL credential issuance during application runtime.
- Implementation notes for JWT-based secret zero handling in GitHub and Kubernetes auth flows.
👉 Read Akeyless's blog post on platform engineering and secrets management →
Secrets management in platform engineering: are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:46 pm
Platform engineering has become an NHI governance domain, not just a delivery architecture. Once GitHub Actions, Kubernetes, and deployment orchestration begin handling reusable credentials, the platform itself becomes part of the identity attack surface. That means IAM, PAM, and lifecycle controls must extend into the software delivery path, not sit beside it. Practitioners should treat platform engineering as governed identity infrastructure, not merely developer tooling.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably account for the identities embedded in platform workflows.
A question worth separating out:
Q: Who should own offboarding for platform identities and secrets?
A: Ownership should sit with the team that governs the underlying identity, not just the application team. Pipeline identities, workload credentials, and portal access all need explicit revocation paths so access does not outlive the system or project that created it. Without lifecycle ownership, platform automation becomes permanent privilege.
👉 Read our full editorial: Platform engineering needs stronger secrets governance for CI/CD workflows
