Hi Folks, I would love to talk about expanding scope of Ranger! Features:
1. Handling fine-grained access (FGA) on the attributes within arbitrary nestedstructures (eg JSON responses to API calls). I just submitted RANGER-3828<https://issues.apache.org/jira/browse/RANGER-3828>, which does just that for JSON structures (Review request 74057<https://reviews.apache.org/r/74057/>). It could be expanded to include avro, etc. We use it for FGA on API JSON response objects, but it or something like it could be used in a kafka or kinesis client, perhaps. The same modeling of nestedstructures could be used within, say, the hive service to handle struct-valued attributes. (I know some folks are skeptical, but I hope to convince them with working code soon!!!) 2. For custom ABAC policies, which are increasingly important to us, Context Enrichers/Policy Evaluators and the new RangerUserStoreRetriever are totally awesome, but a tad inflexible. For example, I’d love for it to be easy to make the data from a context enricher available in tag policy conditions. I have a context enricher that represents a mapping from user to the set of business partners whose data they are permitted to view (“userPartners”). Assuming a partner tag on, say, a hive table, I wish I could write something like “userPartners.includes(tagAttr.get(‘value’))”. Or even better, UserPartners.intersects(tagAttr.get(‘value’)), where tagAttr.get(‘value’) is a set of partners. (The inability of Ranger to handle set-valued tag attributes when Atlas has long handled them perplexes me.). In effect, I’d like there to be a single context that is enriched, and from which any policy type can access data. Tag enrichment shouldn’t be separate from other enrichments. 3. A single Tagsync resource mapper service should support multiple “components”, as long as their resources are the same. This is most obvious in a development environment: since new contextenrichers require change to servicedefs, it’s crazy to have 5 hive tagsync servers, one for each servicedef, while one tries them out. I can also imagine including different contextextenders (and therefore servicedefs) for different user populations in a production context (for performance if nothing else), and that should not require a separate tagsync service for each. We use Ranger primarily on databricks in AWS and Starburst/Trino. We’re expanding to include Athena on AWS, and OS Spark on K8S on MinIO. Barbara On 2022/06/30 19:27:15 Madhan Neethiraj wrote: > (added [email protected]<mailto:[email protected]> back in this > thread) > > cdmikechen - thank you for your response. > > Selva - thank you for starting this thread. Responses from the community will > help prioritize next set of enhancements in Apache Ranger. Looking forward to > more responses from Apache Ranger community. > > I think enabling Apache Ranger authorization to services that don't support > pluggable authorization will be of immense value. This is critical especially > as enterprises use various cloud services where the service provider may not > support a pluggable authorizer model. Such enhancements to authorization > framework will help extend Apache Ranger authorization to services like > Databricks SQL, Snowflake, Google BigQuery, AWS Redshift, MS-SQL, Postgres, > and more. > > Thanks, > Madhan > > On 6/17/22, 12:09 AM, "陈 翔" > <[email protected]<mailto:[email protected]>> wrote: > > 1. My company has used ranger from 1.2.0 and updated to 2.3.0 > recently. > > 2. At present, my company mainly use ranger with hive and atlas. > > 3. I personally hope to support Drill or Druid. > > 4. I hope that the installation of ranger can be easier (for > example, remove Python dependency when installing), and I also hope that > other authentication methods such as oauth2/oidc can be supported. At the > same time, my company runs the Ranger service in k8s. We have developed an > k8s operator to simplify deployment and using. If possible in the future, I > will put relevant projects to Github. > > 5. Not yet. > > Hopefully this will help the community~ > Thanks > > > 发件人: [email protected]<mailto:[email protected]> > <[email protected]<mailto:[email protected]>> > 日期: 星期五, 2022年6月17日 上午10:43 > 收件人: [email protected]<mailto:[email protected]> > <[email protected]<mailto:[email protected]>>, > [email protected]<mailto:[email protected]> > <[email protected]<mailto:[email protected]>>, > [email protected]<mailto:[email protected]> > <[email protected]<mailto:[email protected]>> > 主题: Need community feedback on expanding scope of Apache Ranger > As Apache Ranger has taken a critical role in Security & Governance > of the big data/Hadoop technologies, I would like to see if the scope of > Apache Ranger can be extended to cover other areas such as CLOUD data > sources. To identify the industry needs, can you please provide some feedback > on your current Apache Ranger use and your future needs: > > > 1. Do you currently use Apache Ranger? If so, What Version? > 2. Apache Ranger supports authorization for 20+ data > sources/services. For which data sources/services do you use Apache Ranger > authorization? > 3. What additional data sources/services would you like to have > Apache Ranger authorization? > 4. What new features/enhancements would you like to see in Apache > Ranger? > 5. Have you developed Apache Ranger plugins for any data > sources/services? If yes, please list them. > > As a community, we can review this (feedback) information to create > more backlog tasks for us to scope the next major release. > > Thanks, > Selva- > > -- Barbara Eckman, Ph.D. she/her/hers Distinguished Architect Enterprise Metadata, Lineage and Access Control Comcast [Logo Description automatically generated] [signature_951927206]
