Fatal编程技术网
  • hadoop/
  • 授权Hadoop用户而不使用Sentry

授权Hadoop用户而不使用Sentry

hadoop hive permissions

授权Hadoop用户而不使用Sentry,hadoop,hive,permissions,impala,Hadoop,Hive,Permissions,Impala,我有一个Kerberized CDH集群，其中有一些日常oozie工作流正在运行。它们都使用shell、impala shell、hive和sqoop将数据摄取到hive表中（我们将这些表称为SensitiveTables） 现在，我想创建两个新的BI用户来使用集群，并对一些其他摄取的数据进行实验 要求这些新BI用户： 不应访问敏感表 应该能够spark向集群提交作业 （可选）使用色调 除了设置（这是推荐的方式），是否有机会使用文件权限或ACL和服务级别授权来满足这些要求 到目前为止，我设法

我有一个Kerberized CDH集群，其中有一些日常oozie工作流正在运行。它们都使用
shell
、
impala shell
、
hive
和
sqoop
将数据摄取到hive表中（我们将这些表称为
SensitiveTables
）

现在，我想创建两个新的BI用户来使用集群，并对一些其他摄取的数据进行实验

要求这些新BI用户：

  • 不应访问
    敏感表
  • 应该能够
    spark向集群提交
    作业
  • （可选）使用色调
除了设置（这是推荐的方式），是否有机会使用文件权限或ACL和服务级别授权来满足这些要求

到目前为止，我设法（通过
hadoop fs-chmod o-rwx/user/hive/warehouse/sensitive
）通过hive（使用用户模拟）限制对
SensitiveTables
的访问，但未能通过Impala（它将所有作业作为用户
Impala
提交到集群）。还有什么我应该试试的吗

谢谢,

Gee

经过大量研究，根据我描述的假设，答案是否定的。此外，元存储不能以这种方式保护。

当然，你是对的。谢谢你。设立哨兵并不难。它只是一个额外的SPOF（或者更确切地说是2，因为它不支持Metastore HA）。另一方面，它将解决有关ACL无法正确传播的HDFS错误（在Hadoop 3之前尚未修复）。看起来Cloudera故意在黑斑羚中未开发适当的授权，将人们锁定在哨兵中。但他们似乎不再在哨兵身上投资了；他们转向了销售人员可以夸耀的闪亮新玩具（Kudu，数据科学工作台）。最终，他们会转而使用另一种新玩具，并将所有半生不熟的项目抛在脑后（还记得Sqoop2吗…？）