Issue after upgrading to CMF 2.4.2/CFK 3.3.0: FlinkApplication resolution fails cross-namespace FlinkEnvironment

Stream Processing
1

Hi everyone,

After upgrading Confluent Manager for Flink (CMF) from 2.3.2 to 2.4.2 and Confluent For Kubernetes (CFK) from 3.2.1 to 3.3.0, CFK fails to reconcile an existing FlinkApplication.

It seems to look for the FlinkEnvironment CR in the namespace where the FlinkApplication resides (report-local-test) instead of looking for it in the namespace where the FlinkEnvironment was actually deployed (confluent-platform).

Here is the relevant error log:

{
"level": "ERROR",
"time": "2026-09-17T13:42:36.299Z",
"name": "flinkapplication",
"caller": "log/log.go:53",
"msg": "FlinkEnvironment resolution failed",
"name": "basic-example",
"namespace": "report-local-test",
"flinkEnvironment": "report-local-test-env",
"error": "FlinkEnvironment "report-local-test-env" not found in namespace "report-local-test""
}

Has anyone encountered this issue or knows if there was a breaking change regarding cross-namespace resolution in CMF 2.4.2/CFK 3.3.0?

Thanks a lot for your time and help!

2

Hey, sorry that you are running into this.

That issue was caused by your CFK upgrade. We are (Confluent) are working on a fix in CMF 2.4.3 for this, so that you don’t have to downgrade CFK.

3

Please check this relevant documentation here Confluent for Kubernetes Release Notes | Confluent Documentation

4

Hi,

Thanks for the response!

That’s great news—we’re really looking forward to CMF 2.4.3. Restricting cross-namespace references breaks our current governance setup, so a fix on the CMF side will be a huge help.

Best of luck with the release!

5

Thanks for the explanation! I understand the Kubernetes ownerReference constraint for cascading deletes.

However, sacrificing cross-namespace isolation breaks standard RBAC multi-tenancy rules and breaks existing setups on upgrade. Introducing a constraint that forces a deployment redesign is, by definition, a breaking change.

Highlighting this trade-off clearly in the release notes—or allowing us to opt out of ownerReferences—would be a big help. Thanks again for addressing this in CMF 2.4.3!

6

Hi @TinyToons,

Thanks for the feedback, and sorry for the trouble this caused. I’ve raised it with the responsible team’s lead and with Product, and we’ve agreed to add an opt-out flag that restores the previous cross-namespace behaviour.

The fix will most likely ship in our next patch release. We don’t have an exact date yet, but we expect it around the end of Q4 (December). We’ll update this thread once it’s out.

In the meantime, could you tell us more about how your organisation handles deployment and multi-tenancy? For example, how you split namespaces between platform and tenant teams, and how your RBAC is set up. That would be really useful product feedback.

Thanks again!

7

Hi @rmetzger,
Do you have any EAT planned or available for CMF 2.4.3?
Thanks in advance! :blush:

8

This patch would go into client side i.e CFK 3.3.2 and higher version. Patch in CFK would work against CMF 2.4.3. Next patch release for CFK 3.3.2 would be in Q4, near December.

9

Hello,
FlinkEnvironments are located in the CFK namespace, while FlinkApplications are deployed within each client’s tenant namespace.
Two RBAC layers are involved: Kubernetes namespace-level RBAC and CMF RBAC. The latter is provided by the embedded MDS and is available as soon as CMF 2.4+ is deployed.