Re: WebUI authentication in 1.0.0-rc1

[Evers Benno]

Sure,

it looks like this, not very imaginative. There is currently no
authorization on the agents.

{
"permissive": false,

[...] // Here is the previous ACL with actions "run_tasks" and
"register_frameworks"

"get_endpoints": [
{
"principals": {"type": "ANY"},
"paths": {"type": "ANY"}
}
],

"view_frameworks": [
 {
 "principals": {"type": "ANY"},
 "users": {"type": "ANY"}
 }
],

"view_tasks": [
 {
 "principals": {"type": "ANY"},
 "users": {"type": "ANY"}
 }
],

"view_executors": [
 {
 "principals": {"type": "ANY"},
 "users": {"type": "ANY"}
 }
],

"access_sandboxes": [
 {
 "principals": {"type": "ANY"},
 "users": {"type": "ANY"}
 }
],

"access_mesos_logs": [
 {
 "principals": {"type": "ANY"},
 "logs": {"type": "ANY"}
 }
]
}



On 10.06.2016 00:17, Greg Mann wrote:
> Benno,
> Would you mind providing more information on the ACL definitions that you
> used to gain full access to the web UI? I'm working on some more
> documentation for this. Also, did you have authorization enabled on the
> agents as well?
> 
> Cheers,
> Greg
> 
> On Wed, Jun 8, 2016 at 7:43 AM, Neil Conway  wrote:
> 
>> On Wed, Jun 8, 2016 at 4:27 PM, Alexander Rojas 
>> wrote:
>>> I think we should also think more thoroughly about the expected behaviour
>>> when we introduce new authorizable actions (and we most certainly will).
>>> Since things may break particularly if users set the `permissive` ACL
>> field
>>> to false.
>>>
>>> Perhaps initially, if no ACL is given for the new action we print a
>> warning
>>> message and behave as if the field had an ACL such as
>>>
>>> ```
>>> {
>>>   "principals": {"type": "ANY"}
>>>   "action":{"type": "ANY"}
>>> }
>>> ```
>>
>> An ACL configuration that omits any rules for a particular action is
>> not an invalid way to configure the system. e.g., suppose we added the
>> "/teardown" endpoint in Mesos 1.1, along with the
>> "teardown_frameworks" ACL. A perfectly reasonable way to configure the
>> behavior "no one should be allowed to use the /teardown endpoint" is
>> an ACL configuration that has "permissive: false" and doesn't
>> otherwise mention "teardown_frameworks".
>>
>> The situation here is a little unusual, because we're introducing ACLs
>> for behavior that was previously not covered by the authorization
>> system, rather than new functionality. But overall, I think the
>> situation can be addressed by documenting the new behavior
>> *prominently* in the release notes / upgrade docs -- anyone upgrading
>> to a non-patch release should be reading that document anyway, and the
>> required changes will usually be straightforward.
>>
>> Neil
>>
> 

Re: WebUI authentication in 1.0.0-rc1

[Greg Mann]

Benno,
Would you mind providing more information on the ACL definitions that you
used to gain full access to the web UI? I'm working on some more
documentation for this. Also, did you have authorization enabled on the
agents as well?

Cheers,
Greg

On Wed, Jun 8, 2016 at 7:43 AM, Neil Conway  wrote:

> On Wed, Jun 8, 2016 at 4:27 PM, Alexander Rojas 
> wrote:
> > I think we should also think more thoroughly about the expected behaviour
> > when we introduce new authorizable actions (and we most certainly will).
> > Since things may break particularly if users set the `permissive` ACL
> field
> > to false.
> >
> > Perhaps initially, if no ACL is given for the new action we print a
> warning
> > message and behave as if the field had an ACL such as
> >
> > ```
> > {
> >   "principals": {"type": "ANY"}
> >   "action":{"type": "ANY"}
> > }
> > ```
>
> An ACL configuration that omits any rules for a particular action is
> not an invalid way to configure the system. e.g., suppose we added the
> "/teardown" endpoint in Mesos 1.1, along with the
> "teardown_frameworks" ACL. A perfectly reasonable way to configure the
> behavior "no one should be allowed to use the /teardown endpoint" is
> an ACL configuration that has "permissive: false" and doesn't
> otherwise mention "teardown_frameworks".
>
> The situation here is a little unusual, because we're introducing ACLs
> for behavior that was previously not covered by the authorization
> system, rather than new functionality. But overall, I think the
> situation can be addressed by documenting the new behavior
> *prominently* in the release notes / upgrade docs -- anyone upgrading
> to a non-patch release should be reading that document anyway, and the
> required changes will usually be straightforward.
>
> Neil
>

Re: WebUI authentication in 1.0.0-rc1

[Neil Conway]

On Wed, Jun 8, 2016 at 4:27 PM, Alexander Rojas  wrote:
> I think we should also think more thoroughly about the expected behaviour
> when we introduce new authorizable actions (and we most certainly will).
> Since things may break particularly if users set the `permissive` ACL field
> to false.
>
> Perhaps initially, if no ACL is given for the new action we print a warning
> message and behave as if the field had an ACL such as
>
> ```
> {
>   "principals": {"type": "ANY"}
>   "action":{"type": "ANY"}
> }
> ```

