[
https://issues.apache.org/jira/browse/FLINK-10497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flink Jira Bot updated FLINK-10497:
-----------------------------------
Labels: auto-deprioritized-major stale-minor (was:
auto-deprioritized-major)
I am the [Flink Jira Bot|https://github.com/apache/flink-jira-bot/] and I help
the community manage its development. I see this issues has been marked as
Minor but is unassigned and neither itself nor its Sub-Tasks have been updated
for 180 days. I have gone ahead and marked it "stale-minor". If this ticket is
still Minor, please either assign yourself or give an update. Afterwards,
please remove the label or in 7 days the issue will be deprioritized.
> More fine grained control over access to REST endpoints
> -------------------------------------------------------
>
> Key: FLINK-10497
> URL: https://issues.apache.org/jira/browse/FLINK-10497
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / REST
> Affects Versions: 1.7.0
> Reporter: Till Rohrmann
> Priority: Minor
> Labels: auto-deprioritized-major, stale-minor
>
> At the moment, the REST endpoint can be secured by configuring mutual
> authentication. This, however, defines the access for all available REST
> calls (reads as well as writes). In some situations, it is desired that only
> the writes calls are access restricted whereas the read accesses are
> permitted (e.g. no job submission but the web UI can display the cluster
> state).
> A solution could be to specify ACLs for the different REST calls. This would
> allow to disable state changing operations like cancelling a job from the web
> UI, for example. Moreover, it could allow to specify different rights for
> different users.
> An alternative could be to separate the REST calls relevant for the web UI
> (read operations) from the cluster state changing REST calls. By allowing
> different security configurations (e.g. endpoint with read operations is not
> secured whereas the endpoint with write operations is secured) one could
> effectively achieve the same.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
