You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 9, 2024. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: