[
https://issues.apache.org/jira/browse/MESOS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15382804#comment-15382804
]
Zhitao Li edited comment on MESOS-5851 at 7/18/16 6:37 PM:
-----------------------------------------------------------
[~adam-mesos], the challenging I see about realm is exactly about grouping:
1) Can we come up with a reasonable set of realms to cover all our endpoints?
2) I assume this grouping needs to be mutually exclusive (e.g. one endpoint
cannot be in multiple realms). How does composite endpoint like {{/state}} or
{{/state-summary}} falls into this remains interesting, and what about API
endpoints like {{/v1/operator}}?
3) How much operators need to understand the realms? Most operators can easily
know which endpoint is being used by what tool/workflow, since HTTP requests
are easily logged or sniffed if necessary, but many operators probably don't
even remember the full list of the constant growing/changing list of endpoints,
not to mention the additional mapping from endpoints to realms;
4) future proof: does this mean we need to explicitly think and decide which
realm an endpoint should belong to? And do we need to publish and maintain this
mapping?
If all the concerns can be addressed or proven not real, then I'm happy for the
proposal.
was (Author: zhitao):
[~adam-mesos], the challenging I see about realm is exactly about grouping:
1) Can we come up with a reasonable set of realms to cover all our endpoints?
2) I assume this grouping needs to be mutually exclusive (e.g. one endpoint
cannot be in multiple realms). How does composite endpoint like {{/state}} or
{{/state-summary}} falls into this remains interesting, and what about API
endpoints like {{/v1/operator}}?
3) How much operators need to understand the realms? Most operators can easily
know which endpoint is being used by what tool/workflow, since HTTP requests
are easily logged or sniffed if necessary, but many operators probably don't
even have a full list of the constant growing/changing list of endpoints, not
to mention the mapping from endpoints to realms;
4) future proof: does this mean we need to explicitly think and decide which
realm an endpoint should belong to? And do we need to publish and maintain this
mapping?
If all the concerns can be addressed or proven not real, then I'm happy for the
proposal.
> Create mechanism to control authentication between different HTTP endpoints
> ---------------------------------------------------------------------------
>
> Key: MESOS-5851
> URL: https://issues.apache.org/jira/browse/MESOS-5851
> Project: Mesos
> Issue Type: Bug
> Components: libprocess
> Affects Versions: 1.0.0
> Reporter: Zhitao Li
> Labels: mesosphere, security
>
> All endpoints authentication is controlled by one single flag. We need this
> flag to be on so that `/reserve` `/unreserve` can get a principal.
> However, after 1.0, we cannot access important readonly endpoints
> `/master/state/` and `/metric/snapshot/` anymore w/o a password. The latter
> is detrimental on usability because many users don't have the supporting
> infra to distribute such metrics into every metrics collecting process yet.
> I'm looking towards a mechanism to at least allow unauthenticated access to
> selective whitelisted endpoints while keep endpoints requiring AuthN/AuthZ
> still protected.
> quoting Joseph Wu, "we want a `--authenticate_http=true, but don't check`
> option"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
