shreemaan-abhishek opened a new pull request, #2805:
URL: https://github.com/apache/apisix-ingress-controller/pull/2805
### What this fixes
A `v1alpha1` `Consumer` credential's `secretRef` carries a caller-settable
`namespace`:
```go
type SecretReference struct {
Name string `json:"name"`
Namespace *string `json:"namespace,omitempty"`
}
```
`ConsumerReconciler.processSpec` honored that namespace and read the Secret
with the controller's cluster-wide `secrets` RBAC, with **no `ReferenceGrant`
check**. A user who can only `create consumers` in namespace A could therefore
name `namespace-B/some-secret` and have the controller resolve it and bind that
foreign namespace's auth material (key-auth keys, basic-auth passwords, JWT
secrets, HMAC keys) into a Consumer identity they own. That is a
cross-namespace confused-deputy: the caller never had `get secrets` in
namespace B, but the controller does.
The route controllers (`httproute`, `grpcroute`, `tcproute`, `udproute`,
`tlsroute`) and the Gateway listener CA refs already gate cross-namespace
references through `checkReferenceGrant`. The Consumer path was the one auth
pathway that did not. Note the `v2` `ApisixConsumer` API is structurally
namespace-locked (`LocalObjectReference`, no namespace field), so only
`v1alpha1` was affected.
### The fix
Enforce `checkReferenceGrant` before dereferencing a cross-namespace
Consumer `secretRef`, exactly as the route controllers do. Same-namespace refs
are unaffected (the check short-circuits). When no grant permits the reference,
the reconcile refuses it and surfaces the error on the Consumer status, so the
foreign Secret is never loaded or bound.
### Tests
`internal/controller/consumer_controller_test.go` locks the invariant:
- cross-namespace `secretRef` without a `ReferenceGrant` -> refused, secret
not loaded
- cross-namespace `secretRef` with a matching `ReferenceGrant` -> permitted
- same-namespace `secretRef` -> permitted, no grant needed
```
go test ./internal/controller/ -run TestProcessSpec
```
--
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]