Top trends in the Kubernetes security space

What is “shifting down”? Last TalosCon, Cheryl Hung, independent consultant, former Senior Director of Ecosystem at ARM, and founder of popular Cloud Native London, covered key Kubernetes security trends.

Here's how "shifting down" may be the next step from the shift left, and what it means for Kubernetes security.

Why hasn't Kubernetes security gotten easier over time?

Since 2019’s, CNCF's annual survey has been asking, "Is security a challenge when using and deploying containers?

The number changed each year–but just barely. Around 40% continue to say yes. After five years of work, the industry sits essentially where it started.

Hung identifies several fundamental challenges that emerged with the move to cloud-native architectures:

• Shared responsibility creates gaps. In traditional security models, organizations maintained a clear separation between internal trusted networks and external networks. Cloud and container environments blur these lines entirely. With containers, workloads from different sources run on the same machines, and it becomes unclear who is responsible for securing what.
• Misconfiguration is a killer. Cloud platforms and Kubernetes offer tremendous flexibility, but that flexibility creates countless ways to get things wrong. S3 buckets left unsecured, unencrypted databases, misconfigured RBAC – issues that are difficult to spot and detect at scale. Hung notes that misconfiguration, not sophisticated attacks, causes most major breaches.
• Identity is the new perimeter, but it's hard to get right. Kubernetes RBAC and cloud IAM don't map perfectly to each other, creating opportunities for errors. Breaches in identity management are catastrophic.
• Speed versus security. Development teams want to ship fast, and security reviews don't always keep pace. The "shift left" movement of recent years pushed security responsibilities toward developers, but developers aren't security specialists. This approach doesn't scale consistently, which raises an important question about the difference between shift left and shift down security approaches.

What is shift down security in Kubernetes?

Most teams are familiar with the idea of shifting left. Shifting down is a complement to this. Learn more about it in this CNCF talk.

The model starts with three organizational teams:

1. Application teams deliver features and fix defects (the "magic" for users). Most organizations have multiple application teams.
2. Security teams handle runtime security, compliance, vulnerability management, configurations, and software supply chain concerns.
3. Platform teams provide self-service, highly automated infrastructure to application teams.

Shift down Kubernetes security pushes certain responsibilities, particularly those around vulnerabilities, misconfigurations, and supply chain, into the platform team rather than leaving them distributed across application and security teams.

Under the shift-down model, the platform team offers:

• Hardened, minimal images. The platform team maintains "golden images" that application teams consume, and handles scanning during CI/CD pipelines. This approach clarifies who should be responsible for container image security in an organization, centralizing ownership rather than fragmenting it.
• Policy as code. Implementing policy as code for Kubernetes security means policies are managed through version control with code reviews, rather than living in documents and spreadsheets. This ensures consistent enforcement across the organization.
• Supply chain verification. Image security happens both during earlier pipeline phases and in production.

The application team doesn't disappear from security. However, under this model, they can focus primarily on feature development, while security teams concentrate on defining standards, setting SLAs, and approving exceptions when needed.

Core principles

Hung outlines three principles behind the shift down:

1. Embrace the chaos. Complexity isn't going away, but platform teams can manage common concerns.
2. Automate the trust. Policy as code, not policy in documents and spreadsheets.
3. Less is more. Rather than pushing responsibility toward individual developers (shift left), push it into the platform where it becomes self-service and automatable alongside everything else.

Conclusion

While many teams are implementing some of these principles, they have not been able to implement all three.

If Kubernetes security really is just as challenging as it was in 2019, the shift down model may offer a structural response that sticks. Rather than asking developers to become security experts or leaving security teams disconnected from deployment pipelines, it embeds security capabilities into the platform layer where they can be automated, versioned, and consistently enforced. For organizations already running platform teams, this represents a natural extension of responsibilities. For those still operating without that layer, it may be the push needed to invest in one.

Watch the whole talk here.