Re: [VOTE] Release Apache Mesos 1.3.2 (rc1)

[Vinod Kone]

+1 (binding)

Tested on ASF CI. Red builds are flaky tests due to the known perf core
dump issue that has been fixed since.
*Revision*: 17ab9ff8b35f5ec877f08698e28301bec030d010

   - refs/tags/1.3.2-rc1

Configuration Matrix gcc clang
centos:7 --verbose --enable-libevent --enable-ssl autotools
[image: Success]

[image: Not run]
cmake
[image: Success]

[image: Not run]
--verbose autotools
[image: Success]

[image: Not run]
cmake
[image: Success]

[image: Not run]
ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
[image: Failed]

[image: Failed]

cmake
[image: Success]

[image: Success]

--verbose autotools
[image: Failed]

[image: Failed]

cmake
[image: Success]

[image: Success]


On Thu, Dec 14, 2017 at 5:38 PM, Benjamin Mahler  wrote:

> +1 (binding)
>
> make check passes on macOS 10.13.2 with Apple LLVM version 9.0.0
> (clang-900.0.39.2)
>
> On Thu, Dec 7, 2017 at 2:44 PM, Michael Park  wrote:
>
>> Hi all,
>>
>> Please vote on releasing the following candidate as Apache Mesos 1.3.2.
>>
>> The CHANGELOG for the release is available at:
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_p
>> lain;f=CHANGELOG;hb=1.3.2-rc1
>> 
>> 
>>
>> The candidate for Mesos 1.3.2 release is available at:
>> https://dist.apache.org/repos/dist/dev/mesos/1.3.2-rc1/mesos-1.3.2.tar.gz
>>
>> The tag to be voted on is 1.3.2-rc1:
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.3.2-rc1
>>
>> The MD5 checksum of the tarball can be found at:
>> https://dist.apache.org/repos/dist/dev/mesos/1.3.2-rc1/mesos
>> -1.3.2.tar.gz.md5
>>
>> The signature of the tarball can be found at:
>> https://dist.apache.org/repos/dist/dev/mesos/1.3.2-rc1/mesos
>> -1.3.2.tar.gz.asc
>>
>> The PGP key used to sign the release is here:
>> https://dist.apache.org/repos/dist/release/mesos/KE

Re: Reusing `reserve_resources` ACL for static reservation

[James Peach]

> On Dec 15, 2017, at 5:34 AM, Alexander Rojas  wrote:
> 
> Hey Yan,
> 
> We were discussing this issue with James and I think this is not enough
> to guarantee that an Agent won’t be assigned (neither statically nor
> dynamically) resources under certain role. The problem here is that nothing
> will avoid a principal to dynamically reserve resources later.

Maybe my confusion arises from 2 possible reading of the semantics of the 
`reserve_resources` ACL.

If we read it as "these principals may reserve resources for role A", then it 
makes sense that a framework principal can place those reservations on any 
agent and that agents must register with an allowed principal to make their 
static reservations.

If we read it as "agents with this principal may host resources reserved for 
role A", then that implies that we ought to consider the agent's principal for 
both static and dynamic reservations.

Due to the security context of this change, I had assumed that the latter was 
the desired outcome.

> However your approach does work if you want to treat statically resources
> as dynamical ones. It does require however that agents register using 
> different credentials (which I don’t think is a bad idea).
> 
> What I was thinking now is to use only one authorization call, `RegisterAgent`
> so that it looks at the whole `slave_info` message (That will require 
> modifications
> in `mesos::ObjectApprover::Object`) and then check the roles from the 
> `slave_info`.

This seems like a pretty useful enhancement. An authorizer could validate agent 
attributes and any number of other interesting properties.

> Then for each reservation we would need to not only authorize the reservation
> action, but the roles themselves with the principal used for agent 
> registration
> and compute a logical and of the two results. There are indeed antecedents
> for this solution.
> 
> What I don’t think we can get around is for agents using different principals
> on registration since we only authorize against principals and agent-id’s are
> dynamically generated.

I think this is fine, though I was originally a bit concerned that specifying a 
large number of agent principals in the ACLs JSON would not be scalable. I 
expect that people using the built-in authorization mechanism are using only a 
few agent principals while only those who have wired Mesos up to a directory 
service are probably using machine accounts.

> @jpeach do you have any objections or ideas here?
> @yan could you discuss this with @jpeach.
> 
> Finally @yan, you have been working without a shepherd and I really recommend
> you to get one in order to get this through. I could help here but I may lack 
> some
> of the context that james has. I guess is up to you.
> 
> Best,
> 
> 
> Alexander Rojas
> alexan...@mesosphere.io
> 
> 
> 
> 
>> On 12. Dec 2017, at 20:31, Yan Xu  wrote:
>> 
>> Hi,
>> 
>> In https://issues.apache.org/jira/browse/MESOS-8306 I am proposing that we
>> use an ACL to restrict the roles that agents can statically reserve
>> resources for to address a security concern in which a process on a
>> compromised host can impersonate an agent and then then reservation
>> resources for arbitrary roles.
>> 
>> Resuing `reserve_resources` ACL for this purpose feels intuitive to me and
>> I don't think it interferes with its use for authorizing dynamic
>> reservations by the frameworks and operators.
>> 
>> Are there any concerns about it?
>> 
>> Also as part of this change I am revising the doc to change the wording on
>> static reservations so its use is not discouraged:
>> https://reviews.apache.org/r/64516/diff
>> 
>> Thanks,
>> Yan
> 

Re: Reusing `reserve_resources` ACL for static reservation

[Alexander Rojas]

Hey Yan,

We were discussing this issue with James and I think this is not enough
to guarantee that an Agent won’t be assigned (neither statically nor
dynamically) resources under certain role. The problem here is that nothing
will avoid a principal to dynamically reserve resources later.

However your approach does work if you want to treat statically resources
as dynamical ones. It does require however that agents register using 
different credentials (which I don’t think is a bad idea).

What I was thinking now is to use only one authorization call, `RegisterAgent`
so that it looks at the whole `slave_info` message (That will require 
modifications
in `mesos::ObjectApprover::Object`) and then check the roles from the 
`slave_info`.

Then for each reservation we would need to not only authorize the reservation
action, but the roles themselves with the principal used for agent registration
and compute a logical and of the two results. There are indeed antecedents
for this solution.

What I don’t think we can get around is for agents using different principals
on registration since we only authorize against principals and agent-id’s are
dynamically generated.

@jpeach do you have any objections or ideas here?
@yan could you discuss this with @jpeach.

Finally @yan, you have been working without a shepherd and I really recommend
you to get one in order to get this through. I could help here but I may lack 
some
of the context that james has. I guess is up to you.

Best,


Alexander Rojas
alexan...@mesosphere.io




> On 12. Dec 2017, at 20:31, Yan Xu  wrote:
> 
> Hi,
> 
> In https://issues.apache.org/jira/browse/MESOS-8306 I am proposing that we
> use an ACL to restrict the roles that agents can statically reserve
> resources for to address a security concern in which a process on a
> compromised host can impersonate an agent and then then reservation
> resources for arbitrary roles.
> 
> Resuing `reserve_resources` ACL for this purpose feels intuitive to me and
> I don't think it interferes with its use for authorizing dynamic
> reservations by the frameworks and operators.
> 
> Are there any concerns about it?
> 
> Also as part of this change I am revising the doc to change the wording on
> static reservations so its use is not discouraged:
> https://reviews.apache.org/r/64516/diff
> 
> Thanks,
> Yan