What happens when your infrastructure is designed to disappear? Ephemeral Kubernetes environments bring massive advantages in cost, scalability, and security — but they also demand a fundamentally different mindset from security teams accustomed to static servers they can SSH into.
We spoke with Dinis Cruz, CEO and founder of The Cyber Boardroom and MyFeedAI startups, on the Scale to Zero podcast. Dinis brings over 20 years in cybersecurity and software development, with previous CISO roles at Photobox Group and Revolut, and deep hands-on experience as a CTO building Kubernetes-native infrastructure.
You can read the complete transcript of the episode here >
How do you shift from a data center mindset to ephemeral Kubernetes security?
Dinis is direct: security teams must also be engineering teams. You need developers who understand CI pipelines, deployment, and infrastructure-as-code. Without that engineering foundation, security teams cannot participate meaningfully in conversations about dynamic environments.
The key insight is that most security problems are actually engineering problems, workflow problems, or process problems. Security is a side effect. The best security teams he has worked with were always the best engineering teams — for them, input validation, patch management, and IAM are natural properties of well-built systems, not bolted-on afterthoughts.
Teams that can ship fast can also fix fast. Organizations with rapid deployment capabilities end up with fewer long-lived vulnerabilities than teams that deploy once a week and are afraid to touch production.
What are the biggest challenges when moving to ephemeral environments?
The shift from static to dynamic infrastructure introduces several challenges:
- Forensics in vanishing environments: When a container that caused an incident is already gone, traditional investigation approaches fail. You cannot SSH into something that no longer exists.
- Logging and monitoring gaps: Most organizations still do not capture enough information. The need for SIEMs exists precisely because engineering teams lack proper observability.
- Funding for non-functional requirements: Teams struggle to get budget for logging, monitoring, and security when leadership only funds visible product features.
- Kubernetes complexity at scale: Beyond 50–100 nodes, clusters become fragile. Dinis found that running 200 single-node instances with load balancing was more reliable than one massive cluster.
His solution for Kubernetes scaling: scale to one. Run each workload on its own dedicated single-node cluster. This forces clean engineering decisions and provides natural blast radius containment.
How should organizations handle logging in ephemeral environments?
Dinis rejects the conventional approach of sending all logs to a centralized platform. Instead, he uses a LETS pattern — Load, Extract, Transform, Save:
- Store raw logs in cloud storage first (not directly into your logging platform). Cloud storage is orders of magnitude cheaper.
- Create transformation pipelines that progressively clean and enrich data from one storage layer to the next.
- Send only the minimal cleaned data to your logging platform for day-to-day monitoring.
- Reload raw data on demand when you need to zoom into a specific time window for investigation.
The logging infrastructure itself should be ephemeral — you should be able to delete it entirely and rebuild from stored data. This keeps costs down while maintaining full forensic capability when needed.
Why is identity the key to securing Kubernetes workloads?
In ephemeral environments, identity should also be ephemeral. Each workload should receive credentials scoped to exactly what it needs for that specific request — not broad permissions that persist.
The problem today: most Kubernetes environments have minimal internal security. Services talk to services freely because they lack strong identity propagation. User identity gets lost as requests move deeper through the application stack, eventually reaching databases with overprivileged service accounts.
Dinis envisions a model where:
- Every request carries identity context from the original user through every service hop.
- Assets (databases, APIs) can validate who is actually making the request — a real user, an admin, a bot, or a compromised GenAI agent.
- Permissions are scoped not just to the service but to the specific task in a workflow sequence.
GenAI makes this achievable by helping teams understand their infrastructure well enough to define fine-grained permissions — analyzing Terraform scripts, Helm charts, and firewall rules to map actual data flows.
How does GenAI change the Kubernetes threat landscape?
Dinis sees GenAI as potentially the most dangerous internal threat organizations have ever faced. A Kubernetes pod with GenAI capabilities that gets compromised is fundamentally different from a traditional compromised node:
- Intelligent lateral movement: Unlike traditional exploits that require scripted attack chains, a GenAI agent can explore, adapt, and attack other nodes creatively.
- MCP server volatility: The Model Context Protocol means that not only can infrastructure change dynamically, but the very definition of what tools an LLM can access can change minute to minute — making incident reconstruction nearly impossible.
- Prompt injection at scale: Everything in an LLM’s context window is potential attack surface — DNS entries, tool descriptions, results from other tools, web page content.
His defensive recommendation: treat every GenAI-enabled pod as radioactive. Run them on dedicated single-node clusters with strict isolation. Ask the question: “What happens if this thing starts attacking all other nodes?” Most environments today cannot survive that scenario.
How should security teams use GenAI defensively?
Dinis draws a critical distinction: do not use GenAI to create — use it to translate and transform. This approach is far more deterministic:
- Translate Helm charts into human-readable descriptions to catch security implications in changes.
- Transform firewall rules into graphs to identify redundancies and gaps across thousands of rules.
- Analyze code diffs and update security documentation automatically.
- Run three models in parallel on the same translation task — if they agree, you have high confidence in the output.
The key principle: always provide the raw data to the LLM rather than asking it to generate from its training data. When translating existing artifacts, hallucination drops dramatically.
Security teams have a unique advantage: they are the only team in an organization that can legitimately access all data, all documents, all systems. Combined with GenAI’s ability to process and correlate that information, defenders can finally understand “what good looks like” — and catch attackers when they deviate from it.
How will the role of security engineers evolve with GenAI?
Dinis is optimistic: we will need more engineers, not fewer. Every business function — HR, finance, marketing, procurement — will start shipping code through vibe coding and no-code tools. Each will need dedicated engineers handling non-functional requirements: security, logging, scalability, and deployment.
His hiring philosophy reinforces this: when building security teams, hire developers and teach them security. The development mindset — understanding CI pipelines, abstractions, and systematic problem-solving — is harder to teach than security domain knowledge.
The engineers who thrive will be curious, willing to learn, and comfortable working at the intersection of business enablement and technical security controls.
