[
https://issues.apache.org/jira/browse/KNOX-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273458#comment-16273458
]
Larry McCay edited comment on KNOX-1129 at 11/30/17 9:19 PM:
-------------------------------------------------------------
[~pzampino] - this looks great.
One change that I would suggest is to not just log that ACLs are inappropriate
for authenticated clients but to actually change the ACL accordingly.
If this isn't possible for some reason then we can discuss.
Also, can we lock the znodes down further such that you have to be
authenticated to read them as well? While we do have aliasService for secrets
and passwords, I think there are a couple providers that still require a
password here and there. There may also be other sensitive things like URLs or
something in the descriptors or provider config.
was (Author: lmccay):
[~pzampino] - this looks great.
One change that I would suggest is to not just log that ACLs are inappropriate
for authenticated clients but to actually change the ACL accordingly.
If this isn't possible for some reason then we can discuss.
> Remote Configuration Monitor Should Define The Entries It Monitors If They're
> Not Yet Defined
> ---------------------------------------------------------------------------------------------
>
> Key: KNOX-1129
> URL: https://issues.apache.org/jira/browse/KNOX-1129
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Affects Versions: 0.14.0
> Reporter: Phil Zampino
> Assignee: Phil Zampino
> Labels: kip-8
> Fix For: 0.14.0
>
> Attachments: KNOX-1129.patch
>
>
> Currently, if the remote configuration monitor finds that the
> /knox/config/shared-providers and/or /knox/config/descriptors entries (e.g.,
> znodes) are not present (or are otherwise inaccessible), it determines that
> it cannot function, and it ceases any attempt at monitoring.
> For those cases where the entries do not yet exist, the monitor can define
> them. If the client employed by the monitor does not require authentication,
> then the new entries will be created without any meaningful ACLs applied. If
> the client has been authenticated, then the ACLs should be such that the
> authenticated principal has write permissions, while everyone else has
> read-only permissions.
> Whether or not the read permissions should be more restrictive is yet to be
> determined; Other projects in the ecosystem seem to allow everyone read
> access to their respective ZooKeeper content.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
