Github user tgravescs commented on the issue:
https://github.com/apache/spark/pull/17582
Sorry again the wording above and all the different configs are a bit
confusing to me as to what the real issues are here.
>Here actually has two list of acls, one is controlled by
spark.acls.enabled, if user "A" is not added
to this acl list, then user "A" cannot see the app list
(/<history-server-url>/api/v1/applications). But if this app is run by user
"A", then user "A" could still see the details of app, like
(/<history-server-url>/api/v1/applications/<app-id>/jobs), this acl is
controlled by "spark.history.ui.acls.enabled", and user "A" is automatically in
the acl list (because of run by him).
You are mixing things here. You say that if user "A" is not added to acl
list he cannot see the app list. This is broken then and I assume only applies
to rest api not UI? But I'm not sure what that has to do with your second
sentence, if user "A" ran the app then of course he can see the details of the
app, that is intended. I'm not sure what that has to do with the first issue?
If you don't have spark.history.ui.acls.enabled then it is up to what the user
set. Generally in any secure environment you should set
spark.history.ui.acls.enabled=true and it should enforce acls no matter what
user set. It might help for you to describe these in terms of configs. Which
exact configs are set on the history server and which exact configs are set on
the application side and which exact apis are being used (Rest vs Web UI).
so all the urls you list are the REST API, is this only an issue with rest
api or the actual web UI as well? It sounds like things are definitely broke
there but I'm not sure it requires changing the configs just fixing the things
that are broken.
Its supposed to be that if spark.history.ui.acls.enable is enabled it
doesn't matter what the setting of spark.acls.enable is, acls should always be
enforced on the history server. see the description:
https://spark.apache.org/docs/latest/monitoring.html
Certain UI's don't have information that should be sensitive. I thought the
list of applications was one of those things, all users should be able to see
the entire list of applications. Nothing sensitive there, but once you look at
the application details that should be acl'd. If someone added something
sensitive then it should be protected or it should be moved from that page.
My opinions on your response to @vanzin
1. No, there shouldn't be sensitive information there and many times a user
is looking for a job run by say a headless user or other user. I guess you
could filter only the jobs that user has acls to but that makes it more
complicated. Do you have a concrete reason it should be protected? Note that
this follow how other Hadoop UI's work.
2. That is just broken, event log should be protected.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
