fix(admin): duplicate consumer authentication keys are silently accepted#13529
Merged
nic-6443 merged 6 commits intoJul 17, 2026
Merged
Conversation
nic-6443
marked this pull request as ready for review
June 11, 2026 13:21
There was a problem hiding this comment.
Pull request overview
This PR adds Admin API write-time validation to prevent duplicate unique-key attributes used by auth plugins (e.g., key-auth.key, basic-auth.username) across consumers and credentials, avoiding ambiguous runtime consumer matching where the “last loaded wins”.
Changes:
- Add etcd-backed duplicate-key detection (with data_encryption decrypt support and secret-ref skip behavior) for consumer/credential writes.
- Pass
sub_paththrough the admin resource checker pipeline so credential writes can determine owning consumer. - Extend Admin API tests to cover duplicate rejection cases (including encrypted stored configs).
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
apisix/consumer.lua |
Implements duplicate-key scan by reading /consumers from etcd and comparing decrypted stored plugin conf values. |
apisix/admin/resource.lua |
Threads sub_path into checker options so sub-resources (credentials) can validate with owner context. |
apisix/admin/credentials.lua |
Runs duplicate-key validation on credential PUT using sub_path to extract consumer name. |
apisix/admin/consumers.lua |
Runs duplicate-key validation on consumer PUT. |
t/admin/credentials.t |
Adjusts an existing basic-auth username and adds credential-focused duplicate-key test coverage. |
t/admin/consumers.t |
Adds consumer-focused duplicate-key tests, including encrypted storage scenarios. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
AlinsRan
reviewed
Jul 8, 2026
skip_references_check guards the checks that require the referenced resource to exist (consumer group, upstream, etc.), which must be skipped when validating a config bundle whose references may live in the same payload. The duplicate key check is not a reference check, so it should not be gated by this flag.
ldap-auth also matches the consumer by a unique key attribute at runtime (user_dn), so duplicating it across consumers has the same last-loaded-wins ambiguity. Also make the duplicate-check tests wait deterministically until the local consumer watcher has synced the previous write (polling find_consumer instead of relying on restart timing or a fixed sleep), since the check runs against the locally synced consumer data.
AlinsRan
approved these changes
Jul 16, 2026
membphis
approved these changes
Jul 16, 2026
shreemaan-abhishek
approved these changes
Jul 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The Admin API accepts two different consumers (or credentials) configured with the same authentication key, e.g. two consumers with an identical
key-authkey. At runtime, consumer matching builds akey -> consumermap, so the last loaded consumer silently wins and traffic is attributed to an arbitrary one of them — identity, quotas and ACLs all follow the wrong consumer. The root cause is that there is no write-time validation of key uniqueness.This PR revives the approach from #12040 (write-time checking, as endorsed in the issue discussion): on consumer and credential create/update, the Admin API rejects the write with
400when the same unique key of an auth plugin (key-authkey,basic-authusername,jwt-authkey,hmac-authkey_id,ldap-authuser_dn) is already used by another owner. Re-PUT of the same owner with an unchanged key stays allowed.The check runs against the locally watched
/consumersdata viaconsumer.find_consumer()— the same view the runtime uses for auth matching — so it answers exactly the question "would this key collide at runtime", and it costs no etcd read on the write path. Since the watcher decrypts plugin conf during config sync, the comparison also works whendata_encryptionis enabled.Notes on scope:
$secret://,$env://) in the incoming conf are skipped, since they cannot be resolved at write time.t/admin/credentials.trelied on such a duplicate and was adjusted accordingly.Which issue(s) this PR fixes:
Fixes #11197
Checklist