Released on August 27, 2025 under the theme « Of Wind & Will (O’ WaW) », Kubernetes v1.34 brings a strong security focus, reinforcing zero-trust principles, secure defaults, and identity-aware operations across the platform.
Projected ServiceAccount Tokens for Image Pulls (Beta)
– What’s new: The kubelet can now use short-lived, audience‑bound ServiceAccount tokens to authenticate with container registries, eliminating static Secrets on nodes.
– Why it matters: This significantly shrinks the attack surface by eschewing long-lived credentials, aligning registry access with workload identity rather than node-level secrets.
Scoped Anonymous Access for API Endpoints
– What’s new: Administrators can now safely expose health endpoints (/healthz, /readyz, /livez) to unauthenticated access, while denying broader anonymous access via narrow configuration in AuthenticationConfiguration.
– Why it matters: Prevents accidental overexposure of API capabilities, balancing observability/open health checks with tightened security controls.
Pod Identity & mTLS with PodCertificateRequests (Stable)
– What’s new: Pods can now obtain X.509 certificates via PodCertificateRequests, allowing kubelet-managed issuance for use in mTLS authentication.
– Why it matters: Embeds strong, workload-specific identity into the platform, reinforcing secure communication patterns among services.
Field or Label-Aware RBAC (Enhanced Least Privilege)
– What’s new: Although not yet GA, emerging enhancements allow RBAC rules that consider node or pod-specific attributes (fields or labels) to enforce least-privilege access.
– Why it matters: Granular permissions reduce risk from overbroad role bindings, tightening control over what pods or nodes can access and do.
CEL Mutation Policies & External JWT Signing
– CEL Mutation Policies: Introduce native support for rule-based mutation using Common Expression Language (CEL), enabling secure, declarative policy enforcement within Kubernetes.
– External JWT Signing: Facilitates signing JWTs via external key management services, removing local key storage and enhancing auditability and security.
Mutual TLS (mTLS) for Pod-to-API Traffic
– What’s new: Kubernetes is ramping up mTLS support to secure pod-to-API server communications, though details are still unfolding.
– Why it matters: Ensures encrypted, authenticated channeling between workloads and the control plane, a key zero-trust tenet.
OCI Artifact Volumes & Image Pull Security
– What’s new: Ability to mount OCI images directly as volumes, ensuring secure, versioned delivery of external files to pods.
– Why it matters: Reduces reliance on sidecars or manual injection methods, streamlining configuration while preserving integrity.
Conclusion
Kubernetes v1.34 represents a meaningful step forward in embedding robust security into the platform itself. From per-pod identity to safer defaults, explicit anonymous access handling, and fine-grained policy enforcement, it advances Kubernetes toward a more zero-trust architecture.
Organizations should explore upgrading thoughtfully, especially leveraging the projected ServiceAccount tokens, pod-level certification, and scoped anonymous access to immediately elevate cluster security.
Maxime.
Catégorie : Kubernetes
User Namespaces in Kubernetes: Perspectives on Isolation and Escape
User Namespaces in Kubernetes are designed to improve pod isolation by mapping container users to non-root UIDs on the host. While they offer a promising sandboxing mechanism, their security implications are nuanced. For offensive security practitioners, understanding how user namespaces work opens doors to assess potential privilege escalation, misconfigurations, and runtime escape attempts in hardened clusters.
What Are Kubernetes User Namespaces?
In traditional Kubernetes setups, containers often run as root (UID 0), which also maps to root on the host unless otherwise restricted (e.g., with seccomp, AppArmor, or dropping capabilities). With User Namespaces, UID 0 inside the container can be mapped to a non-root UID (e.g., 100000) on the host, drastically reducing the risk of container breakout.
Core Concept:
Container UID | Mapped Host UID |
---|---|
0 | 100000 |
1 | 100001 |
1000 | 101000 |
This mapping isolates privilege levels, ensuring that root inside the container ≠ root on the host.
Offensive Security Perspective: Attack Surface & Evasion Tactics
Despite the promise of tighter isolation, user namespaces introduce complexity that can be exploited or abused if not configured properly. Let’s analyze common offensive scenarios.
1. Privilege Escalation via Misconfigured Mappings
If the UID/GID mappings are too broad, or improperly configured (e.g., overlapping ranges), an attacker could potentially:
- Access sensitive host resources via mapped UIDs.
- Use remapped file permissions to exploit volume mounts (e.g., hostPath or PVCs).
- Abuse misaligned subuid/subgid ranges to escalate outside the intended sandbox.
Example Attack:
bashCopyEdit# Container UID 0 maps to Host UID 100000
# But /data is mounted with files owned by Host UID 100000
cat /data/secrets.txt
Result: UID 0 inside the container has effective access to host-owned files, violating isolation.
2. Kernel Exploits Inside Namespaces
Even with UID remapping, the container shares the kernel. User namespaces do not prevent kernel-level exploits such as:
- DirtyPipe (CVE-2022-0847)
- Dirty COW (CVE-2016-5195)
- StackRot (CVE-2023-3269)
Red Team Tactic:
If CAP_SYS_ADMIN is not dropped, or seccomp filters are lax, you can test kernel exploits inside user namespaces with minimal detection due to reduced apparent privileges.
# Run DirtyPipe exploit inside a user-namespaced container
./dirtypipe /etc/passwd "root::0:0:root:/root:/bin/bash\n"
3. Anti-Forensics & Evasion with Mapped UIDs
User namespaces make detection more complex from a blue team’s perspective:
- Logs might show actions from UID 100000+ on the host instead of UID 0.
- Traditional forensic tooling might miss attribution of malicious activity if unaware of the mapping.
Example:
bashCopyEdit# From container: creates a backdoor as UID 0
echo "malicious_user:x:0:0::/root:/bin/bash" >> /etc/passwd
On host, this action appears as being made by UID 100000 — not obviously suspicious unless correlated with namespace mappings.
4. Side-channel and Shared Resource Attacks
Even with user namespaces, shared resources can become attack vectors:
- cgroups, /proc, and /sys access
- Spectre/Meltdown-style attacks
- CPU time, memory pressure side channels
Tactic:
Use PID or mount namespace escape primitives combined with user namespace to test access to host-level interfaces. For example:
lsns -t user,pid
If misconfigured, you may be able to observe or interfere with host-level processes.
What Doesn’t Work (Defense Successes)
User namespaces offer strong mitigations against:
Threat | Mitigated by User Namespaces |
---|---|
Direct host root access | ✅ |
Access to host UID 0 files | ✅ |
CAP_SYS_ADMIN container use | ✅ (if dropped) |
AppArmor/SELinux bypass | ✅ (if enforced properly) |
However, they do not protect against:
- Kernel-level vulnerabilities
- Volume mount misconfigurations
- Lax seccomp/bpf policies
- Insufficient container runtime restrictions (e.g., allowing
--privileged
)
Offensive Testing Setup
You can simulate a user namespace-enabled cluster using:
yamlCopyEditapiVersion: v1
kind: Pod
metadata:
name: userns-test
spec:
securityContext:
runAsUser: 0
runAsGroup: 0
seccompProfile:
type: RuntimeDefault
runtimeClassName: "userns"
containers:
- name: test
image: alpine
command: ["/bin/sh", "-c", "id && sleep 3600"]
Check the UID mappings inside the container:
cat /proc/self/uid_map
Use host PID or mount checks to assess boundary enforcement.
How to Defend Against Offense
Defense Layer | Best Practices |
---|---|
UID/GID Mapping | Use minimal, non-overlapping ranges (subuid , subgid ) |
Capabilities | Drop all except required ones (especially CAP_SYS_ADMIN ) |
Seccomp | Enforce strict syscall profiles (RuntimeDefault , Custom ) |
Volume Management | Avoid hostPath; use projected volumes or CSI |
RuntimeClass Enforcement | Use PodSecurityAdmission or Kyverno/Gatekeeper to enforce runtimeClassName |
Conclusion
While User Namespaces are a powerful isolation primitive in Kubernetes, they’re not a silver bullet. Offensive security testing shows that, when misconfigured or poorly integrated with other controls, user namespaces can be subverted or bypassed. A layered defense including syscall filtering, strict capability drops, and forensic visibility tooling — is essential.
If you’re building hardened Kubernetes platforms, test user namespaces like an attacker. Simulate kernel exploits, map UID collisions, and validate how well the telemetry captures identity mappings.
From Vision to Stage: My KubeCon Europe 2025 Experience in London, UK
Just over a year ago, I told my team that I wanted to speak at a future KubeCon. No roadmap. No CFP draft. Just a bold intention. Fast forward to April 2025, I stood on stage in London at KubeCon + CloudNativeCon Europe—sharing our security journey in front of the most vibrant, forward-thinking community in tech. It wasn’t just a milestone. It was a personal and professional transformation.

