Copilot commented on code in PR #2806:
URL:
https://github.com/apache/apisix-ingress-controller/pull/2806#discussion_r3602360631
##########
internal/webhook/v1/consumer_webhook.go:
##########
@@ -134,6 +134,14 @@ func (v *ConsumerCustomValidator) collectWarnings(ctx
context.Context, consumer
}
visited[nn] = struct{}{}
+ // Don't probe cross-namespace Secrets that no ReferenceGrant
permits: the
+ // found/not-found warning difference would leak Secret
existence across
+ // namespaces. Emit a uniform message and skip the lookup.
+ if namespace != defaultNamespace &&
!controller.CheckConsumerSecretRef(ctx, v.Client, defaultNamespace, nn) {
+ warnings = append(warnings, fmt.Sprintf("Referenced
Secret '%s/%s' is not accessible from this Consumer without a ReferenceGrant",
nn.Namespace, nn.Name))
+ continue
+ }
Review Comment:
The new gate correctly avoids emitting found/not-found warnings for
cross-namespace SecretRefs without a permitting ReferenceGrant, but
cross-namespace Secret probing can still occur later in validation via
validateDuplicateKeyAuthCredentials → extractCredentialKey: for `key-auth`
credentials that use `secretRef`, the webhook still does a `v.Client.Get()`
against the referenced Secret (including cross-namespace) and can return a
different *error outcome* depending on whether the Secret exists/contains a
colliding key. That means a cross-namespace existence/value oracle may still be
possible even when this warning path is uniform.
To fully suppress the oracle, consider applying the same
`CheckConsumerSecretRef` gate before any Secret `Get` in validation (e.g., in
`extractCredentialKey`, if secretRef namespace != consumer namespace and not
grant-permitted, skip the `Get` and treat it as missing). Adding a focused test
for a `key-auth` credential with a cross-namespace `secretRef` (with and
without a ReferenceGrant) would help prevent regressions.
--
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]
