fix(helm): resolve RBAC permissions for namespaced gateway sources

[u-kai]

What does it do ?

This PR resolves RBAC permission issues when using Gateway API sources with namespaced: true configuration in the Helm chart.
It implements proper conditional RBAC creation that supports both same-namespace and cross-namespace gateway access scenarios while maintaining backward compatibility.

Motivation

Fixes #5300 - Gateway API sources require ClusterRole permissions when using namespaced: true, but the current implementation creates insufficient Role permissions, causing external-dns to fail with RBAC errors.

Problem: When namespaced: true is set with gateway sources, external-dns needs:

• Namespace informer access (ClusterRole for namespaces resource)
• Gateway resource access (varies based on gatewayNamespace configuration)

Root Cause: The namespace informer uses NamespacesFromSelector functionality which requires cluster-wide namespace access, but namespaced: true only creates Role permissions.

Solution

Implements Split RBAC approach with conditional logic:

Scenarios Supported:

1. namespaced=false + gateway sources → ClusterRole with all permissions
2. namespaced=true + gateway sources + no gatewayNamespace → Main Role (with gateway permissions) + ClusterRole for namespaces
3. namespaced=true + gateway sources + gatewayNamespace specified → Main Role + ClusterRole for namespaces + Cross-namespace Gateway Role
4. namespaced=false/true + no gateway sources → Standard behavior (unchanged)

More

• Yes, this PR title follows Conventional Commits
• Yes, I added unit tests
• Yes, I updated end user documentation accordingly

[k8s-ci-robot]

Hi @u-kai. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ivankatliarchuk]

Not sure if this is the correct solution. Why gateway have a distinct flag, when rest of the sources rely on --namespace ? Is there is a specific reason or a mistake?

[ivankatliarchuk]

I think one of the issues is, that Gateway actually uses --gateway-namespace when it should be unified and --namespace is just enough. This is just a confusion.

[u-kai]

@ivankatliarchuk
Thanks for the feedback!

The separate --gateway-namespace flag aligns with Gateway API's design for cross-namespace routing, where Gateways (often managed by cluster operators) and Routes (managed by app teams) typically reside in different namespaces.

The flag already exists in the external-dns, so this change maintains consistency with the existing CLI interface while fixing the RBAC permissions for namespaced deployments.

[ivankatliarchuk]

/ok-to-test

[ivankatliarchuk]

I found an initial PR #2292

As short term it seems like a fix. But not clear

Long term solutions are

• Watch all or multiple namespaces --namespace should accept a list of values #5263
• Per source configurations Consider adding per source configurations #5397

In my opinion, if --namespace is set, only resouces in this exact namespace should be watched. If there are cross-namespace resource references (it should be ignored with a message that the resource is outside of current namespace scope), it should be either all namespaces or we need to add multiple namespace support.

[ivankatliarchuk]

Related issues:

• "failed to sync *v1.Namespace: context deadline exceeded" with gateway-httproute source #3537
• failed to sync *v1alpha3.Gateway: context deadline exceeded #4901
  It could be that we need to review documentation as well

[u-kai]

@ivankatliarchuk
I agree that supporting multiple namespaces with the --namespace option would be a valuable improvement in the long term.

That said, I’d like to clarify one point — does this proposal also imply deprecating or integrating the --gateway-namespace option?

If so, my personal opinion is that --gateway-namespace still has value and should remain.
When supporting multiple namespaces, we’ll likely need to create one informer per namespace. Without a --gateway-namespace option, we wouldn't know which namespace the Gateway actually exists in, which could result in unnecessary informer overhead, especially when the Gateway is deployed in a single, shared namespace (as is often the case in common Gateway setups).

In such cases, having a dedicated --gateway-namespace provides a useful optimization and avoids wasteful resource watching.

So in conclusion, I’m in favor of enabling multi-namespace support for --namespace, but I think retaining --gateway-namespace is also beneficial from a performance and configuration clarity standpoint.

[ivankatliarchuk]

@mloiseleur wdyt?

[mloiseleur]

In External DNS doc on flags, it says:

• --namespace: Limit resources queried for endpoints to a specific namespace (default: all namespaces)
• --gateway-namespace: Limit Gateways of Route endpoints to a specific namespace (default: all namespaces)

With current state of External DNS, this PR looks valid to me. It allows user to use the same namespace or different namespace, with similar names between the binary and the chart. For instance, a user may want to use external dns CRD on external-dns namespace and Gateway on gateway namespaces.

@ivankatliarchuk An answer to your idea would be to implement a --namespaces options, allowing to set multiple namespaces. Then it would make sense to remove specific namespace options tailored for a specific source. But that's clearly beyond the scope of this PR.

[mloiseleur]

@u-kai About the implementation, why are you adding a specific ClusterRole and ClusterRoleBinding ? Wouldn't it be simpler to use the same CR & CRB with just extended required permissions ?

[ivankatliarchuk]

Make sense

[u-kai]

@mloiseleur
Thank you for the feedback!

Let me explain the implementation. For namespaced: true configurations, multiple Role/ClusterRole resources are necessary for the following reasons:

Technical Requirements:

1. Base Permissions - When namespaced: true, typically a Role (not ClusterRole) is created for namespace-scoped permissions
2. Namespace Informer - When using Gateway API sources like HTTPRoute, cluster-wide namespace read access is required for the NamespacesFromSelector functionality
3. Principle of Least Privilege - We should only grant permissions when actually needed:

• namespaced: true → base permissions via Role
• Gateway API sources → additional ClusterRole for namespace access only when used

4. Cross-namespace Gateway - In practice, Gateways often exist in different namespaces than Routes (e.g., infrastructure namespace vs application namespace). When users desire this setup (e.g., gatewayNamespace: default), a separate Role is needed for cross-namespace access

Implementation Approach:

• Base permissions: Role (when namespaced)
• Namespace access: ClusterRole (only when Gateway sources are used)
• Cross-namespace Gateway: Role in target namespace (only when specified)

This design grants exactly the permissions needed for each scenario while maintaining security isolation.

[mloiseleur]

/assign @stevehipwell
for review

[stevehipwell]

Thanks for the PR @u-kai. I've added a comment suggesting an improvement but as I'd like to include this in the next release we can leave that for the next time we need to make changes.

/approve

[stevehipwell]

Why not use hasPrefix in a range loop so the code is less likely to need updating in the future?

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: stevehipwell

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• charts/OWNERS [stevehipwell]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[stevehipwell]

@mloiseleur @ivankatliarchuk could one of you please add the LGTM if you're happy with this?

[ivankatliarchuk]

/lgtm