This article is based on research from the Cloud Security Alliance presented at RSA Conference 2020 in San Francisco, as reported by BankInfoSecurity.
The Security Gap That Containers and Kubernetes Are Creating
The rapid adoption of containers and orchestration platforms like Kubernetes is outpacing the security practices designed to protect them. According to research from the Cloud Security Alliance (CSA) presented at RSA Conference 2020, development and operations teams are deploying containerized workloads at scale — but many organizations have not yet adapted their security models to match the complexity this creates.
John Yeoh, Global Vice President of Research at the CSA, summed up the core tension: segmenting applications into containers and microservices delivers clear functional and scalability benefits, but it simultaneously multiplies the number of components that must be secured and made compliant.
“As we have seen with the use of containers and micro-services and compliance, when you further segment things off, there’s a functionality benefit from that. But you also have a lot more pieces to secure or to make compliant. So the challenge is how do we grant proper access control to containers and micro-services? How do we make these environments compliant?”
— John Yeoh, Global VP of Research, Cloud Security Alliance
Why Access Control Is the Central Problem
Containers are designed to be lightweight, portable, and numerous. In a busy Kubernetes cluster, dozens or hundreds of containers may run simultaneously across many nodes. This creates a sprawling attack surface where default configurations — including default security settings and default access controls — may be far more permissive than the sensitivity of the data being handled requires.
Yeoh points to a specific and well-documented attack pattern: an adversary compromises one container and then pivots laterally to others within the same cluster. Over-provisioned permissions — whether through misconfigured Role-Based Access Control (RBAC) policies, exposed Kubernetes API servers, or overly broad service account tokens — are frequently the enabler.
“We see breaches and incidents all the time when it’s compromised credentials or something really silly like, ‘Why does the attacker have that much access when they penetrate one environment?’ If we can address that and limit that, we’re going to be much better off.”
— John Yeoh, Cloud Security Alliance
Common Access Control Failures in Container Environments
- Overpermissive RBAC policies: Granting cluster-admin or broad namespace access when narrower roles would suffice.
- Default service account tokens auto-mounted: Kubernetes mounts service account tokens by default; many workloads that don’t need API access still receive it.
- Unrestricted inter-pod communication: Without Network Policies, every pod can reach every other pod in a namespace.
- Exposed Kubernetes API server: Publicly reachable API endpoints without strong authentication have been exploited in documented incidents.
- Secrets stored in plain text: Credentials embedded in container images or environment variables rather than managed through a secrets manager.
Shifting Security Left: Building It Into the Development Cycle
The CSA’s position — consistent with the broader DevSecOps movement — is that security must be addressed as early as possible in the software development lifecycle, not bolted on after deployment. Yeoh describes a model where automated checks are embedded directly into CI/CD pipelines, and where code with security problems can be rolled back before it ever reaches production.
“You are also able to automate a lot of these [checks] as well, and you can almost create a self-healing architecture, where it rolls back, is fixed and then moves forward. We’re seeing more and more people do that in cloud environments. It’s a way to make sure that developers are held accountable.”
— John Yeoh, Cloud Security Alliance
In practical terms, this means integrating tooling at several stages of the pipeline:
- Image scanning: Scanning container images for known CVEs before they are pushed to a registry (tools such as Trivy, Clair, or Snyk Container).
- Static analysis: Linting Kubernetes manifests and Dockerfiles for security misconfigurations (tools such as kube-score, Checkov, or Kubesec).
- Admission controllers: Using Kubernetes admission webhooks (e.g., OPA/Gatekeeper, Kyverno) to block non-compliant workloads from being deployed to the cluster at all.
- Runtime security: Monitoring container behaviour at runtime to detect anomalous system calls (tools such as Falco).
- Automated rollback: GitOps workflows that can detect a failed or insecure deployment and roll back to a known-good state automatically.
Compliance in a Containerized World
Container environments present compliance teams with a challenge that traditional VM-based infrastructure did not: workloads are ephemeral. A container may run for seconds or minutes and leave no persistent audit trail unless that logging is explicitly configured. This makes meeting the audit and data-residency requirements of regulations such as the California Consumer Privacy Act (CCPA) and the New York SHIELD Act — both discussed at the CSA’s RSA 2020 sessions — significantly more complex.
Attorney Aravind Swaminathan, Global Co-Chair of the cyber, privacy and data innovation practice at Orrick Herrington & Sutcliffe LLP, highlighted a broader issue for organizations moving to cloud: users and organizations do not own the underlying infrastructure, which changes the risk model fundamentally.
“There’s tons of value in the cloud, but you have to understand the risks. We have recently seen individuals compromise the cloud environment when we thought we had protections like multifactor authentication and certain controls, and attackers were able to make end-runs around those. And that’s the challenge.”
— Aravind Swaminathan, Orrick Herrington & Sutcliffe LLP
Practical Recommendations for DevOps and Security Teams
Based on the challenges identified by the CSA and the speakers at RSA 2020, the following practices reflect the direction the industry is moving:
- Apply least-privilege RBAC: Audit every Kubernetes role and cluster role binding. Grant only the permissions a workload genuinely needs.
- Disable auto-mounting of service account tokens on pods that do not need to communicate with the Kubernetes API.
- Implement Network Policies: Default-deny all ingress and egress traffic, then explicitly allow only required flows.
- Scan images before deployment: Block images with critical or high CVEs from reaching production registries.
- Use a secrets management solution: Avoid embedding credentials in images or manifests; use a dedicated secrets store integrated with your cluster.
- Enable audit logging: Kubernetes audit logs and container runtime logs should be shipped to a centralized, tamper-resistant store for compliance and incident response.
- Adopt a DevSecOps pipeline: Make security gates part of CI/CD so that developers receive fast feedback and policy is enforced consistently.
- Plan for regulatory requirements early: Map data flows through your containerized architecture to understand where regulated data lives and how ephemeral workloads affect audit trails.
The Road Ahead
The security challenges that containers and Kubernetes introduce are not insurmountable, but they do require a deliberate shift in how security is resourced and when it is applied. The CSA’s research presented at RSA 2020 reflects a consensus view that is still relevant today: security teams must evolve from gatekeepers who review finished applications to engineers who build security requirements directly into the development process. Self-healing pipelines, automated compliance checks, and granular access control are no longer aspirational — they are operational requirements for any organization running containerized workloads in production.
Original reporting by BankInfoSecurity. Cloud Security Alliance research was presented at RSA Conference 2020, San Francisco.