Notifications
Clear all
Topic starter
12/06/2026 9:36 pm
TL;DR: Containerization improves portability and density, but its shared-kernel model shifts security risk into images, registries, orchestration, and runtime settings, according to Orca Security. For IAM and platform teams, the governance challenge is to control workload identity, RBAC, secrets, and admission policy as one operating model, not as separate checklists.
NHIMG editorial — based on content published by Orca Security: Containerization Security: Risks and Strategies
Questions worth separating out
Q: How should security teams govern container workloads with Kubernetes RBAC?
A: Treat Kubernetes RBAC as workload identity governance, not just cluster administration.
Q: Why do containers create more lateral movement risk when secrets are poorly handled?
A: Containers commonly expose credentials through environment variables, mounted files, and attached service identities.
Q: What breaks when container admission controls are missing?
A: Without admission controls, risky workloads can run with privileged mode, host mounts, weak security contexts, or unreviewed image provenance.
Practitioner guidance
- Map container workloads to explicit workload identities Inventory which service accounts, tokens, API keys, and certificates each workload uses, then assign scope by namespace, service, and environment so no container inherits broader access than it needs.
- Block risky container settings before deployment Use admission controls to reject privileged containers, hostPath mounts, Docker socket mounts, and security contexts that allow unnecessary kernel or node access.
- Review Kubernetes RBAC as an access governance control Audit who can create pods, modify secrets, and bind cluster-admin roles, then remove permissions that are convenient for operations but unnecessary for workload delivery.
What's in the full article
Orca Security's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step comparison of Docker, LXC, Windows containers, and Kubernetes for security planning
- Practical examples of how namespaces, cgroups, seccomp, AppArmor, and SELinux change runtime isolation
- Detailed container security best practices covering base images, scanning, admission policy, and host hardening
- The article's own explanations of hybrid and multi-cloud container deployment tradeoffs
👉 Read Orca Security's full guide to containerization security risks and strategies →
Container security and RBAC gaps: what practitioners are missing?
Explore further
12/06/2026 11:48 pm
Container security is now an identity governance problem, not just a platform-hardening problem. The article is right to frame images, registries, orchestration, and host settings as a single attack surface. In practice, the most dangerous failures are permission failures: who can deploy, what the workload can reach, and which secrets it inherits. Practitioners should govern containers as an identity-bound workload model, not as a packaging format.
A few things that frame the scale:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: Which frameworks should teams use to govern container security risk?
A: NIST SP 800-190 and the CIS Kubernetes Benchmark are the clearest starting points for container governance. Use them to structure controls across image scanning, RBAC, admission policy, and host hardening, then tie those controls back to your broader identity and access programme so workload permissions are not managed in isolation.
👉 Read our full editorial: Containerization security risks: what IAM teams need to know
