What is the difference between master and ranger-2.3?
What are the main feature differences between these two branches at present? What kind of patch should only be submitted to the master?
[jira] [Updated] (RANGER-3630) Support wildcards, group short names, and list of memberof attribute DNs for computing user search filter
[ https://issues.apache.org/jira/browse/RANGER-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3630: --- Fix Version/s: 3.0.0 > Support wildcards, group short names, and list of memberof attribute DNs for > computing user search filter > - > > Key: RANGER-3630 > URL: https://issues.apache.org/jira/browse/RANGER-3630 > Project: Ranger > Issue Type: New Feature > Components: Ranger, usersync >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-3630-Added-code-to-support-wildcards-group-sh.patch, > RANGER-3630_proposal.pdf > > > Ranger Usersync provides multiple configuration properties to sync users & > groups from AD/LDAP. One of the key configuration properties is the User > Search filter (ranger.usersync.ldap.user.searchfilter). Currently, the value > of user search filter must be a valid ldap search filter and is used by > ranger usersync “as is” to limit the no. of users to be sync’d from AD/LDAP. > Example values include: > # samaccountname=* > ** Syncs all users from a given user search base > # (|(memberof=CN=finance,ou=Hadoop > Groups,dc=apache,dc=org)(memberof=CN=eng_dev,ou=Hadoop > Groups,dc=apache,dc=org)(memberof=CN=eng_testing,ou=Hadoop > Groups,dc=apache,dc=org)) > ** Sync users that are members of finance, eng_dev, and eng_testing groups > According to [Microsoft > documentation|https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx], > the wildcard character * is not allowed when the is a DN > attribute. Examples of DN attributes are distinguishedName, manager, > directReports, member, and memberOf. If users need to be sync'd from multiple > Active Directory groups with memberOf filters, this value can quickly become > a long string of OR concatenated group DNs. A single misplaced character in > this cryptic string results in all users failing to sync. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (RANGER-3657) Support for recursive ACL check for subpaths in Ozone plugin
[
https://issues.apache.org/jira/browse/RANGER-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Polavarapu reassigned RANGER-3657:
--
Assignee: Sailaja Polavarapu
> Support for recursive ACL check for subpaths in Ozone plugin
>
>
> Key: RANGER-3657
> URL: https://issues.apache.org/jira/browse/RANGER-3657
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Major
>
> This task is to implement {{recursive}} ACL check in
> {{{}RangerOzoneAuthorizer{}}}, using the below interface. OzoneRanger can
> build an optimized recursive ACL check similar to HDFS -
> [Reference|https://github.com/apache/ranger/blob/master/hdfs-agent/src/main/java/org/apache/ranger/authorization/hadoop/RangerHdfsAuthorizer.java#L444]
>
> {code:java}
> IAccessAuthorizer#checkAccess(IOzoneObj ozoneObject, RequestContext context)
> public class RequestContext {
> …...
> /**
> * Represents recursive access check required for all the sub-paths of
> the
> * given path. If the given path is not a directory, there is no effect
> for
> * this flag. A true value represents recursive check, false represents
> * non-recursive check.
> */
> private final boolean recursiveAccessCheck; // introducing new
> attribute for recursive access checks.
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (RANGER-3657) Support for recursive ACL check for subpaths in Ozone plugin
Sailaja Polavarapu created RANGER-3657:
--
Summary: Support for recursive ACL check for subpaths in Ozone
plugin
Key: RANGER-3657
URL: https://issues.apache.org/jira/browse/RANGER-3657
Project: Ranger
Issue Type: Improvement
Components: Ranger
Reporter: Sailaja Polavarapu
This task is to implement {{recursive}} ACL check in
{{{}RangerOzoneAuthorizer{}}}, using the below interface. OzoneRanger can build
an optimized recursive ACL check similar to HDFS -
[Reference|https://github.com/apache/ranger/blob/master/hdfs-agent/src/main/java/org/apache/ranger/authorization/hadoop/RangerHdfsAuthorizer.java#L444]
{code:java}
IAccessAuthorizer#checkAccess(IOzoneObj ozoneObject, RequestContext context)
public class RequestContext {
…...
/**
* Represents recursive access check required for all the sub-paths of the
* given path. If the given path is not a directory, there is no effect for
* this flag. A true value represents recursive check, false represents
* non-recursive check.
*/
private final boolean recursiveAccessCheck; // introducing new attribute
for recursive access checks.
}{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (RANGER-3656) Hive Plugin Not Compatible With Hive 2.3.9
Joseph Wheeler created RANGER-3656: -- Summary: Hive Plugin Not Compatible With Hive 2.3.9 Key: RANGER-3656 URL: https://issues.apache.org/jira/browse/RANGER-3656 Project: Ranger Issue Type: Bug Components: plugins Affects Versions: 2.1.0 Reporter: Joseph Wheeler Ranger Hive Plugin 2.1.0 is not compatible with Hive 2.3.9. Error on Hive 2.3.9 when trying to start HiveServer2: java.lang.NoClassDefFoundError: org/apache/hadoop/hive/ql/security/authorization/plugin/HivePolicyProvider at org.apache.ranger.authorization.hive.authorizer.RangerHiveAuthorizerFactory.createHiveAuthorizer(RangerHiveAuthorizerFactory.java:37) ~[ranger-hive-plugin-2.1.0.jar:2.1.0] Specific class is present in hive-exec-3.1.2.jar, but not in hive-exec-2.3.9.jar. Unable to upgrade to Hive 3.1.2 as it does not support Spark 3.x, and Spark 2.3.x has numerous vulnerabilities. -- This message was sent by Atlassian Jira (v8.20.1#820001)
Re: Review Request 73880: RANGER-3231: Ranger-Kafka-Plugin implementing Kafka Authorizer from KIP-504
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/73880/ --- (Updated March 8, 2022, 12:27 p.m.) Review request for ranger and Ramesh Mani. Changes --- logging fix for request context Bugs: RANGER-3231 https://issues.apache.org/jira/browse/RANGER-3231 Repository: ranger Description --- kafka.security.auth.Authorizer has been deprecated since December 2019, and it's removed in Apache Kafka 3.0 Diffs (updated) - plugin-kafka/pom.xml d95f591fe plugin-kafka/src/main/java/org/apache/ranger/authorization/kafka/authorizer/RangerKafkaAuthorizer.java 97a2f2ec7 ranger-kafka-plugin-shim/pom.xml 3264138a8 ranger-kafka-plugin-shim/src/main/java/org/apache/ranger/authorization/kafka/authorizer/RangerKafkaAuthorizer.java b84b765c2 Diff: https://reviews.apache.org/r/73880/diff/2/ Changes: https://reviews.apache.org/r/73880/diff/1-2/ Testing --- unit tests executed via maven related PR: https://github.com/apache/ranger/pull/133 - currently executing checks, last time failed with unrelated compile error: missing dependency Thanks, Andras Katona
[jira] [Commented] (RANGER-2362) [security] Admin webui - Lack of account lockout
[ https://issues.apache.org/jira/browse/RANGER-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502875#comment-17502875 ] kirby zhou commented on RANGER-2362: [https://mkyong.com/spring-security/spring-security-limit-login-attempts-example/] It is a in-database attempts-count resolution of lockout. But it requires to update our database schema. I think a in-memory attempts-count is enough in most case. > [security] Admin webui - Lack of account lockout > > > Key: RANGER-2362 > URL: https://issues.apache.org/jira/browse/RANGER-2362 > Project: Ranger > Issue Type: Bug > Components: admin, Ranger >Affects Versions: 1.0.0 >Reporter: t oo >Priority: Major > > |Account lockout is a mechanism used to stop non-valid users from guessing > for the right password. It is also a protection against brute force attacks > wherein an automated system can use common/dictionary passwords or even build > passwords based on set of characters just to try to guess the valid one.| > |The application does not implement an account lockout mechanism, leaving it > susceptible to brute force attacks. These login pages were susceptible to > this condition.| > |It is possible for an attacker to use dictionary or brute force attacks and > set it to attempt sending the requests on a particular amount of time to > bypass the validation. Once a username has been correctly guessed, the > attacker may then be able to gain access to the application. Since it is > vulnerable to Form Auto Complete Active vulnerability (LINK) which makes the > email addresses easier to guess, it will make brute force attack to more > likely possible. > |Enforce account lockout conditions to prevent intrusions and improve > password requirements and complexities to avoid the chances of brute force > and dictionary attacks from working.| > | -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (RANGER-2362) [security] Admin webui - Lack of account lockout
[ https://issues.apache.org/jira/browse/RANGER-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502872#comment-17502872 ] kirby zhou commented on RANGER-2362: I think way 1 is unacceptable. Small clusters DO NOT want to link LDAP/AD just for authentication. In most cases, we only need few admin users to log in to ranger. > [security] Admin webui - Lack of account lockout > > > Key: RANGER-2362 > URL: https://issues.apache.org/jira/browse/RANGER-2362 > Project: Ranger > Issue Type: Bug > Components: admin, Ranger >Affects Versions: 1.0.0 >Reporter: t oo >Priority: Major > > |Account lockout is a mechanism used to stop non-valid users from guessing > for the right password. It is also a protection against brute force attacks > wherein an automated system can use common/dictionary passwords or even build > passwords based on set of characters just to try to guess the valid one.| > |The application does not implement an account lockout mechanism, leaving it > susceptible to brute force attacks. These login pages were susceptible to > this condition.| > |It is possible for an attacker to use dictionary or brute force attacks and > set it to attempt sending the requests on a particular amount of time to > bypass the validation. Once a username has been correctly guessed, the > attacker may then be able to gain access to the application. Since it is > vulnerable to Form Auto Complete Active vulnerability (LINK) which makes the > email addresses easier to guess, it will make brute force attack to more > likely possible. > |Enforce account lockout conditions to prevent intrusions and improve > password requirements and complexities to avoid the chances of brute force > and dictionary attacks from working.| > | -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (RANGER-2362) [security] Admin webui - Lack of account lockout
[ https://issues.apache.org/jira/browse/RANGER-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502860#comment-17502860 ] Bhavik Patel commented on RANGER-2362: -- We have 2 approach: 1. We can move all the DB(internal) users to external user so LDAP/AD will handle the lockout mechanism - Required to check all the impacts 2. We have to implement the account lockout mechanise for Internal users(using spring security) - Required to check spring configuration and code level changes > [security] Admin webui - Lack of account lockout > > > Key: RANGER-2362 > URL: https://issues.apache.org/jira/browse/RANGER-2362 > Project: Ranger > Issue Type: Bug > Components: admin, Ranger >Affects Versions: 1.0.0 >Reporter: t oo >Priority: Major > > |Account lockout is a mechanism used to stop non-valid users from guessing > for the right password. It is also a protection against brute force attacks > wherein an automated system can use common/dictionary passwords or even build > passwords based on set of characters just to try to guess the valid one.| > |The application does not implement an account lockout mechanism, leaving it > susceptible to brute force attacks. These login pages were susceptible to > this condition.| > |It is possible for an attacker to use dictionary or brute force attacks and > set it to attempt sending the requests on a particular amount of time to > bypass the validation. Once a username has been correctly guessed, the > attacker may then be able to gain access to the application. Since it is > vulnerable to Form Auto Complete Active vulnerability (LINK) which makes the > email addresses easier to guess, it will make brute force attack to more > likely possible. > |Enforce account lockout conditions to prevent intrusions and improve > password requirements and complexities to avoid the chances of brute force > and dictionary attacks from working.| > | -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (RANGER-2362) [security] Admin webui - Lack of account lockout
[
https://issues.apache.org/jira/browse/RANGER-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502823#comment-17502823
]
kirby zhou commented on RANGER-2362:
Authentication backend such as ldapam has its own lockout mechanism, so just
need to do somethings at JDBC branch. Which is DaoAuthenticationProvider,
DaoAuthenticationProvider::retrieveUser call
UserDetailsService::loadUsersByUsername to get user details. UserDetails have a
Nonlocked property.
The UserDetailsService object is actually a JdbcUserDetailsManager.
Unfortunately JdbcUserDetailsManager|JdbcDaoImpl::loadUsersByUsername do not
load "Nonlocked" from Database, although it loads "enabled" which used by
admin to disable user by hand.
{code:java}
protected List loadUsersByUsername(String username) {
// @formatter:off
RowMapper mapper = (rs, rowNum) -> {
String username1 = rs.getString(1);
String password = rs.getString(2);
boolean enabled = rs.getBoolean(3);
return new User(username1, password, enabled, true, true, /* nonlocked:
*/ true, AuthorityUtils.NO_AUTHORITIES);
};
// @formatter:on
return getJdbcTemplate().query(this.usersByUsernameQuery, mapper, username);
} {code}
An Simple Way:
subclass DaoAuthenticationProvider to provide a in-memory lock mech.
override additionalAuthenticationChecks to lock user when many failures.
override retrieveUser to set nonlocked attr into UserDetails.
> [security] Admin webui - Lack of account lockout
>
>
> Key: RANGER-2362
> URL: https://issues.apache.org/jira/browse/RANGER-2362
> Project: Ranger
> Issue Type: Bug
> Components: admin, Ranger
>Affects Versions: 1.0.0
>Reporter: t oo
>Priority: Major
>
> |Account lockout is a mechanism used to stop non-valid users from guessing
> for the right password. It is also a protection against brute force attacks
> wherein an automated system can use common/dictionary passwords or even build
> passwords based on set of characters just to try to guess the valid one.|
> |The application does not implement an account lockout mechanism, leaving it
> susceptible to brute force attacks. These login pages were susceptible to
> this condition.|
> |It is possible for an attacker to use dictionary or brute force attacks and
> set it to attempt sending the requests on a particular amount of time to
> bypass the validation. Once a username has been correctly guessed, the
> attacker may then be able to gain access to the application. Since it is
> vulnerable to Form Auto Complete Active vulnerability (LINK) which makes the
> email addresses easier to guess, it will make brute force attack to more
> likely possible.
> |Enforce account lockout conditions to prevent intrusions and improve
> password requirements and complexities to avoid the chances of brute force
> and dictionary attacks from working.|
> |
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[Blog] Introduction to Apache Ranger Policy Model
Ranger community, Please take few minutes to read this blog on Apache Ranger Policy Model, the core of Apache Ranger - https://blogs.apache.org/ranger/entry/apache-ranger-policy-model. This is the first of many blogs to come. If you would like specific topics to be covered, please send your suggestions. Hope you find this useful. Madhan
[jira] [Resolved] (RANGER-3603) HDFS audit files rollover improvement to trigger rollover in monitoring thread
[ https://issues.apache.org/jira/browse/RANGER-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani resolved RANGER-3603. - Resolution: Fixed > HDFS audit files rollover improvement to trigger rollover in monitoring thread > -- > > Key: RANGER-3603 > URL: https://issues.apache.org/jira/browse/RANGER-3603 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0, 2.3.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0, 2.3.0 > > Attachments: RANGER-3603.rtf > > > HDFS audit files rollover improvement to trigger rollover in monitoring > thread. Currently file rollover happens based on the audit event occurrence. > If there are no event happening, then the created hdfs or any cloud location > audit file will be kept opened until an auditing event occurs. This result in > files that are opened beyond the configured rollover time. e.g if the file > rollover time is 1 day, some files are kept opened beyond 1 day. This may > cause some inconvenience when audit files are read by an external tools for > analysis on a daily basis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (RANGER-3603) HDFS audit files rollover improvement to trigger rollover in monitoring thread
[ https://issues.apache.org/jira/browse/RANGER-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Mani updated RANGER-3603: Affects Version/s: 2.3.0 (was: 2.2.0) > HDFS audit files rollover improvement to trigger rollover in monitoring thread > -- > > Key: RANGER-3603 > URL: https://issues.apache.org/jira/browse/RANGER-3603 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Affects Versions: 3.0.0, 2.3.0 >Reporter: Ramesh Mani >Assignee: Ramesh Mani >Priority: Major > Fix For: 3.0.0, 2.3.0 > > Attachments: RANGER-3603.rtf > > > HDFS audit files rollover improvement to trigger rollover in monitoring > thread. Currently file rollover happens based on the audit event occurrence. > If there are no event happening, then the created hdfs or any cloud location > audit file will be kept opened until an auditing event occurs. This result in > files that are opened beyond the configured rollover time. e.g if the file > rollover time is 1 day, some files are kept opened beyond 1 day. This may > cause some inconvenience when audit files are read by an external tools for > analysis on a daily basis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
