[jira] [Comment Edited] (MESOS-5851) Create mechanism to control authentication between different HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385416#comment-15385416
]
Adam B edited comment on MESOS-5851 at 7/20/16 6:05 AM:
We've never actually supported multiple `\-\-http_authenticators` before
(despite the flag name), and I imagine it being more applicable to something
like scheduler API vs operator API, but we've already got
`\-\-http_framework_authenticators` for the scheduler API. I can't imagine
wanting to authenticate both RO and RW but use different authenticators for
each. Let's leave that alone for now too.
was (Author: adam-mesos):
We've never actually supported multiple `--http_authenticators` before (despite
the flag name), and I imagine it being more applicable to something like
scheduler API vs operator API, but we've already got
`--http_framework_authenticators` for the scheduler API. I can't imagine
wanting to authenticate both RO and RW but use different authenticators for
each. Let's leave that alone for now too.
> 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
>Assignee: Zhitao Li
> Labels: mesosphere, security
> Fix For: 1.0.0
>
>
> 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"
> Proposed endpoint to realm grouping by [~zhitao]
> {quote}
> /
> // Common realms shared by both master and agent
>
> FLAGS
> - /flags
>
> FILES
> - /files/browse
> - /files/browse.json
> - /files/debug
> - /files/debug.json
> - /files/download
> - /files/download.json
> - /files/read
> - /files/read.json
>
> LOGGING
> - /logging/toggle
>
> METRICS
> - /metrics/snapshot
>
> PROFILER
> - /profiler/start
> - /profiler/stop
>
> SYSTEMS
> - /system/stats.json
>
> VERSIONS
> - /version
>
> /
> // Additional master only realms
>
> MAINTENANCE
> - /machine/down
> - /machine/up
> - /maintenance/schedule
> - /maintenance/status
>
> OPERATORS
> - /api/v1
>
> SCHEDULERS
> - /api/v1/scheduler
>
> REGISTRARS
> - /registrar(id)/registry
>
> RESERVATIONS
> - /reserve
> - /unreserve
> - /quota
> - /weights
>
> TEARDOWN
> - /teardown
>
> VIEWS
> - /frameworks
> - /roles
> - /roles.json
> - /slaves
> - /state
> - /state-summary
> - /state.json
> - /tasks
> - /tasks.json
>
> VOLUMES
> - /create-volumes
> - /destroy-volumes
>
> UNAUTHENTICATED
> - /health
> - /redirect
>
>
> // Additional agent realms
>
>
> OPERATORS
> - /api/v1
>
> VIEWS
> - /containers
> - /monitor/statistics
> - /monitor/statistics.json
> - /state
> - /state.json
>
> UNAUTHENTICATED
> - /api/v1/executor
> - /health
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5851) Create mechanism to control authentication between different HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385307#comment-15385307
]
Zhitao Li edited comment on MESOS-5851 at 7/20/16 4:38 AM:
---
[~adam-mesos] I'll start to work on RR drafts from master side.
About `\-\-http_authenticators` flag change: do we expect people use different
authenticator implementations between `READ_ONLY` and `READ_WRITE`? It seems
very strange anyone would actually do that. If not, we can probably reduce the
changes we need for this. (If you think it's definitely necessary, then I
propose we make the flags symmetric to `\-\-authenticate_http_readonly` by
adding `--http_authenticators_readonly`)
was (Author: zhitao):
[~adam-mesos] I'll start to work on RR drafts from master side.
About `--http_authenticators` flag change: do we expect people use different
authenticator implementations between `READ_ONLY` and `READ_WRITE`? It seems
very strange anyone would actually do that. If not, we can probably reduce the
changes we need for this. (If you think it's definitely necessary, then I
propose we make the flags symmetric to `--authenticate_http_readonly` by adding
`--http_authenticators_readonly`)
> 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
>Assignee: Zhitao Li
> Labels: mesosphere, security
> Fix For: 1.0.0
>
>
> 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"
> Proposed endpoint to realm grouping by [~zhitao]
> {quote}
> /
> // Common realms shared by both master and agent
>
> FLAGS
> - /flags
>
> FILES
> - /files/browse
> - /files/browse.json
> - /files/debug
> - /files/debug.json
> - /files/download
> - /files/download.json
> - /files/read
> - /files/read.json
>
> LOGGING
> - /logging/toggle
>
> METRICS
> - /metrics/snapshot
>
> PROFILER
> - /profiler/start
> - /profiler/stop
>
> SYSTEMS
> - /system/stats.json
>
> VERSIONS
> - /version
>
> /
> // Additional master only realms
>
> MAINTENANCE
> - /machine/down
> - /machine/up
> - /maintenance/schedule
> - /maintenance/status
>
> OPERATORS
> - /api/v1
>
> SCHEDULERS
> - /api/v1/scheduler
>
> REGISTRARS
> - /registrar(id)/registry
>
> RESERVATIONS
> - /reserve
> - /unreserve
> - /quota
> - /weights
>
> TEARDOWN
> - /teardown
>
> VIEWS
> - /frameworks
> - /roles
> - /roles.json
> - /slaves
> - /state
> - /state-summary
> - /state.json
> - /tasks
> - /tasks.json
>
> VOLUMES
> - /create-volumes
> - /destroy-volumes
>
> UNAUTHENTICATED
> - /health
> - /redirect
>
>
> // Additional agent realms
>
>
> OPERATORS
> - /api/v1
>
> VIEWS
> - /containers
> - /monitor/statistics
> - /monitor/statistics.json
> - /state
> - /state.json
>
> UNAUTHENTICATED
> - /api/v1/executor
> - /health
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5851) Create mechanism to control authentication between different HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385247#comment-15385247
]
Adam B edited comment on MESOS-5851 at 7/20/16 3:19 AM:
I like it.
As for the flags, here's my suggestion:
`\-\-authenticate_http` will become a deprecated alias for
`\-\-authenticate_http_readwrite` (since the old behavior applied to
reserve/unreserve, create/destroy, and teardown).
`\-\-authenticate_http_readonly` will be a new boolean flag for the VIEWS.
Note that `\-\-authenticate_http_frameworks` already exists for
`/v1/scheduler`. `/v1/` represents the operator API, and counts as readwrite.
`\-\-http_authenticators` needs to be updated as well, either to
`\-\-http_readwrite_authenticator` and `\-\-http_readonly_authenticator`, or to
handle a json blob specifying which authenticator to use for each realm.
We must continue to support the previous format as well, if specified, although
we'd probably error out if `\-\-authenticate_http_readonly` is set and
`\-\-http_authenticators` uses the old format.
was (Author: adam-mesos):
I like it.
As for the flags, here's my suggestion:
`--authenticate_http` will become a deprecated alias for
`--authenticate_http_readwrite` (since the old behavior applied to
reserve/unreserve, create/destroy, and teardown).
`--authenticate_http_readonly` will be a new boolean flag for the VIEWS.
Note that `--authenticate_http_frameworks` already exists for `/v1/scheduler`.
`/v1/` represents the operator API, and counts as readwrite.
`--http_authenticators` needs to be updated as well, either to
`--http_readwrite_authenticator` and `--http_readonly_authenticator`, or to
handle a json blob specifying which authenticator to use for each realm.
We must continue to support the previous format as well, if specified, although
we'd probably error out if `--authenticate_http_readonly` is set and
`--http_authenticators` uses the old format.
> 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
> Fix For: 1.0.0
>
>
> 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"
> Proposed endpoint to realm grouping by [~zhitao]
> {quote}
> /
> // Common realms shared by both master and agent
>
> FLAGS
> - /flags
>
> FILES
> - /files/browse
> - /files/browse.json
> - /files/debug
> - /files/debug.json
> - /files/download
> - /files/download.json
> - /files/read
> - /files/read.json
>
> LOGGING
> - /logging/toggle
>
> METRICS
> - /metrics/snapshot
>
> PROFILER
> - /profiler/start
> - /profiler/stop
>
> SYSTEMS
> - /system/stats.json
>
> VERSIONS
> - /version
>
> /
> // Additional master only realms
>
> MAINTENANCE
> - /machine/down
> - /machine/up
> - /maintenance/schedule
> - /maintenance/status
>
> OPERATORS
> - /api/v1
>
> SCHEDULERS
> - /api/v1/scheduler
>
> REGISTRARS
> - /registrar(id)/registry
>
> RESERVATIONS
> - /reserve
> - /unreserve
> - /quota
> - /weights
>
> TEARDOWN
> - /teardown
>
> VIEWS
> - /frameworks
> - /roles
> - /roles.json
> - /slaves
> - /state
> - /state-summary
> - /state.json
> - /tasks
> - /tasks.json
>
> VOLUMES
> - /create-volumes
> - /destroy-volumes
>
> UNAUTHENTICATED
> - /health
> - /redirect
>
>
> // Additional agent realms
>
>
> OPERATORS
> - /api/v1
>
> VIEWS
> - /containers
> - /monitor/statistics
> - /monitor/statistics.json
> - /state
> - /state.json
>
> UNAUTHENTICATED
> - /api/v1/executor
> - /health
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5851) Create mechanism to control authentication between different HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385244#comment-15385244
]
Zhitao Li edited comment on MESOS-5851 at 7/20/16 3:12 AM:
---
[~greggomann] and [~vinodkone], I'd like to design the new flags from the
perspective of easy and consistent upgrade.
I believe all endpoints in READ_ONLY realm was not authenticated in 0.28.x,
then the existing --authenticate_http flag only maps to endpoints in READ_WRITE
realm. We can introduce another flag {{--authenticate_http_read_only}}, which
defaults to {{false}}. This allows operator to upgrade to 1.0 with the same
behavior.
For the sake of consistent, I think we should also create an alias flag
{{--authenticate_http_read_write}} in favor of {{--authenticate_http}}, and
explicitly call the latter deprecated from this cycle.
Given that making new flag required is very unfriendly during upgrade, I can't
really think of a good way to introduce new flag and making upgrade easy.
Please advise if you have better idea.
was (Author: zhitao):
[~greggomann] and [~vinodkone], I'd like to design the new flags from the
perspective of easy and consistent upgrade.
I believe all endpoints in READ_ONLY realm was not authenticated in 0.28.x,
then the existing {{--authenticate_http}} flag only maps to endpoints in
READ_WRITE realm. We can introduce another flag
{{--authenticate_http_read_only}}, which defaults to {{false}}. This allows
operator to upgrade to 1.0 with the same behavior.
For the sake of consistent, I think we should also create an alias flag
{{--authenticate_http_read_write}} in favor of {{--authenticate_http}}, and
explicitly call the latter deprecated from this cycle.
Given that making new flag required is very unfriendly during upgrade, I can't
really think of a good way to introduce new flag and making upgrade easy.
Please advise if you have better idea.
> 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
> Fix For: 1.0.0
>
>
> 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"
> Proposed endpoint to realm grouping by [~zhitao]
> {quote}
> /
> // Common realms shared by both master and agent
>
> FLAGS
> - /flags
>
> FILES
> - /files/browse
> - /files/browse.json
> - /files/debug
> - /files/debug.json
> - /files/download
> - /files/download.json
> - /files/read
> - /files/read.json
>
> LOGGING
> - /logging/toggle
>
> METRICS
> - /metrics/snapshot
>
> PROFILER
> - /profiler/start
> - /profiler/stop
>
> SYSTEMS
> - /system/stats.json
>
> VERSIONS
> - /version
>
> /
> // Additional master only realms
>
> MAINTENANCE
> - /machine/down
> - /machine/up
> - /maintenance/schedule
> - /maintenance/status
>
> OPERATORS
> - /api/v1
>
> SCHEDULERS
> - /api/v1/scheduler
>
> REGISTRARS
> - /registrar(id)/registry
>
> RESERVATIONS
> - /reserve
> - /unreserve
> - /quota
> - /weights
>
> TEARDOWN
> - /teardown
>
> VIEWS
> - /frameworks
> - /roles
> - /roles.json
> - /slaves
> - /state
> - /state-summary
> - /state.json
> - /tasks
> - /tasks.json
>
> VOLUMES
> - /create-volumes
> - /destroy-volumes
>
> UNAUTHENTICATED
> - /health
> - /redirect
>
>
> // Additional agent realms
>
>
> OPERATORS
> - /api/v1
>
> VIEWS
> - /containers
> - /monitor/statistics
> - /monitor/statistics.json
> - /state
> - /state.json
>
> UNAUTHENTICATED
> - /api/v1/executor
> - /health
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5851) Create mechanism to control authentication between different HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385244#comment-15385244
]
Zhitao Li edited comment on MESOS-5851 at 7/20/16 3:14 AM:
---
[~greggomann] and [~vinodkone], I'd like to design the new flags from the
perspective of easy and consistent upgrade.
I believe all endpoints in READ_ONLY realm was not authenticated in 0.28.x,
then the existing {{\-\-authenticate_http}} flag only maps to endpoints in
READ_WRITE realm. We can introduce another flag
{{\-\-authenticate_http_read_only}}, which defaults to {{false}}. This allows
operator to upgrade to 1.0 with the same behavior.
For the sake of consistent, I think we should also create an alias flag
{{\-\-authenticate_http_read_write}} in favor of {{\-\-authenticate_http}}, and
explicitly call the latter deprecated from this cycle.
Given that making new flag required is very unfriendly during upgrade, I can't
really think of a good way to introduce new flag and making upgrade easy.
Please advise if you have better idea.
was (Author: zhitao):
[~greggomann] and [~vinodkone], I'd like to design the new flags from the
perspective of easy and consistent upgrade.
I believe all endpoints in READ_ONLY realm was not authenticated in 0.28.x,
then the existing --authenticate_http flag only maps to endpoints in READ_WRITE
realm. We can introduce another flag {{--authenticate_http_read_only}}, which
defaults to {{false}}. This allows operator to upgrade to 1.0 with the same
behavior.
For the sake of consistent, I think we should also create an alias flag
{{--authenticate_http_read_write}} in favor of {{--authenticate_http}}, and
explicitly call the latter deprecated from this cycle.
Given that making new flag required is very unfriendly during upgrade, I can't
really think of a good way to introduce new flag and making upgrade easy.
Please advise if you have better idea.
> 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
> Fix For: 1.0.0
>
>
> 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"
> Proposed endpoint to realm grouping by [~zhitao]
> {quote}
> /
> // Common realms shared by both master and agent
>
> FLAGS
> - /flags
>
> FILES
> - /files/browse
> - /files/browse.json
> - /files/debug
> - /files/debug.json
> - /files/download
> - /files/download.json
> - /files/read
> - /files/read.json
>
> LOGGING
> - /logging/toggle
>
> METRICS
> - /metrics/snapshot
>
> PROFILER
> - /profiler/start
> - /profiler/stop
>
> SYSTEMS
> - /system/stats.json
>
> VERSIONS
> - /version
>
> /
> // Additional master only realms
>
> MAINTENANCE
> - /machine/down
> - /machine/up
> - /maintenance/schedule
> - /maintenance/status
>
> OPERATORS
> - /api/v1
>
> SCHEDULERS
> - /api/v1/scheduler
>
> REGISTRARS
> - /registrar(id)/registry
>
> RESERVATIONS
> - /reserve
> - /unreserve
> - /quota
> - /weights
>
> TEARDOWN
> - /teardown
>
> VIEWS
> - /frameworks
> - /roles
> - /roles.json
> - /slaves
> - /state
> - /state-summary
> - /state.json
> - /tasks
> - /tasks.json
>
> VOLUMES
> - /create-volumes
> - /destroy-volumes
>
> UNAUTHENTICATED
> - /health
> - /redirect
>
>
> // Additional agent realms
>
>
> OPERATORS
> - /api/v1
>
> VIEWS
> - /containers
> - /monitor/statistics
> - /monitor/statistics.json
> - /state
> - /state.json
>
> UNAUTHENTICATED
> - /api/v1/executor
> - /health
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5851) Create mechanism to control authentication between different HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 when we write new endpoints? And do we need
to publish and maintain this mapping in user doc and {{/help}}?
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 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.
> 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)
[jira] [Comment Edited] (MESOS-5851) Create mechanism to control authentication between different HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Comment Edited] (MESOS-5851) Create mechanism to control authentication between different HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15382673#comment-15382673
]
Zhitao Li edited comment on MESOS-5851 at 7/18/16 5:39 PM:
---
Ideally, I hope Mesos can be un-opinionated about how operators run their
clusters as much as it can.
One thing I liked about the ACL system is that there is a "permissive" fields
which regulates the default case. Sensitive organization can (and probably
should) set {{permissive=false}} for their ACL system. Maybe we should also do
something similar to authentication?
For example, consider the following json:
{quote}
--http_endpoints_authenticate=
\{
"permissive": "false",
"unauthenticated": ["/master/state", "/metrics/snapshot"],
"authenticated": ["/reserve", "/unreserve", "/create-volume",
"/destroy-volume"],
\}
{quote}
As long as {{unauthenticated}} and {{authenticated}} are both optional, I
believe this can satisfy any organization's need.
Another thing I'd like to point out that authentication is used for providing
{{principal}} for authorization, so any endpoint which requires AuthZ has to
have AuthN turn on to be properly used.
was (Author: zhitao):
Ideally, I hope Mesos can be un-opinionated about how operators run their
clusters as much as it can.
One thing I liked about the ACL system is that there is a "permissive" fields
which regulates the default case. Sensitive organization can (and probably
should) set {{permissive=false}} for their ACL system. Maybe we should also do
something similar to authentication?
For example, consider the following json:
{quote}
--http_endpoints_authenticate=
{
"permissive": "false",
"unauthenticated": ["/master/state", "/metrics/snapshot"],
"authenticated": ["/reserve", "/unreserve", "/create-volume",
"/destroy-volume"],
}
{quote}
As long as {{unauthenticated}} and {{authenticated}} are both optional, I
believe this can satisfy any organization's need.
Another thing I'd like to point out that authentication is used for providing
{{principal}} for authorization, so any endpoint which requires AuthZ has to
have AuthN turn on to be properly used.
> 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)
[jira] [Comment Edited] (MESOS-5851) Create mechanism to control authentication between different HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15382673#comment-15382673
]
Zhitao Li edited comment on MESOS-5851 at 7/18/16 5:38 PM:
---
Ideally, I hope Mesos can be un-opinionated about how operators run their
clusters as much as it can.
One thing I liked about the ACL system is that there is a "permissive" fields
which regulates the default case. Sensitive organization can (and probably
should) set {{permissive=false}} for their ACL system. Maybe we should also do
something similar to authentication?
For example, consider the following json:
{quote}
--http_endpoints_authenticate=
{
"permissive": "false",
"unauthenticated": ["/master/state", "/metrics/snapshot"],
"authenticated": ["/reserve", "/unreserve", "/create-volume",
"/destroy-volume"],
}
{quote}
As long as {{unauthenticated}} and {{authenticated}} are both optional, I
believe this can satisfy any organization's need.
Another thing I'd like to point out that authentication is used for providing
{{principal}} for authorization, so any endpoint which requires AuthZ has to
have AuthN turn on to be properly used.
was (Author: zhitao):
Ideally, I hope Mesos can be un-opinionated about how operators run their
clusters as much as it can.
One thing I liked about the ACL system is that there is a "permissive" fields
which regulates the default case. Sensitive organization can (and probably
should) set {{permissive=false}} for their ACL system. Maybe we should also do
something similar to authentication?
For example, consider the following json:
{quote}
--http_endpoints_authenticate=
{
"permissive": false,
"unauthenticated": ["/master/state", "/metrics/snapshot"],
"authenticated": ["/reserve", "/unreserve", "/create-volume",
"/destroy-volume"],
}
{quote}
As long as {{unauthenticated}} and {{authenticated}} are both optional, I
believe this can satisfy any organization's need.
Another thing I'd like to point out that authentication is used for providing
{{principal}} for authorization, so any endpoint which requires AuthZ has to
have AuthN turn on to be properly used.
> 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)
[jira] [Comment Edited] (MESOS-5851) Create mechanism to control authentication between different HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15382673#comment-15382673
]
Zhitao Li edited comment on MESOS-5851 at 7/18/16 5:37 PM:
---
Ideally, I hope Mesos can be un-opinionated about how operators run their
clusters as much as it can.
One thing I liked about the ACL system is that there is a "permissive" fields
which regulates the default case. Sensitive organization can (and probably
should) set {{permissive=false}} for their ACL system. Maybe we should also do
something similar to authentication?
For example, consider the following json:
{quote}
--http_endpoints_authenticate=
{
"permissive": false,
"unauthenticated": ["/master/state", "/metrics/snapshot"],
"authenticated": ["/reserve", "/unreserve", "/create-volume",
"/destroy-volume"],
}
{quote}
As long as {{unauthenticated}} and {{authenticated}} are both optional, I
believe this can satisfy any organization's need.
Another thing I'd like to point out that authentication is used for providing
{{principal}} for authorization, so any endpoint which requires AuthZ has to
have AuthN turn on to be properly used.
was (Author: zhitao):
Ideally, I hope Mesos can be un-opinionated about how operators run their
clusters as much as it can.
One thing I liked about the ACL system is that there is a "permissive" fields
which regulates the default case. Sensitive organization can (and probably
should) set {{permissive=false}} for their ACL system. Maybe we should also do
something similar to authentication?
For example, consider the following json:
{quote}
--http_endpoints_authenticate=
{
"permissive": false, // authenticate by default
"unauthenticated": ["/master/state", "/metrics/snapshot"], // optional list
of endpoints that's always unauthenticated regardless
"authenticated": ["/reserve", "/unreserve", "/create-volume",
"/destroy-volume"], // optional list of endpoints that's always authenticated
regardless
}
{quote}
then I believe this can satisfy any organization's need.
Another thing I'd like to point out that authentication is used for providing
{{principal}} for authorization, so any endpoint which requires AuthZ has to
have AuthN turn on to be properly used.
> 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)
[jira] [Comment Edited] (MESOS-5851) Create mechanism to control authentication between different HTTP endpoints
[
https://issues.apache.org/jira/browse/MESOS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15382673#comment-15382673
]
Zhitao Li edited comment on MESOS-5851 at 7/18/16 5:36 PM:
---
Ideally, I hope Mesos can be un-opinionated about how operators run their
clusters as much as it can.
One thing I liked about the ACL system is that there is a "permissive" fields
which regulates the default case. Sensitive organization can (and probably
should) set {{permissive=false}} for their ACL system. Maybe we should also do
something similar to authentication?
For example, consider the following json:
{quote}
--http_endpoints_authenticate=
{
"permissive": false, // authenticate by default
"unauthenticated": ["/master/state", "/metrics/snapshot"], // optional list
of endpoints that's always unauthenticated regardless
"authenticated": ["/reserve", "/unreserve", "/create-volume",
"/destroy-volume"], // optional list of endpoints that's always authenticated
regardless
}
{quote}
then I believe this can satisfy any organization's need.
Another thing I'd like to point out that authentication is used for providing
{{principal}} for authorization, so any endpoint which requires AuthZ has to
have AuthN turn on to be properly used.
was (Author: zhitao):
Ideally, I hope Mesos can be un-opinionated about how operators run their
clusters as much as it can.
One thing I liked about the ACL system is that there is a "permissive" fields
which regulates the default case. Sensitive organization can (and probably
should) set `permissive=false` for their ACL system. Maybe we should also do
something similar to authentication?
For example, consider the following json:
```
--http_endpoints_authenticate=
{
"permissive": false, // authenticate by default
"unauthenticated": ["/master/state", "/metrics/snapshot"], // optional list
of endpoints that's always unauthenticated regardless
"authenticated": ["/reserve", "/unreserve", "/create-volume",
"/destroy-volume"], // optional list of endpoints that's always authenticated
regardless
}
```
then I believe this can satisfy any organization's need.
Another thing I'd like to point out that authentication is used for providing
`principal` for authorization, so any endpoint which requires AuthZ has to have
AuthN turn on to be properly used.
> 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)
[jira] [Comment Edited] (MESOS-5851) Create mechanism to control authentication between different HTTP endpoints
[ https://issues.apache.org/jira/browse/MESOS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15380348#comment-15380348 ] Zhitao Li edited comment on MESOS-5851 at 7/16/16 12:19 AM: This sounds acceptable to me. Will this exclusion list be specified as a flag on master side and passed to some (global) variable? was (Author: zhitao): This sounds good to me. Will this exclusion list be specified as a flag on master side and passed to some (global) variable? > 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 >Reporter: Zhitao Li > > 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)
