search

envoyproxy / gateway

Manages Envoy Proxy as a Standalone or Kubernetes-based Application Gateway
https://gateway.envoyproxy.io
Apache License 2.0
1.58k stars 341 forks source link

Support API Key Auth #2630

Open arkodg opened 8 months ago

arkodg commented 8 months ago 
          > @zhaohuabing can we reuse the same Envoy Filter for API key auth ?

The problem is, unlike HTTP Basic Auth, API key auth is much more flexible, the key can be in the header, path, or even body. I think we will need a dedicated envoy filter in Envoy if we want to support API key auth, we can follow the open API specs: https://swagger.io/docs/specification/authentication/api-keys/#:~:text=API%20keys%20are%20supposed%20to,mechanisms%20such%20as%20HTTPS%2FSSL.

Originally posted by @zhaohuabing in https://github.com/envoyproxy/gateway/issues/1660#issuecomment-1814974031

arkodg commented 8 months ago

blocked on upstream implementation in envoy

zufardhiyaulhaq commented 6 months ago

@arkodg do you know the upstream implementation envoy tracking?

zufardhiyaulhaq commented 6 months ago

I think this can be easily implemented by header or query matching right?

arkodg commented 6 months ago

cc @zhaohuabing

zhaohuabing commented 5 months ago

@arkodg @zufardhiyaulhaq It should be a simple Envoy Filter. I can pick it up when I get some bandwidth.

sanposhiho commented 3 weeks ago

/assign

missBerg commented 3 weeks ago

API Key Auth is also often related to a set of APIs that is accessible with that Key. Often stored elsewhere to determine if the resource (API) being accessed is allowed to be accessed with this Key.

What is the main purpose of this feature? To capture API key values for rate limiting only? Or to do AuthZ enforcement?

And how would we differentiate dynamically if an API key is subscribed to a higher rate limit than another API key?

gecube commented 2 weeks ago

@missBerg it is very essential feature for us stopping the adoption of envoy gateway. The primary idea is to use it as AuthZ. Regarding rate limits - we can support different scenarios. Probably starting from separate rate limit for each API key.

And how would we differentiate dynamically if an API key is subscribed to a higher rate limit than another API key?

It should not be an issue.

When the basic rate limiting would be implemented, complex scenarios could be considered (like common rate limit for API keys from one user).