AlinsRan opened a new pull request, #2901:
URL: https://github.com/apache/apisix-ingress-controller/pull/2901
### Type of change:
- [x] Bugfix
- [ ] New feature provided
- [ ] Improve performance
- [ ] Backport patches
- [ ] Documentation
- [ ] Refactor
- [ ] Chore
- [ ] CI/CD or Tests
### What this PR does / why we need it:
When an ApisixRoute references an ApisixPluginConfig in another namespace
via `plugin_config_namespace`, the plugin config's `secretRef` was loaded from
the **route's** namespace:
```go
// internal/controller/apisixroute_controller.go (validatePluginConfig)
if err := r.validatePlugins(tctx, in, pc.Spec.Plugins); err != nil {
// validateSecrets
Namespace: in.Namespace,
```
while the translator looks it up in the **plugin config's** namespace:
```go
// internal/adc/translator/apisixroute.go (loadPluginConfigPlugins)
config, err := t.buildPluginConfig(plugin, pc.Namespace, tctx.Secrets)
```
The Secret index (`ApisixPluginConfigSecretIndexFunc`) and the Secret watch
also key on the plugin config's namespace, so only the loader was inconsistent.
As a result, for a route in `ns-b` using a plugin config in `ns-a`:
- if `ns-b` had a same-named Secret, the route was accepted but the Secret
values were silently missing from the plugin config sent to APISIX;
- otherwise the route was rejected with `failed to get Secret: ns-b/<name>`,
although the Secret exists in `ns-a`.
This PR passes the namespace explicitly to `validatePlugins` /
`validateSecrets`: the route's own plugins still resolve in the route's
namespace, and the plugin config's plugins resolve in the plugin config's
namespace.
Behavior change: a cross-namespace route now requires the Secret to exist in
the plugin config's namespace, which is where it was always read from during
translation. Same-namespace setups are unaffected.
Fixes #2896
### Pre-submission checklist:
- [x] Did you explain what problem does this PR solve? Or what new features
have been added?
- [x] Have you added corresponding test cases?
- [ ] Have you modified the corresponding document?
- [x] Is this PR backward compatible? **If it is not backward compatible,
please discuss on the [mailing
list](https://github.com/apache/apisix-ingress-controller#community) first**
--
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]