The Talk: “Platform Engineering Loves Security: Shift Down, Not Just Left!”
Co-presenting with my friend and co-speaker Mathieu, we delivered a talk that challenged the traditional “shift left” security narrative. Instead, we proposed a more pragmatic, scalable approach: “shift down into the platform, not left to your developers« .
We walked through real-world lessons from the trenches—how platform teams can embed security guardrails by design, without burning out developers or slowing delivery. We covered:
- Real Kubernetes policy enforcement stories using OPA and Gatekeeper
- Building paved roads for secure service onboarding
- Why platform ownership is the missing link in cloud-native security


The feedback? Incredible. Thoughtful questions, packed room, and lots of “this is exactly what we’re facing” conversations afterward.
What Made This KubeCon Special
Every KubeCon is filled with energy, but London felt different. Maybe it was the hallway track filled with impromptu deep dives. Maybe it was the sheer volume of conversations around AI governance, multi-tenancy security, and platform responsibility.
I connected with other CNCF community leaders, fellow Microsoft MVPs, and members of the Kubernetes Security Special Interest Group (SIG) and TAG Security. We exchanged ideas on how to improve secure defaults in open source tooling and keep up with the ever-changing threat landscape.
Must-Watch Sessions
- KubeCon EU 2025: Azure Day: Morning Session (Azure Kubernetes Service)
- Objection! AI Security Mistakes on Trial With Kubeflow and Confidential Computing
- Panel: Platform as a Product as a Transformation Enabler Within One of the Top 4 Banks in the UK
- Panel: Platform Engineering in Financial Institutions: The Practitioner Panel
- Compliance at the Speed of Innovation: Leveraging AI-Driven Automation for Real-Time Regulatory Read
- The Past, the Present, and the Future of Platform Engineering
- Unlocking the Future of Kubernetes Policy as Code With Kyverno
- Lightning Talk: 10 Quick Tips on How To Internally Market Your Platform
- Product Thinking for Cloud Native Engineers – Stéphane Di Cesare & Cat Morris
- Platform Engineering for Architects – Crafting Platforms as a Product
- Securing the Modern Software Supply Chain: A Beginner’s Guide To SLSA, SBOM, and Beyond
- Lightning Talk: Agentic Bee: How To Get AI Agents To Talk To Tetragon
- Attesting and Verifying Your Software Supply-Chain with in toto
- Identity-based Trust – Till Death Do We Part?
- Leveraging Internal Knowledge: Building AiKA at Spotify – Majd Salman & Jofre Mateu Matesanz
- Platform Engineering for Software Developers and Architects (Redux) – Daniel Bryant, Syntasso
- Project Lightning Talk: Kubewarden: Leveraging and Extending CEL for your Cluster Security
- Project Lightning Talk: Empowering Federated Learning with Multi-Cluster Management for Privacy and Efficiency
- Project Lightning Talk: ORAS: Create and Distribute a Multi-platform Image with Security Posture
- Project Lightning Talk: Capsule: Launching Multi-Tenancy to New Kubernetes Horizons
- The Bricks That Make Us – How the LEGO Group Avoids 50 Mediocre Kubernetes implementations
- Container Runtimes… on Lockdown: The Hidden Costs of Multi-tenant Workloads
- Tutorial: Hacking up a Storm With Kubernetes
- Enhancing Software Composition Analysis Resilience Against Container Image Obfuscation
- Beyond Security Leveraging OPA For FinOps In Kubernetes Sathish Kumar Venkatesan
- Dapr + Score: Mixing the Perfect Cocktail for an Enhanced Developer Experience, Mathieu Benoit & Kendall Roden
From Open Source to Open Conversations
What really makes KubeCon unforgettable isn’t just the sessions—it’s the people. Meeting folks I’ve only known online, reuniting with past collaborators, mentoring first-time attendees, and exchanging stories over coffee.
One of the standout moments this year was meeting some of the very first Golden Kubestronauts—like Sajeeva Nambadawa Vithanage. This new CNCF initiative celebrates individuals who not only achieve all CNCF certifications but also exemplify community leadership, collaboration, and a deep commitment to cloud-native innovation.

It reminded me why I care so deeply about this space: we’re not just building systems—we’re building a movement. One where security, collaboration, and open source values are not just buzzwords, but guiding principles.
✈️ What’s Next?
Coming back from KubeCon, I’m more motivated than ever:
- To continue pushing for technical leadership recognition in security roles.
- To help more teams adopt platform-centric security thinking.
- To mentor others chasing their first KubeCon CFP.
And maybe… to start planning for KubeCon North America?
Whether you’re just starting out or deep into your cloud-native journey, I can’t recommend attending (or speaking at!) a KubeCon enough. It’s more than a conference—it’s a catalyst.
Let’s keep raising the bar. Together.
Maxime.