There are a couple of things to check:

make sure that you've updated the issuer at the tenant screen: https://fusionauth.io/docs/v1/tech/core-concepts/tenants#general make sure you are using an asymmetric keypair to sign the id token. If you are using HMAC, which is the default for FusionAuth, you have to share a secret. Asymmetric algorithms like RSA256 are what proxies typically need (so they don't have to have the signing secret). More here: https://fusionauth.io/docs/v1/tech/core-concepts/applications#jwt and here: https://fusionauth.io/docs/v1/tech/core-concepts/key-master

Hope that helps.

No. Our cloud is a fully managed system, so you shouldn't care about the underlying technology.

It isn't built with Kubernetes so when we launch a deployment in it, it's constructed using a different approach.

If you want to run FusionAuth with kubernetes, that is supported, but you must self-host. More details here: https://fusionauth.io/docs/v1/tech/installation-guide/kubernetes/

Proxy servers can store cached copies of sites. You will get the data from the proxy when you access a particular location.

Sorry, no kub expert here. I'm not sure how to teardown just the database, but I assume you could write a script to connect to the backing database and drop the tables/schema, etc. That might be quicker than dropping the entire cluster.

If you figure out a better way, please share!

As of q4 2021, FusionAuth officially supports Kubernetes.

You can read the docs here: https://fusionauth.io/docs/v1/tech/installation-guide/kubernetes/