Need for ZTN

Firstly, Zero Trust Network is where no network entity is trusted by default or with respect to its position in the network. Every workload, node, machine needs to continuously identify itself.

Shortcomings of traditional network architecture.

Traditionally IT companies used to have a network with firewall and all the entities within the network are trusted by default. This is also called as castle and moat architecture. We all have used VPNs to connect to the network. The problem with this approach is that once an attacker has access to the network. He have free reign over the network. He could access all the data he could. Now-a-days, the networks are spanned across different clouds and hence the traditional network architecture will not work.

Additional risks due to microservices

The emergence of microservices architecture means that the sensitive data now flows continuously between all the microservices, posing additional risks of spoofing attacks on microservices. You can have application-specific solutions to hold certificates of other workloads like Java truststore but a lack of coherent solutions across all the different workloads can be a problem.

Ephemeral nature of underlying hardware in the cloud-native ecosystem.

When using Kubernetes or similar container orchestration tools, the underlying nodes are changed and replaced continuously, so you cannot keep whitelisting the IP addresses or instanceIDs as the nodes change. This is not feasible and not practical.

mTLS and SPIFFE

As we all know the modern internet works on TLS certificates. mTLS is using TLS certs to mutually authenticate each other. mTLS is a proven way of implementing Zero Trust Network. Here you can have CA which issues certs to all the required workloads. The workloads can authenticate each other using TLS certificates.

SPIFFE is

SPIFFE, the Secure Production Identity Framework for Everyone, is a set of open-source standards for securely identifying software systems in dynamic and heterogeneous environments. Systems that adopt SPIFFE can easily and reliably mutually authenticate wherever they are running.

SPIFFE sets the standard of how an ZTN can be implemented. It works by having a workload API running on all the nodes and issuing SVID(Spiffe verifiable Identity Document) to the workloads which can use to authenticate themselves. These documents are short-lived, constantly rotated and cryptographically signed making them more secure.

SPIRE is

SPIRE is a production-ready implementation of the SPIFFE APIs that performs node and workload attestation in order to securely issue SVIDs to workloads, and verify the SVIDs of other workloads, based on a predefined set of conditions.

The SPIFFE project has created the standards and also an implementation of these standards so that the companies can implement mTLS. It works similarly to Hashicorp Vault or Istio where there is a SPIRE Server which is centrally located and there are SPIRE Agents which run in all the nodes. This part of the docs details how this entire process works. SPIFFE and SPIRE are primarily created for Cloud Native workloads but can be worked with traditional VMs as well. There are multiple ways to set up SPIRE server and agent, the easiest one will be having both inside the same Kubernetes cluster.

Conclusion

Though SPIFFE is not the only way it is a compelling solution to approach Zero Trust Network using mTLS in CloudNative environments

Understanding Zero Trust Networks, mTLS and SPIFFE