Zero Trust & mTLS for Services in Romania

What Zero Trust means between services

The classic model assumes that anything inside the internal network is trusted. Zero Trust removes the assumption: every call is authenticated and authorised, wherever it comes from. In practice, each service receives its own certificate, presents it on every connection and checks the certificate of the other side. Without a valid certificate the call does not pass, even if an attacker already runs code on another server in the same private network.

• Mandatory mTLS on traffic between services, not only at the network edge
• Identity per service, not per server or per network
• Explicit authorisation policies: who may call whom
• A log of rejected connections, useful for debugging and for audits

Best practices we apply to Zero Trust

Zero Trust is not bought from a vendor, it is built in steps that can be verified one at a time. We apply the list below gradually, starting with the services that touch personal data, and we leave it in your documentation together with the order we followed. Every step is reversible, so you do not end up with a network that is secure on paper but in which nobody can debug a rejected call.

• No implicit trust in the local network: every call authenticates
• Identity per service, tied to the workload rather than to an IP address
• Least privilege: each service reaches only what it needs
• Automatic certificate rotation, short-lived and with no manual work
• Secrets encrypted in git with SOPS or kept in Vault, with an access log

Service mesh or sidecar-less

A service mesh such as Linkerd or Istio gives you mTLS and policy without changing the application, but it adds components to operate and resource use on every pod. For around ten services a mesh is usually too much: we reach the same result with cert-manager or step-ca and TLS settings in the application or the proxy. We tell you honestly where the line is, based on the number of services and the team that runs them.

• Few services: cert-manager plus TLS in the proxy, no sidecar
• Many services and teams: Linkerd for uniform mTLS
• Fine-grained routing and policy: Istio, with the operating cost accepted

Romanian context and included hours

For Romanian companies in scope of NIS2, transposed through Emergency Ordinance 155/2024, access control between systems is a concrete requirement, not an architectural preference. Non-compliance is penalised administratively and corrective measures are mandatory. The work comes out of your monthly hours, 1–8 h on VPS and 5–10 h on dedicated servers depending on the plan, requested in the client panel under DevOps Services. Anything above the quota is billed separately.

How we work

1. Request it in the panel

   Tell us which services you run, which ones touch sensitive data and how they talk to each other now, then propose a deadline.

2. We scope the work

   We map the calls, choose between a mesh and cert-manager, set the order of the services and estimate the hours from your allowance.

3. We build it in reversible steps

   We start the internal authority, issue certificates, enable mTLS in permissive mode, check the traffic, then switch each service to mandatory.

4. Handover with documentation

   You receive the identity map, the authorisation policies, the rotation procedure and the debugging steps for a rejected call.

Use cases

Technology stack

• cert-manager
• step-ca
• SPIFFE
• Linkerd
• Istio
• Envoy
• HashiCorp Vault
• SOPS
• Kubernetes

Frequently asked questions

• Istio vs Linkerd: which service mesh should I use?

  Linkerd is simpler, uses fewer resources and covers the usual need for mTLS and basic policy. Istio offers more routing and control, at a matching operating cost. For a small number of services, both are probably more than you need.

• Do I need a service mesh to get mTLS?

  No. With cert-manager or step-ca plus TLS configured in the application or a proxy, you get mutual authentication without sidecars. A mesh pays off when you have many services and teams and want mTLS applied uniformly without touching each application.

• What is mTLS, and how does it differ from ordinary TLS?

  With ordinary TLS only the server proves its identity, with the certificate you see in a browser. With mTLS both sides do: the client presents a certificate too. A service cannot then be called by an unknown component, even one that has network access.

• How do you introduce Zero Trust without blocking the team?

  In reversible steps. We start the internal authority, issue certificates, enable mTLS in permissive mode, which also accepts plain traffic while we check what connects, then move to mandatory one service at a time. Every stage has a way back.

• How do certificates rotate automatically between services?

  With cert-manager or step-ca, which issue short-lived certificates and renew them before expiry, with no manual work. Services reload them from a volume or from memory. We test rotation at delivery, so you do not discover problems on the expiry day.

• Do I need mTLS if my servers are already on a VPN?

  A VPN protects traffic from the internet, but inside it there is still implicit trust: any compromised process can call any service. mTLS adds identity to every call. The two complement each other, and together they make lateral movement much harder.