Threat Modelling Zero Trust

This blog post is based on the Kubecon EU 2023 talk: What Can Go Wrong When You Trust Nobody? Threat Modeling Zero Trust - James Callaghan & Richard Featherstone, ControlPlane

With the prevalence of cloud native technologies continually growing, and organisations increasingly adopting multi-cloud and hybrid architectures, it has never been more important to discuss the principles of Zero Trust. In order to fully apply the philosophy of ’never trust, always verify’, we must build systems with a sound understanding of the adversaries who may wish to compromise our data, how such a compromise could occur, and how we can protect ourselves by implementing proportionate, layered security controls.

When threat modelling, it is important to prototype early in order to understand how the underlying technologies are integrated. You can then put yourself in the position of an attacker, and ask what can go wrong. We have provided an example repo, to help you get started with the technologies we covered in the talk.

To fully apply a Zero Trust philosophy to workloads, we need cryptographically verifiable identities for our workloads. Our prototype uses SPIRE (a production ready implementation of the SPIFFE framework for workload identity) to issue identity documents to some example workloads deployed to an Istio service mesh within a local Kind cluster. By integrating Istio with SPIRE (using the fact that SPIRE can act as an SDS server for Envoy), we can ensure that workloads get identity documents from the same issuing authority, whether the identity document is an X.509 certificate for TLS, or a JWT (which may be needed if traversing a layer 7 load balancer).

Once workloads have cloud-agnostic identities, authorisation decisions can be made based on these identities, making it possible to enforce the principle of least privilege for workloads. We demonstrate how Istio External Authorization can delegate layer 7 authorization decisions to OPA sidecars.

It is important to note that threat modelling is an iterative process, and once controls have been defined at a high level, detailed threat modelling of the low-level architecture can be performed to fine-tune these controls. In our talk and the accompanying prototype, we show how layered security controls can be applied which thwart our attacker’s valiant efforts. In particular, we introduce a custom method to sign and verify OPA bundles, using an AWS KMS key pair. This will benefit anyone who wishes to preserve the integrity of OPA policy and data bundles, as the risk of a signing key compromise will be reduced by ensuring that the private key is only used within AWS KMS to perform the signing operation.

We believe that threat modelling should be performed by everyone. By linking architectural controls to a threat model, prototyping early and iterating our architecture, we can be confident that our systems are robust, and we can demonstrate compliance to standards in highly regulated environments.

We invite you to take a look at our prototype for our talk’s example architecture, put yourself in the position of an attacker, and see what new threats you can come up with!