I asked this in the mailing list as well, but trying my luck here. I have a standalone Flink cluster which I have started using the jobmanager.sh and taskmanager.sh scripts. For security reasons, I wanted to disable the submit and cancel jar features from the web ui but keep them enabled from the REST API so that my application can submit jars. But when I set web.submit.enable: false, my /jars API doesnt work over REST as well. Not sure if /jars/upload will work too, but I have seen that other /jobs, /overview etc are still working. The documentation says that in session mode REST API will continue to work. Is my understanding correct?

there might be some confusion about Flink cluster’s behavior, especially when distinguishing between the web UI and the REST API functionalities. The property web.submit.enable does control whether jobs can be submitted or cancelled via the web interface. However, it appears it can also impact the /jars endpoint when accessed through the web UI and potentially through the REST API in some setups, which might not be entirely clear from the documentation. This could be due to the fact that uploading a JAR effectively allows for job submission, hence the restriction applies. To clarify, Flink differentiates between its web UI (typically accessed via HTTP/HTTPS on port 8081 by default) and the REST API (which shares similar endpoints but is accessed separately, often on port 8081 as well but under the /api path). If your intention is to disable job submission and cancellation only from the web UI while keeping these functionalities available via the REST API, the current configuration options might not provide a straightforward way to do this, primarily because of the tight coupling between UI actions and the underlying REST endpoints they utilize. Given this, a couple of potential workarounds or solutions could be considered: 1. Network-Level Restrictions: Implement network-level rules or a reverse proxy setup that blocks access to specific UI paths (like job submission and cancellation URLs) while allowing unrestricted access to the REST API endpoints. This is more of an infrastructure-level solution and requires careful configuration to ensure proper functioning without unintended side effects. 2. Use Flink’s Security Features: Leverage Flink’s built-in security features such as authentication and authorization to restrict who can perform certain operations. While this won’t directly disable UI-based submissions without affecting the REST API, it can limit access to trusted users or services that interact with Flink programmatically. I think achieving more control might require a modification of Flink source.

Thanks a lot, it makes sense. Authentication is something I am looking at to prevent such situations. But would have been better if Flink had different ports/connectors for REST and WebUI. If that was the case, I could have applied a Kubernetes network policy on the WebUI port. Or infact not exposed that port on my service.

I suppose you could consider a lightweight service mesh like linkerd2 with mTLS.