Kubernetes: the right path to a more secure infrastructure

Most security incidents do not start with a brilliant attacker. They start with a server nobody has patched, a network where everything can talk to everything, and a release process so slow that known vulnerabilities stay open for months. Kubernetes, used the right way, changes all three.

This is not about chasing the latest trend. It is about building infrastructure where security, speed and stability support each other instead of competing.

Infrastructure as code, not hand-built servers

In a traditional setup, every server slowly becomes unique. Someone installs a package, changes a setting, applies a hotfix at night. After a few years nobody knows exactly what runs where, and nobody dares to touch it.

With Kubernetes, everything is described as code: which applications run, how many copies, which resources they get and who may talk to whom. That description lives in Git, goes through review and is applied automatically. The result:

• Every change is traceable: who changed what, when and why.
• Environments are identical: test and production are built from the same definitions.
• Recovery is fast: if something breaks, the platform is rebuilt from code instead of from memory.

Network policies: stop the spread

By default, every pod in a Kubernetes cluster can reach every other pod. That is convenient, and it is exactly what an attacker wants. Once inside one application, they can move freely to the next.

Network policies fix that. Start by denying all traffic, then open only what each application actually needs:

# Deny all incoming traffic in the namespace by default
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: shop
spec:
  podSelector: {}
  policyTypes: [Ingress]
---
# Allow only the web application to reach the database
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-from-web-only
  namespace: shop
spec:
  podSelector:
    matchLabels: { app: database }
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: web }
      ports:
        - port: 3306

This is zero trust in practice. A compromised component can only reach what it was explicitly allowed to reach, which limits the blast radius of every incident.

Network policies are one layer. The others are just as important:

• Pod security: containers run as non-root, with read-only file systems and no extra privileges.
• RBAC: people and services get exactly the permissions they need, nothing more.
• Secrets management: passwords and keys are stored and rotated centrally, never in code.
• Admission policies: rules that stop insecure configurations before they reach the cluster.

Scalability without drama

Kubernetes scales applications automatically based on load. When traffic increases, more copies start. When it decreases, they are removed. The cluster itself can add and remove servers in the same way.

That matters for security too. An application that can scale out is much harder to take down with a traffic spike, and resources are not left running idle, which is good for both the budget and the climate.

Hand in hand with agile development and DevSecOps

Kubernetes is at its best when it meets an agile way of working. Short sprints, small changes and frequent releases fit a platform where a new version can be rolled out gradually and rolled back in seconds.

The pipeline becomes the natural place for security. Every change passes through the same steps:

1. Code review and AI-assisted analysis of every pull request
2. Scanning of code, dependencies and container images for known vulnerabilities
3. Policy checks that stop insecure configurations
4. Signed images with a software bill of materials (SBOM)
5. Gradual rollout with health checks and automatic rollback

Security stops being a phase at the end of the project and becomes part of every cycle. And in every retrospective, the team can look at what to improve next, including security.

Maintenance: replace instead of repair

On a traditional server, patching means logging in, updating packages and hoping nothing breaks. In Kubernetes, you do not patch running containers. You build a new image with the fix, test it in the pipeline and replace the old version with a rolling update, without downtime.

The same principle applies to the servers underneath. Nodes are replaced rather than repaired, which means the platform is always running on known, up-to-date building blocks. There are no forgotten servers that were last updated three years ago.

From vulnerability to fix in hours, not months

This is where everything comes together. When a new vulnerability is published, the question every organisation should be able to answer is: how long until we are protected?

With traditional infrastructure, the honest answer is often weeks or months. Someone has to find out where the affected component is used, plan a maintenance window, update each server by hand and hope nothing else breaks.

With Kubernetes and a secure pipeline, the process looks different:

• Detection: image scanning and the SBOM tell you immediately which applications contain the vulnerable component.
• Fix: the dependency or base image is updated in one place.
• Verification: the pipeline rebuilds, tests and scans the new version automatically.
• Rollout: the fix goes out as a rolling update, with automatic rollback if something fails.

The time from vulnerability to fix shrinks from months to hours or days. That is one of the most important security improvements an organisation can make, and it comes from the way of working as much as from the technology.

Serverless, when it fits

Not everything needs to run all the time. With serverless on Kubernetes, using tools such as Knative or KEDA, applications can scale to zero when nobody uses them and start automatically when a request or an event arrives.

It suits event-driven workloads, integrations and background jobs. You get the convenience of serverless without being tied to one cloud provider's proprietary function service, and the same security policies apply as for the rest of the platform.

Freedom to move between cloud platforms

Kubernetes works the same way on AWS, Azure, Google Cloud, in a Swedish data centre or on your own servers. Applications described for Kubernetes can be moved between them with limited changes.

That freedom is worth more than ever. Geopolitical changes, new regulations, price increases or requirements for data to stay in the EU can all make it necessary to move. With a portable platform, that is a project, not a crisis.

Two things to be honest about:

• Managed services create dependencies. A cloud provider's database, queue or identity service is convenient but harder to move. Choose them consciously.
• Data has gravity. Moving applications is easy compared to moving large amounts of data. Plan for it from the start.

When Kubernetes is not the answer

Kubernetes is powerful, but it is not free. It adds complexity and needs people who understand it. For a single small application, a simpler setup may be the right choice. The value grows with the number of applications, the requirements for security and availability, and the pace of change.

The most common mistake is not choosing Kubernetes. It is running it without the security basics: no network policies, containers running as root, no image scanning and a release process nobody trusts.

Questions for your team

1. Can every pod in our clusters talk to every other pod?
2. How long did it take to fix the last critical vulnerability we found?
3. Can we rebuild our entire platform from code?
4. Could we move to another cloud provider within a reasonable time?
5. Is security part of every release, or something we check at the end?

If any of the answers worry you, that is where to start. Talk to us about a review of your Kubernetes platform and delivery pipeline.