An ACL configuration that omits any rules for a particular action is
not an invalid way to configure the system. e.g., suppose we added the
"/teardown" endpoint in Mesos 1.1, along with the
"teardown_frameworks" ACL. A perfectly reasonable way to configure the
behavior "no one should be allowed to use the /teardown endpoint" is
an ACL configuration that has "permissive: false" and doesn't
otherwise mention "teardown_frameworks".

The situation here is a little unusual, because we're introducing ACLs
for behavior that was previously not covered by the authorization
system, rather than new functionality. But overall, I think the
situation can be addressed by documenting the new behavior
*prominently* in the release notes / upgrade docs -- anyone upgrading
to a non-patch release should be reading that document anyway, and the
required changes will usually be straightforward.

Neil

Re: WebUI authentication in 1.0.0-rc1

[Jörg Schad]

Maybe we can just supply a default acl template file specifying these
defaults acls. Then users will have more guidance when starting to use acls.
I will create a sample patch to clarify how I envision such kind of
template :-).

On Wed, Jun 8, 2016 at 4:27 PM, Alexander Rojas 
wrote:

> I think we should also think more thoroughly about the expected behaviour
> when we introduce new authorizable actions (and we most certainly will).
> Since things may break particularly if users set the `permissive` ACL field
> to false.
>
> Perhaps initially, if no ACL is given for the new action we print a warning
> message and behave as if the field had an ACL such as
>
> ```
> {
>   "principals": {"type": "ANY"}
>   "action":{"type": "ANY"}
> }
> ```
>
> which effectively set a permissive rule for that action. The advantage is
> that
> it will give time for users to update the ACLs, the disadvantage is that we
> would be introducing incorrect semantics (if temporarily).
>
> The other idea would be to detect `permissive=false` and no ACLs given
> for the new action and print a warning message about possible breaks
> because of a change in the system, but no change in behaviour.
>
> Any other ideas?
>
> On Wed, Jun 8, 2016 at 1:30 AM, Greg Mann  wrote:
>
> > Hi Evers,
> > Thanks for testing this out! We should have called out this change more
> > explicitly in the changelog; I've posted a patch here
> >  to do that.
> >
> > Adding documentation with guidance on how to set ACLs to accomplish
> > particular tasks (i.e., full use of the web UI) would be beneficial as
> > well, but seems out of scope for the release notes. I've created a JIRA
> to
> > update the authorization documentation here
> > .
> >
> > Cheers,
> > Greg
> >
> >
> > On Mon, Jun 6, 2016 at 2:28 AM, Evers Benno 
> wrote:
> >
> > > Hi,
> > >
> > > thanks for the pointer. For people having the same problem, it seems
> > > that you have to actually provide six new ACL rules to restore the
> > > previous behaviour:
> > >
> > > get_endpoints, view_frameworks, view_tasks, view_executors,
> > > access_sandboxes, and access_mesos_logs.
> > >
> > > On 03.06.2016 21:59, Michael Park wrote:
> > > > Hello, I'm not exactly sure about whether the behavior is undesired
> or
> > > not.
> > > >
> > > > But I think the ACL that you're missing is `GetEndpoint`:
> > > >
> > >
> >
> https://github.com/apache/mesos/blob/master/include/mesos/authorizer/acls.proto#L183-L190
> > > >
> > > > Hope that helps,
> > > >
> > > > MPark
> > > >
> > > > On 3 June 2016 at 12:36, Evers Benno  wrote:
> > > >
> > > >>
> > > >> I just tried building and running the 1.0.0-rc1, and it seems that
> the
> > > >> web UI is broken due to /metrics/snapshot returning a 403. (There's
> a
> > > >> popup continously displaying "Failed to connect to
> > > >> mesos-master.example.org:5050!"
> > > >>
> > > >> I'm running mesos-master with options `--no-authenticate_http
> > > >> --acls={"permissive": "false", [...]}`, so I'm not completely sure
> if
> > > >> this behaviour is as desired or not. (although its certainly
> > unexpected)
> > > >>
> > > >> Regardless, I looked around for a while, but I couldn't figure out
> > what
> > > >> to add to the ACL to restore unauthorized viewing access for
> everyone?
> > > >>
> > > >> Best regards,
> > > >> Benno
> > > >>
> > > >
> > >
> >
>

Re: WebUI authentication in 1.0.0-rc1

[Alexander Rojas]

I think we should also think more thoroughly about the expected behaviour
when we introduce new authorizable actions (and we most certainly will).
Since things may break particularly if users set the `permissive` ACL field
to false.

Perhaps initially, if no ACL is given for the new action we print a warning
message and behave as if the field had an ACL such as

```
{
  "principals": {"type": "ANY"}
  "action":{"type": "ANY"}
}
```

which effectively set a permissive rule for that action. The advantage is
that
it will give time for users to update the ACLs, the disadvantage is that we
would be introducing incorrect semantics (if temporarily).

The other idea would be to detect `permissive=false` and no ACLs given
for the new action and print a warning message about possible breaks
because of a change in the system, but no change in behaviour.

Any other ideas?

On Wed, Jun 8, 2016 at 1:30 AM, Greg Mann  wrote:

> Hi Evers,
> Thanks for testing this out! We should have called out this change more
> explicitly in the changelog; I've posted a patch here
>  to do that.
>
> Adding documentation with guidance on how to set ACLs to accomplish
> particular tasks (i.e., full use of the web UI) would be beneficial as
> well, but seems out of scope for the release notes. I've created a JIRA to
> update the authorization documentation here
> .
>
> Cheers,
> Greg
>
>
> On Mon, Jun 6, 2016 at 2:28 AM, Evers Benno  wrote:
>
> > Hi,
> >
> > thanks for the pointer. For people having the same problem, it seems
> > that you have to actually provide six new ACL rules to restore the
> > previous behaviour:
> >
> > get_endpoints, view_frameworks, view_tasks, view_executors,
> > access_sandboxes, and access_mesos_logs.
> >
> > On 03.06.2016 21:59, Michael Park wrote:
> > > Hello, I'm not exactly sure about whether the behavior is undesired or
> > not.
> > >
> > > But I think the ACL that you're missing is `GetEndpoint`:
> > >
> >
> https://github.com/apache/mesos/blob/master/include/mesos/authorizer/acls.proto#L183-L190
> > >
> > > Hope that helps,
> > >
> > > MPark
> > >
> > > On 3 June 2016 at 12:36, Evers Benno  wrote:
> > >
> > >>
> > >> I just tried building and running the 1.0.0-rc1, and it seems that the
> > >> web UI is broken due to /metrics/snapshot returning a 403. (There's a
> > >> popup continously displaying "Failed to connect to
> > >> mesos-master.example.org:5050!"
> > >>
> > >> I'm running mesos-master with options `--no-authenticate_http
> > >> --acls={"permissive": "false", [...]}`, so I'm not completely sure if
> > >> this behaviour is as desired or not. (although its certainly
> unexpected)
> > >>
> > >> Regardless, I looked around for a while, but I couldn't figure out
> what
> > >> to add to the ACL to restore unauthorized viewing access for everyone?
> > >>
> > >> Best regards,
> > >> Benno
> > >>
> > >
> >
>

Re: WebUI authentication in 1.0.0-rc1

[Evers Benno]

Hi,

thanks for the pointer. For people having the same problem, it seems
that you have to actually provide six new ACL rules to restore the
previous behaviour:

get_endpoints, view_frameworks, view_tasks, view_executors,
access_sandboxes, and access_mesos_logs.

On 03.06.2016 21:59, Michael Park wrote:
> Hello, I'm not exactly sure about whether the behavior is undesired or not.
> 
> But I think the ACL that you're missing is `GetEndpoint`:
> https://github.com/apache/mesos/blob/master/include/mesos/authorizer/acls.proto#L183-L190
> 
> Hope that helps,
> 
> MPark
> 
> On 3 June 2016 at 12:36, Evers Benno  wrote:
> 
>>
>> I just tried building and running the 1.0.0-rc1, and it seems that the
>> web UI is broken due to /metrics/snapshot returning a 403. (There's a
>> popup continously displaying "Failed to connect to
>> mesos-master.example.org:5050!"
>>
>> I'm running mesos-master with options `--no-authenticate_http
>> --acls={"permissive": "false", [...]}`, so I'm not completely sure if
>> this behaviour is as desired or not. (although its certainly unexpected)
>>
>> Regardless, I looked around for a while, but I couldn't figure out what
>> to add to the ACL to restore unauthorized viewing access for everyone?
>>
>> Best regards,
>> Benno
>>
> 

Re: WebUI authentication in 1.0.0-rc1

[Michael Park]

Hello, I'm not exactly sure about whether the behavior is undesired or not.

But I think the ACL that you're missing is `GetEndpoint`:
https://github.com/apache/mesos/blob/master/include/mesos/authorizer/acls.proto#L183-L190

Hope that helps,

MPark

On 3 June 2016 at 12:36, Evers Benno  wrote:

>
> I just tried building and running the 1.0.0-rc1, and it seems that the
> web UI is broken due to /metrics/snapshot returning a 403. (There's a
> popup continously displaying "Failed to connect to
> mesos-master.example.org:5050!"
>
> I'm running mesos-master with options `--no-authenticate_http
> --acls={"permissive": "false", [...]}`, so I'm not completely sure if
> this behaviour is as desired or not. (although its certainly unexpected)
>
> Regardless, I looked around for a while, but I couldn't figure out what
> to add to the ACL to restore unauthorized viewing access for everyone?
>
> Best regards,
> Benno
>