Jamil

> If we can somehow avoid it, I would really love to not having to track this. Everything on the Gateway so far is centered around resources and not flows...

> I think the confusing thing here is that there is already the possibility that more than one policy grants access. How do we pick which one? Given that you...

> My concern here is correctness: Track TCP state is difficult and we should limit the logic we are using here to an absolute minimum and instead just record packets...

#### Schema (authorize_flow) ``` { "stats": { "tx_count": 12, "rx_count": 10, "tx_bytes": 1123, "rx_bytes": 5432, }, "flow": { "flow_start": timestamp, "flow_end": timestamp, "client_id": 1234, "resource_id": 4321, "inner_src_ip": "100.100.100.100", "inner_src_port": 50000,...

I don't see how this won't be the case though? STUN doesn't make sense in the context of routing packets to the Gateway first, right? Should I expect the Gateway...

This could likely be solved by ensuring the masquerade rule uses a deterministic source port.

~~Actually for Google Workspace I think we can stick to personal tokens since they don't expire, and the service account requires an impersonation email anyhow.~~ Scratch that - we can...

Yeah this is still relevant: - Okta will use a service app the customer provisions in their tenant - Google will use our public service account - Entra won't use...

Unfortunately `alien` isn't helpful in this case:

Is there another plan in place for supporting RPM-based distros? Since this was a direct ask from a couple folks, should we retitle this back to `Support RPM distros` and...