api: HTTP APIKey Auth Filter

[sanposhiho]

This PR adds the API for HTTP APIKey Auth Filter that is proposed at #34877 and envoyproxy/gateway#2630.

Commit Message: api: HTTP APIKey Auth Filter
Risk Level: Low (only API)
Testing: WIP (will be done after we agree on the API)
Docs Changes: WIP
Release Notes: WIP
Platform Specific Features: No
Part of: #34877

[repokitteh-read-only]

Hi @sanposhiho, welcome and thank you for your contribution.

We will try to review your Pull Request as quickly as possible.

In the meantime, please take a look at the contribution guidelines if you have not done so already.

🐱

Caused by: #36709 was opened by sanposhiho.

see: more, trace.

[repokitteh-read-only]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @mattklein123
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #36709 was opened by sanposhiho.

see: more, trace.

[sanposhiho]

/cc @wbpcode @arkodg @zhaohuabing @missBerg

[wbpcode]

/assign

[mattklein123]

Can we potentially just include this functionality in the basic auth filter? We could have config in that filter to use different header names, etc. It seems not needed to have a new filter for this?

/wait

[wbpcode]

Can we potentially just include this functionality in the basic auth filter? We could have config in that filter to use different header names, etc. It seems not needed to have a new filter for this?

/wait

Basically, they have different logic and configuration format. Or we need to extend the meaning of basic_auth...

[mattklein123]

Basically, they have different logic and configuration format. Or we need to extend the meaning of basic_auth...

The logic is basically identical just swapping out different header names. Doesn't seem worth it to have a new filter just to have different header names. Is there anything else different?

[wbpcode]

Basically, they have different logic and configuration format. Or we need to extend the meaning of basic_auth...

The logic is basically identical just swapping out different header names. Doesn't seem worth it to have a new filter just to have different header names. Is there anything else different?

Both the configration parsing and verification is a little different, although we can abstract them by a virtual interface. 🤔

[sanposhiho]

I agree there's some similarity though, wouldn't it be weird to implement the features proposed here into BasicAuth filter since the responsibility of the filter would no longer be "Basic Auth"?

[wbpcode]

I agree there's some similarity though, wouldn't it be weird to implement the features proposed here into BasicAuth filter since the responsibility of the filter would no longer be "Basic Auth"?

Yeah, API Key Auth and Basic Auth are different authentication approaches. Or we need to extend the meaning of the basic_auth filter.
I will prefer to make this an independent filter.

If we insist on to merge them to one, then I think we need to document this very clear in the document of basic auth filter that the filter is not only be used for Basic Auth.

cc @mattklein123 WDYT

[zhaohuabing]

While basic authentication and API key authentication share some similarities, their authentication logic is fundamentally different:

• Basic Auth authenticates a user by verifying both the username and password against a configured user list.
• API Key Auth, on the other hand, authenticates a client by matching the API key provided in the request with a pre-configured list of valid keys.

From a UI perspective, it would also be clearer to separate these two methods into different APIs, as they serve distinct purposes and follow different workflows.

Some existing arts in this area:

• Nginx implements Basic Auth and API key auth as different APIs:
  • Basic Auth: https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/
  • API Key Auth: https://docs.nginx.com/nginx-management-suite/acm/how-to/policies/apikey-authn/
• APISIX implements Basic Auth and API key auth as different Plugins
  • Basic Auth: https://apisix.apache.org/docs/apisix/next/plugins/basic-auth/
  • API Key Auth: https://apisix.apache.org/docs/apisix/2.13/plugins/key-auth/

[zhaohuabing]

I suggest removing this at the first run. We can use a metadata to pass it(username or clientid) to later filters if it's required in the future.

[mattklein123]

OK fair enough we can do different filters.

[sanposhiho]

Will make it ready for review again when the implementation is ready.

[sanposhiho]

Discussed with @wbpcode.
Given I'm busy right now towards the upcoming K8s code freeze and I won't be able to take time for this until Kubecon NA is over, I converted this PR to the API-only one, and will pass the implementation part over to @wbpcode.

Thanks @wbpcode for the help!

[sanposhiho]

Updated the PR description + the title

[repokitteh-read-only]

CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to (bazel/.*repos.*\.bzl)|(bazel/dependency_imports\.bzl)|(api/bazel/.*\.bzl)|(.*/requirements\.txt)|(.*\.patch).
envoyproxy/dependency-shepherds assignee is @mattklein123

🐱

Caused by: #36709 was synchronize by wbpcode.

see: more, trace.