Support cross namespace secret references with a ReferenceGrant

[nfarhadian]

Description:
Cross namespace secret reference is not allowed in OIDC security policy, even with reference grant

I checked the code and allowCrossNamespace is "false"

gateway/internal/gatewayapi/securitypolicy.go

Line 1131 in 484e023

false, from, oidc.ClientSecret, resources); err != nil {

Since it's false, reference grant is not checked

gateway/internal/gatewayapi/validate.go

Line 920 in 484e023

if !allowCrossNamespace {

Environment:
v1.5.1

Logs:
OIDC: secret ref namespace must be unspecified/empty or .

[arkodg]

cc @zhaohuabing

[zhaohuabing]

We need to decide whether cross-namespace secret references should be allowed for Envoy Gateway APIs(e.g., for BasicAuth, OIDC, API key auth).

I lean toward only supporting secrets within the same namespace to keep things simple and avoid unnecessarily complexity.

@nfarhadian Why do you need cross-namespace secret references? Could they be in the same namespace as the SecurityPolicy?

[nfarhadian]

In our setup, each app team creates their own HTTPRoute in their namespace and we want them to have full control over their service. Having them create the route and then open a ticket for the DevOps team to add a SecurityPolicy elsewhere isn’t a great workflow. (And in that scenario there should be at least one ReferenceGrant per namespace)

Also, the generated CRD mention that cross-namespace references should work with ReferenceGrant, so it feels like there’s a gap between what the spec allows and what’s currently supported.

P.S. I know we could script around this, but ideally the workflow shouldn’t need extra tooling.

[zhaohuabing]

Having them create the route and then open a ticket for the DevOps team to add a SecurityPolicy elsewhere isn’t a great workflow. (And in that scenario there should be at least one ReferenceGrant per namespace)

Hi @nfarhadian does the DevOps team create the SecurityPolicy in another namespace but reference the client secret in the app namespace? In other words, are the owner of the client secret and the SecurityPolicy different?

[nfarhadian]

Yes, they are different in our case
OAuth client and client-secret is managed by the DevOps team

[zhaohuabing]

OAuth client and client-secret is managed by the DevOps team

Do you mean app team? Or am I miss something?

SecurityPolicy: DevOps team, created in another namespace
OAuth client and client-secret: App team, created in app namespace