AlinsRan commented on issue #2896:
URL:
https://github.com/apache/apisix-ingress-controller/issues/2896#issuecomment-6077563708
Thanks for the detailed report, your analysis is correct.
The controller loads the plugin config's `secretRef` using the ApisixRoute's
namespace:
```go
// internal/controller/apisixroute_controller.go
func (r *ApisixRouteReconciler) validatePluginConfig(...) error {
...
if err := r.validatePlugins(tctx, in, pc.Spec.Plugins); err != nil { //
`in` is the ApisixRoute
...
}
func (r *ApisixRouteReconciler) validateSecrets(tctx
*provider.TranslateContext, in *apiv2.ApisixRoute, secretRef string) error {
...
secret = corev1.Secret{ObjectMeta: metav1.ObjectMeta{Name: secretRef,
Namespace: in.Namespace}}
```
The translator then looks it up using the ApisixPluginConfig's namespace and
skips the merge without an error when it is not found:
```go
// internal/adc/translator/apisixroute.go
config, err := t.buildPluginConfig(plugin, pc.Namespace, tctx.Secrets)
```
So for a route in `ns-b` using `ns-a/shared-config`:
- if `ns-b/my-secret` exists, the route is accepted but the plugin config is
pushed without any of the Secret's values;
- if it does not exist, the route is rejected with `failed to get Secret:
ns-b/my-secret`, even though `ns-a/my-secret` exists.
The fix is in #2901: the plugin config's secrets are now loaded from the
plugin config's namespace. The route's own plugins still resolve secrets in the
route's namespace. After this change, a cross-namespace route needs the Secret
to exist in the ApisixPluginConfig's namespace, as you expected.
--
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]
