geoctl

I don't think the point here is to fully replace deterministic with non-deterministic-based access control. The point is to combine the traditional manual/coarse-grained deterministic access control with an additional layer of dynamic, fine-grained non-deterministic access control.

Actually zero trust can be seen as an optimization problem, you almost certainly want to globally deny every single request, even for authenticated users under all circumstances to all resources, unless when "necessary", "necessary" here is the key because it needs to be as dynamic and as fine-grained as possible, context-based and scalable. For small businesses, RBAC and ACL rules can be fine, but for enterprises with thousands or tens of thousands of employees, contractors and now AI agents which need varying permissions to different resources at different times, you would have to define thousands or tens of thousands of rules that might conflict with one another and are hard to maintain. ABAC and policy-as-code can mitigate to a certain extent providing dynamic context-based fine-grained access control. But if you could gather as much information as possible about every user and every session, combine it with some boundary permissions and static rules, and feed it periodically to some reasoning engine that is tasked with dynamically increasing/decreasing permissions for each session based on all such info, you can keep your manual/static access control policies to a minimum and maybe even eliminate JIT in some cases. The real question is whether modern LLMs and transformers are the correct and optimal architecture for this problem in the first place.

I discovered this bash trick by chance when I was once trying to healthCheck the Envoy's official OCI image container which didn't include curl or wget while forcing the envoy admin interface to listen on localhost which breaks the traditional k8s httpGet checks.

Honestly I am happy that more remote access products are using QUIC, not WireGuard, for tunneling and realizing its technical benefits (e.g. AES hardware acceleration, dynamic endpoints, custom auth with JWT or mTLS, FIPS compliance, traffic masquerading as HTTP/3, etc.). I am a big fan of QUIC myself and I implemented it long ago in Octelium, which is a similar remote access product that's more centered around access control and zero trust rather than P2P connectivity. I believe QUIC should be the future of tunneling, especially when it comes to business and enterprise remote access use cases. Congrats on launching an I wish you the best of luck.