janiussyafiq opened a new issue, #13005: URL: https://github.com/apache/apisix/issues/13005
### Current Behavior When a `key-auth` plugin is configured in a `consumer_group` and a `consumer` is attached to that group, the authentication fails with `"Invalid API key in request"` or `"Missing API key in request"` errors. The error log shows `failed to find consumer: Missing related consumer.` However, other plugins in the same `consumer_group` (like limit-count) work as expected. ### Expected Behavior When authentication plugins like `key-auth` are attached to a `consumer_group`, and consumers are assigned to that group, the authentication should work as if the plugin was directly configured on the consumer itself. The `consumer_group` should act as an abstraction layer where plugins from the group are effectively merged with the consumer's configuration. In other words, the following scenarios should be functionally equivalent: Scenario 1 (current approach - should work but doesn't): Consumer group with key-auth plugin → Consumer attached to group Scenario 2 (current workaround - works): Consumer with key-auth plugin directly configured ### Error Logs ``` 2026/02/11 08:19:20 [warn] 215879#215879: *3302542 [lua] key-auth.lua:86: find_consumer(): failed to find consumer: Missing related consumer, client: 127.0.0.1, server: _, request: "GET /internal HTTP/1.1", host: "127.0.0.1:9080", request_id: "4a5cd4ba972459d217c2317eba58f5b6" 2026/02/11 08:19:20 [warn] 215879#215879: *3302542 [lua] plugin.lua:1205: run_plugin(): key-auth exits with http status code 401, client: 127.0.0.1, server: _, request: "GET /internal HTTP/1.1", host: "127.0.0.1:9080", request_id: "4a5cd4ba972459d217c2317eba58f5b6" ``` ### Steps to Reproduce 1. Create a consumer group with both `limit-count` and `key-auth` plugins: ``` curl "http://127.0.0.1:9180/apisix/admin/consumer_groups"; -X PUT -d '{ "id": "basic_plan", "plugins": { "limit-count": { "count": 2, "time_window": 30, "rejected_code": 429 }, "key-auth": { "key": "john-key" } } }' -H "x-api-key: xxxxx" ``` 2. Create a consumer attached to the consumer_group: ``` curl "http://127.0.0.1:9180/apisix/admin/consumers"; -X PUT -d '{ "username": "johndoe", "group_id": "basic_plan" }' -H "x-api-key: xxxxx" ``` 3. Create a route with `key-auth` plugin enabled: ``` curl "http://127.0.0.1:9180/apisix/admin/routes"; -X PUT -d '{ "id": "rate-limiting", "uri": "/internal", "plugins": { "key-auth": {} }, "upstream": { "nodes": { "mock.api7.ai:443": 1 }, "pass_host": "node", "scheme": "https" } }' -H "x-api-key: xxxxx" ``` 4. Test the endpoint with the API key: ``` curl http://127.0.0.1:9080/internal -H "apikey: john-key" # Returns: {"message":"Invalid API key in request"} curl http://127.0.0.1:9080/internal # Returns: {"message":"Missing API key in request"} ``` Additional Context The issue appears to be that during the consumer lookup process, when an API key is provided, APISIX searches for a consumer directly associated with that key. Since the key-auth configuration is in the consumer_group rather than directly on the consumer object, the search fails to find a matching consumer. This is inconsistent because: 1. Rate limiting plugins (like limit-count) from the consumer_group work correctly 2. The consumer_group abstraction should transparently merge its plugins into the consumer's effective configuration This behavior limits the usefulness of consumer_groups for mixed authentication scenarios where you might want to centralize auth configuration across multiple consumers or combine authentication at both the consumer and consumer_group levels. ### Environment - APISIX version (run `apisix version`): latest version - Operating system (run `uname -a`): - OpenResty / Nginx version (run `openresty -V` or `nginx -V`): openresty/1.27.1.2 - etcd version, if relevant (run `curl http://127.0.0.1:9090/v1/server_info`): - APISIX Dashboard version, if relevant: - Plugin runner version, for issues related to plugin runners: - LuaRocks version, for installation issues (run `luarocks --version`): -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
