This repo demonstrates how the example architecture from the ControlPlane talk What can go wrong when you trust nobody? Threat Modelling Zero Trust
, can be run locally in a Kind cluster. This allows us to spin up components quickly and
easily, with only a small amount of cloud resources required. Understanding each component in more detail by configuring
integrations in this manner will ultimately lead to a more comprehensive threat model.
Two demonstrations are included:
- Demo 1 - Authenticate to AWS from a Pod in our Kind cluster, using an SVID issued by the cluster's SPIRE server.
- Demo 2 - Deploy two workloads in an Istio service mesh, with External Authorisation set up using OPA sidecars. OPA policy bundles are downloaded from an S3 bucket. Istio is integrated with SPIRE, and Rego traffic authorisation policies are based on X.509 SVIDs provided to our workloads via SPIRE.
In order to run the examples, an active set of AWS credentials must be available when running the various commands.
This examples uses a number of S3 Buckets, in order to ensure you get unique names, you set the NAME
environment
variable to something unique to you.
export NAME=something-unique-to-you
- Create a Kind cluster and preload third party images
- Build and load the various images used in the demo
- Deploy SPIRE with OIDC Discovery exposed using an S3 Bucket
More details can be found here.
make cluster-up cluster-preload-images
make image-build-load-jwks-retriever \
image-build-load-s3-consumer \
image-build-load-jwt-retriever \
image-build-load-opa-istio-kms
make spire-deploy
These are the key components for this deployment:
- SPIRE OIDC Bucket
- SPIRE OIDC Provider
- Templated configuration files
- JWKS Retriever
Available after
make spire-deploy
- SPIRE OIDC Discovery Document
- SPIRE JWKS
In this scenario an example service retrieves an object from an S3 bucket.
More details can be found here.
- Deploy the s3-consumer application
- Verify everything is working
- Cleanup
make example-one-deploy
make example-one-clean
- Target Bucket and access policy
- Federated Role
- S3 Consumer manually exchanging the SPIRE JWT SVID for temporary AWS Credentials
- View the application logs
In this scenario we deploy Istio with SPIRE provided X.509 SVIDs for mTLS and a customised OPA Istio sidecar that uses our custom bundle signing plugin utilising KMS keys. Kyverno injects the sidecars into the two workloads and the OPA sidecar reads the JWT SVID from a shared volume and exchanges this for temporary credentials to access S3 and KMS.
More details can be found here.
- Deploy Kyverno and Istio
- Sign and publish the OPA Bundle and deploy the example workloads
- Check the Istio certs are issued by SPIRE
- Check the communication uses Istio's External Authorisation (and spell it properly)
- Cleanup
make kyverno-deploy istio-deploy
make example-two-opa-publish example-two-deploy
make example-two-check-istio-certs
make example-two-send-requests
make example-two-delete istio-clean
- OPA Policy Bucket
- OPA Bundle Signing Keys
- OPA Role
- Templated configuration files
- Istio Operator configuration
- Kyverno policy to inject configured OPA sidecar
- Istio configuration for loading and verifying the bundles from S3 using KMS and automagic AWS credentials
- JWT Watcher
Available after
make istio-deploy
- OPA Policy from template
- Delete the S3 resources for SPIRE and the Kind cluster
make spire-clean cluster-down