> On July 15, 2015, 6:13 p.m., Artem Harutyunyan wrote:
> > To make sure that this is fool proof(ish), I would suggest that this should
> > only ship only when the Authorizer framework (mentioned in the TODO
> > comment) becomes available. Also, I would add a screaming comment to
> > --usage, something along the lines of 'this is insecure, and this enables
> > arbitrary command executrion with root privileges'.
> >
> > In general, I am of the firm opinion that this feature should come with a
> > whitelisting mechanism that will allow operators to whitelist (benign)
> > commands that they want to execute, and forbid anything else.
>To make sure that this is fool proof(ish), I would suggest that this should
>only ship only when the Authorizer framework (mentioned in the TODO comment)
>becomes available. Also, I would add a screaming comment to --usage, something
>along the lines of 'this is insecure, and this enables arbitrary command
>executrion with root privileges'.
This has to be deliberately enabled:
```
--allow_remote_execution
Allows the execution of arbitrary shell commands on the Slave, by
POSTing to the /execute endpoint with a JSON-serialized CommandInfo
protobuf, containing the command to execute and, optionally, the
arguments.
WARNING: this may cause a security vulnerability and is disabled by
default; enable only if you know exactly what you are doing.
```
The WARNING seems explicit enough to me, but if people agree, I'm happy TO MAKE
IT SCREAM ;-)
> In general, I am of the firm opinion that this feature should come with a
> whitelisting mechanism that will allow operators to whitelist (benign)
> commands that they want to execute, and forbid anything else.
Perhaps; but please note that this is meant mostly for emergency/off-cycle
maintenance reasons, so it's very difficult to know in advance *what* you will
need (if you did, you probably wouldn't need the feauture in the first place).
This is also meant to be a "highly scriptable" endpoint, where you have either
a generating function or a discovery methodology, that finds out (potentially
1,000s of) IPs for your Slaves and then does in very rapid succession a POST
with the command to execute (I'm envisioning some catastrophic failure mode
that needs to be prevented; or a security breach; or something like that).
In any event, in modern systems, the way to "protect" these endpoints is at the
network security level, by isolating services within a protected, private
subnet, with access granted only from "bastion" servers (hardened and secured)
- re-implementing authentication/authorization on every single service is not
only prone to leaving some vulnerable to security breaches, but it also becomes
quickly unmanageable (as you know have disparate, and inconsistent, security
policies and authentication mechanism and no centralized way to manage and
revoke access).
(well, when I say "modern"... that was 5-6 years ago at Google... but I figure
we were 4-5 years ahead of everyone else :) )
- Marco
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/36389/#review91784
-----------------------------------------------------------
On July 14, 2015, 11:20 p.m., Marco Massenzio wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36389/
> -----------------------------------------------------------
>
> (Updated July 14, 2015, 11:20 p.m.)
>
>
> Review request for mesos, Benjamin Hindman and Cody Maloney.
>
>
> Bugs: MESOS-2830
> https://issues.apache.org/jira/browse/MESOS-2830
>
>
> Repository: mesos
>
>
> Description
> -------
>
> Jira: MESOS-2830
>
> Under certain (maintenance) circumnstance, it may be necessary
> (or desirable) to execute arbitrary operator's commands on the
> slave (the entire fleet or a subset thereof) bypassing the Mesos
> Task execution mechanism; this may typically be necessary for
> maintenance and/or emergency actions.
>
> This patch adds an HTTP endpoint (/execute) which accepts a
> JSON-encoded CommandInfo structure and executes the given
> command (with optional arguments).
>
> The output of the command (along with potentially any stderr
> messages) is returned JSON-encoded in the Response.
>
> For more details, see the design doc at:
> https://goo.gl/4npTMU
>
>
> Diffs
> -----
>
> src/slave/flags.hpp 26c778db2303167369af8675fe0441a00a1e9151
> src/slave/flags.cpp 8632677ebbdbfef8ffa45204b6f63a700baff7f3
> src/slave/main.cpp 8008430e98773d8be9ba5ac6385cffb2e351932a
> src/slave/slave.hpp dec4ca8323e151a6d0f9139214ff0ef6e3e3375a
> src/slave/slave.cpp 2119b5176aa7cfb7b0b551d4d4f65ee12818b9e4
>
> Diff: https://reviews.apache.org/r/36389/diff/
>
>
> Testing
> -------
>
> make check
>
> lots of manual testing (using Postman, REST client)
>
>
> Thanks,
>
> Marco Massenzio
>
>
