On Tue, Mar 12, 2019 at 11:57 AM James E. Blair <corvus@inaugust.com> wrote:

[snip]

>> With respect to the second, it would mean that an operator would be able
>> to worry less about what the Zuul executor has access to, but would need
>> to ensure that whatever off-host non-Zuul executor doesn't have access
>> to anything it shouldn't.  Basically, it moves the problem.  As long as
>> the things that Zuul requires access to (e.g., gearman, zookeeper) can
>> be protected, I don't think it's a significant difference from a
>> security POV.
>>
>
> Note that ZooKeeper access can not be protected without a fix for
> https://issues.apache.org/jira/browse/ZOOKEEPER-2937 (at least without
> network isolation between the executor service and the job tasks).

Indeed, we should clarify this.  I don't think we can drop our plugins
or proceed with a scale-out scheduler if we can't prevent anonymous zk
reads.  The Jira report involves a custom authentication plugin.  Have
you tested this with the system we'd be using?


FYI, I did some quick local testing and I don't believe the standard digest/sasl mechanisms are affected. An unauthenticated client can connect and do CRUD ops, but cannot affect any znodes that have appropriate ACLs set on them. So as long as we set the ACLs correctly, I don't see any issue. This will mean we'll need to consider an upgrade path from non-ACL nodes to ACL nodes, but it looks like kazoo provides us a set_acls() API call we use to create a tool to help with that.

-Dave