[jira] [Comment Edited] (OOZIE-3196) Authorization: restrict world readability by user

2018-04-09 Thread Peter Orova (JIRA)

[ 
https://issues.apache.org/jira/browse/OOZIE-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16430243#comment-16430243
 ] 

Peter Orova edited comment on OOZIE-3196 at 4/9/18 8:16 AM:


Some follow up:

# In the minimal viable product described by [~andras.piros] and [~dbist13], it 
seems that the authorization level of non-admin user in the current 
authorization scheme is not present. I.e. a user with read privileges on 'all' 
does not exist. Such user could be useful when creating dashboards and such. 
What do you all think?
# As far as the different levels of authorization that should be enforced, as 
discussed with [~andras.piros] offline, a three level schema seems reasonable 
with the following levels:

* level1 - no authorization

* level2 - currently existing authorization (admins, and plain users - the 
latter having read privileges on all)

* level3 - restricted (admins, users having r/w privileges on 'owned' items, 
possibly service user(s) having read only access)

Could you share your thoughts on this?


was (Author: orova):
Some follow up:

1./  In the minimal viable product described by [~andras.piros] and [~dbist13], 
it seems that the authorization level of non-admin user in the current 
authorization scheme is not present. I.e. a user with read privileges on 'all' 
does not exist. Such user could be useful when creating dashboards and such. 
What do you all think?

2./  As far as the different levels of authorization that should be enforced, 
as discussed with [~andras.piros] offline, a three level schema seems 
reasonable with the following levels:

level1 - no authorization

level2 - currently existing authorization (admins, and plain users - the latter 
having read privileges on all)

level3 - restricted (admins, users having r/w privileges on 'owned' items, 
possibly service user(s) having read only access)

Could you share your thoughts on this?

> Authorization: restrict world readability by user
> -
>
> Key: OOZIE-3196
> URL: https://issues.apache.org/jira/browse/OOZIE-3196
> Project: Oozie
>  Issue Type: New Feature
>  Components: bundle, coordinator, workflow
>Affects Versions: 5.0.0b1
>Reporter: Andras Piros
>Assignee: Peter Orova
>Priority: Major
>
> The [*current authorization 
> model*|https://issues.apache.org/jira/browse/OOZIE-228] does not fit the 
> enterprise requirements as everything is readable and writable by everyone by 
> default.
> Write access can be restricted using authorization but restricting read 
> rights is only possible via Yarn ACLs and HDFS rights which still does not 
> prevent accessing the workflow, coordinator or bundle job’s configurations 
> for everyone.
> Improve authorization so it’s possible to configure read/write access for 
> workflows, coordinators, and bundles in a more granular way. Could involve 
> Sentry during implementation or create and design a new system that fits the 
> needs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (OOZIE-3196) Authorization: restrict world readability by user

2018-04-03 Thread Artem Ervits (JIRA)

[ 
https://issues.apache.org/jira/browse/OOZIE-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16424481#comment-16424481
 ] 

Artem Ervits edited comment on OOZIE-3196 at 4/3/18 7:30 PM:
-

In order of priority:

1. Prevent UI access to private information

2. Prevent REST API access to private information

3. Prevent CLI access to private information

at the minimum this should be configurable at the oozie-site.xml level, when 
Oozie is restarted.

 


was (Author: dbist13):
In order of priority:

1. Prevent UI access to private information

2. Prevent REST API access to private information

3. Prevent CLI access to private information

> Authorization: restrict world readability by user
> -
>
> Key: OOZIE-3196
> URL: https://issues.apache.org/jira/browse/OOZIE-3196
> Project: Oozie
>  Issue Type: New Feature
>  Components: bundle, coordinator, workflow
>Affects Versions: 5.0.0b1
>Reporter: Andras Piros
>Assignee: Peter Orova
>Priority: Major
>
> The [*current authorization 
> model*|https://issues.apache.org/jira/browse/OOZIE-228] does not fit the 
> enterprise requirements as everything is readable and writable by everyone by 
> default.
> Write access can be restricted using authorization but restricting read 
> rights is only possible via Yarn ACLs and HDFS rights which still does not 
> prevent accessing the workflow, coordinator or bundle job’s configurations 
> for everyone.
> Improve authorization so it’s possible to configure read/write access for 
> workflows, coordinators, and bundles in a more granular way. Could involve 
> Sentry during implementation or create and design a new system that fits the 
> needs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (OOZIE-3196) Authorization: restrict world readability by user

2018-03-20 Thread Artem Ervits (JIRA)

[ 
https://issues.apache.org/jira/browse/OOZIE-3196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406625#comment-16406625
 ] 

Artem Ervits edited comment on OOZIE-3196 at 3/20/18 4:32 PM:
--

this is a wonderful idea, at the minimum, implementation should be internal to 
Oozie not (Sentry, Ranger) specific. There should be a property file with Oozie 
authorizations and provide an interface for external projects to tap into.

Do we want this for per workflow, per coordinator, per bundle, per action?

feedback I got from customers is that they want jobs to be more private, 
prevent user from seeing a workflow, see job.properties (passwords), job logs, 
etc.


was (Author: dbist13):
this is a wonderful idea, at the minimum, implementation should be internal to 
Oozie not (Sentry, Ranger) specific. There should be a property file with Oozie 
authorizations and provide an interface for external projects to tap into.

Do we want this for per workflow, per coordinator, per bundle, per action?

feedback I got from customers is that they want jobs to be more private, 
prevent user from seeing a workflow, see job.properties (passwords).

> Authorization: restrict world readability by user
> -
>
> Key: OOZIE-3196
> URL: https://issues.apache.org/jira/browse/OOZIE-3196
> Project: Oozie
>  Issue Type: New Feature
>  Components: bundle, coordinator, workflow
>Affects Versions: 5.0.0b1
>Reporter: Andras Piros
>Priority: Major
>
> The [*current authorization 
> model*|https://issues.apache.org/jira/browse/OOZIE-228] does not fit the 
> enterprise requirements as everything is readable and writable by everyone by 
> default.
> Write access can be restricted using authorization but restricting read 
> rights is only possible via Yarn ACLs and HDFS rights which still does not 
> prevent accessing the workflow, coordinator or bundle job’s configurations 
> for everyone.
> Improve authorization so it’s possible to configure read/write access for 
> workflows, coordinators, and bundles in a more granular way. Could involve 
> Sentry during implementation or create and design a new system that fits the 
> needs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)