Cloud security after the first wave of containers: more than just the network
Why the perimeter security model does not work in a container environment - and what actually needs protecting instead.
Several years have passed since containers moved from a developer tool to a deployment standard. Kubernetes has become the de-facto orchestration platform. Companies that have been through the first wave of adoption now face a question that was deferred during the pilot phase: how to secure all of this properly.
The answer that traditional infrastructure established - configure a network perimeter, close ports, deploy a firewall - works partially in a container environment. The network matters, but it is not sufficient.
Why the network perimeter loses its meaning
In classical infrastructure you have servers with IP addresses, and the perimeter is built around them. In a container environment, services are ephemeral: a container starts, runs, stops. IP addresses are dynamic. The boundary between "inside" and "outside" is blurred, because microservices communicate intensively with each other.
A traditional firewall does not understand context - who ran this container, from which image, with what permissions, as part of which pipeline. But it is exactly this context that matters for container environment security.
What to protect instead of the perimeter
The first layer - container images. An attacker who enters the image supply chain gets access to every environment where that image is run. Control is needed: which images are in use, where they come from, who verified them and when, whether there are known vulnerabilities in the dependencies.
The second layer - orchestrator configuration. Kubernetes has a rich access model - RBAC. But "rich" does not mean "secure by default." On many installations, permissions are granted broadly because it is simpler during development. In production that becomes a risk: a service with excessive permissions can do things it should not.
The third layer - secrets. Passwords, tokens, access keys to external systems - how are they stored and how do they reach the container? Secrets in environment variables, baked into the image, or sitting in plaintext in manifests is a common problem.
The fourth layer - runtime behaviour. What does the container do while it is running? Which system calls does it make, which external addresses does it connect to, which files does it read? Anomalous container behaviour is often the first sign of a compromise.
A practical order of actions
For a company that already uses containers in production, I recommend starting with an inventory, not with buying a new tool.
Which images are currently running in production, and when were they last checked for vulnerabilities? Which service accounts have permissions in the cluster, and do they actually need those permissions? How do secrets reach containers right now? Is there system-level event logging at the node level?
Answering these questions often surfaces problems without a single new tool.
Questions to assess maturity
- Is there a process for scanning images for vulnerabilities before deploying to production?
- Is the principle of least privilege applied to Kubernetes service accounts?
- Where are secrets stored and how are they delivered to containers?
- Is there monitoring of anomalous network behaviour from containers?
- Who in the company is responsible for container platform security - a specific person, not "the team in general"?
Containers accelerated development and deployment. Now is the time to verify that the speed was not achieved at the cost of security that was left "for later."