Build Kubernetes-aware component to generate trusted assertion to proxy

[nhoughto]

Integrating with Inkfish via username/password and static configuration works but the ergonomics of managing and updating rules isn't great.

In a world where #18 and #20 are implemented there is an obvious next step to combine these two features in a Kubernetes specific way. A new component could be constructed as a kind of 'in cluster proxy' that really just collects cluster metadata, generates a trusted assertion of that metadata and forwards the request upstream to the real inkfish proxies to authenticate and service. This shouldn't really change any trust boundaries as the out-of-cluster inkfish is still doing the enforcement but will improve the developer experience as rules could be written with the context of Pod/Namespace/whatever metadata is collected rather than only the concept of EC2 instance or 'user' both of which aren't a great fit for Kubernetes resources.

[bls]

I think this is a good idea, we just have to be careful not to reinvent envoy/istio.

[nhoughto]

Simpler approach could be service account jwts and #20
not as transparent but less moving parts