Notifications
Clear all
Topic starter
24/06/2026 11:24 pm
TL;DR: A Kubernetes dashboard used runtime-injected, policy-based access to Qase.io and Slack instead of environment variables and long-lived tokens, reducing secret handling while keeping test results and delivery signals visible each morning, according to Aembit. Static credentials are still a governance liability even when the workload is not an AI system, because scheduled non-human access behaves like an identity problem, not just an application problem.
NHIMG editorial — based on content published by Aembit: a case study on runtime workload identity for a Kubernetes dashboard
Questions worth separating out
Q: How should security teams govern scheduled workload access in Kubernetes?
A: Treat scheduled workloads as non-human identities with named owners, explicit service dependencies, and centrally governed runtime policy.
Q: Why do long-lived tokens create more risk for dashboards and automation jobs?
A: Long-lived tokens turn routine automation into reusable access that can be copied, replayed, or moved across environments.
Q: What breaks when developers keep handling secrets directly in application workflows?
A: The break is governance, not just convenience.
Practitioner guidance
- Replace embedded secrets with runtime-issued access Move service-to-service authentication for dashboards and background jobs out of environment variables and into centrally governed runtime policy.
- Classify scheduled workloads as governed identities Inventory nightly jobs, dashboards, and automation services as workload identities with named owners, explicit service dependencies, and separate access review paths from human accounts.
- Separate access validation from application debugging When a job fails, inspect the identity layer first so teams can distinguish a code defect from an authentication or authorisation failure.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- A concrete build pattern for the Kubernetes-hosted dashboard and how it was deployed through Argo CD.
- The specific way Aembit handled access to Qase.io and Slack at runtime without environment variables.
- The day-to-day developer workflow impact, including how the team avoided handling API keys directly.
- The article's implementation narrative showing how the access layer stayed separate from application logic.
👉 Read Aembit’s case study on runtime workload identity for a Kubernetes dashboard →
Kubernetes workload identity for dashboards: are your controls keeping up?
Explore further
25/06/2026 8:15 am
Runtime secret injection is now a governance control, not just a deployment convenience. This article shows why the old split between application code and access governance no longer holds for non-human workloads. When the workload can authenticate itself repeatedly to external services, credential handling becomes part of the control surface. Practitioners should treat the access path as a governed identity channel, not as an engineering shortcut.
A few things that frame the scale:
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
- 59.8% of organisations see value in a solution that simplifies non-human access management and introduces dynamic ephemeral credentials.
A question worth separating out:
Q: How do workload identity controls differ from human IAM controls?
A: Human IAM focuses on login, session, and user behaviour, while workload identity focuses on runtime access between systems. Workloads need policy-based authorisation, short-lived credentials, and ownership tied to the service rather than the person who deployed it. That is why non-human access should not be governed as a user account.
👉 Read our full editorial: Runtime workload identity controls for Kubernetes dashboards
