关于大数据:大数据生态安全框架的实现原理与最佳实践下篇

前言

数字化转型大背景下，数据作为企业重要的策略资产，其平安的重要性显而易见。

咱们会通过系列文章，来看下大数据生态中平安框架的实现原理与最佳实际，系列文章一共两篇，蕴含以下章节：

• 大数据生态平安框架概述
• HDFS 认证详解
• HDFS 受权详解
• HIVE 认证详解
• HIVE 受权详解
• 金融行业大数据安全最佳实际

本片文章是下篇，蕴含上述后三个章节，心愿大家喜爱。

1. HIVE 认证详解

• HIVE 的认证形式，通过参数 hive.server2.authentication 在服务端进行对立配置；
• 该参数可选的值次要有三种：hive.server2.authentication=none/kerberos/ldap
• HIVE 的客户端，不论是 beeline 等专用 cli 客户端，还是 dbeaver 等通用 jdbc gui 客户端，抑或 JAVA 利用（基于 jdbc），都须要依据服务端配置的认证形式，应用对应的形式，进行认证后能力胜利连上 hiveserver2，进而提交查问命令。

• 视乎大数据集群中是否开启了 kerberos，理论的认证形式，分为以下四种：

  • 无认证模式
  • 只开启 LDAP 认证模式
  • 只开启 Kerberos 认证模式

  • 开启 Kerberos 和 LDAP 双重认证模式

    1.1 无认证模式:hive.server2.authentication = none

• 当不须要对用户身份进行校验，能够配置 hive.server2.authentication = none, 这种境况常常用在测试环境，生产环境个别不举荐;
• 此时用户通过各种客户端如 cli/gui/java 登录时，能够不配置用户名和明码, 在服务端 Hive 会认为登录的是匿名用户 anonymous,（这点不同于 hdfs, 当没有开启 kerberos 平安时，如果没有配置 环境变量或零碎参数 Hadoop_user_name,hdfs 的默认用户是提交作业的 LINUX 零碎用户）如：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default
• 此时用户通过各种客户端如 cli/gui/java 登录时，也能够配置为任意用户名和任意明码, 在服务端 Hive 会认为登录的是用户申明的任意用户（用户名能够是任意用户名，甚至是不存在的用户名；明码能够是任意明码，或不配置明码），如：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n xyz；beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n xyz -p xxxx
• 能够通过 hiveserver2 webui，验证登录的用户身份；

1.2 只开启 LDAP 认证模式:hive.server2.authentication = ldap

• 中大型企业中个别都会有用户身份的对立认证平台，其底层个别都应用 ldap 协定，其具体实现有微软的 ActiveDirectory，也有 openLdap, ApacheDS 等开源实现；
• Hive 提供了基于 Ldap 的认证机制，能够应用企业的对立认证平台，来验证登录 hive 的用户的身份, 其配置形式：hive.server2.authentication = ldap;
• 具体的 ldap 工具的 url，须要通过参数指定：hive.server2.authentication.ldap.url；
• 除了集成商业版的 ActiveDirectory，大数据集群中也能够应用独立装置的开源的 ldap 工具，此类工具常见的有 openLdap 和 ApacheDS，其中前者在大部分 linux 发行版中都自带了 package 安装包，更容易装置，不过次要通过命令行 cli 进行治理；而后者则自带了 gui 客户端 Apache Directory Studio，性能更为丰盛；以 openLdap 为例，其装置命令如下：sudo yum -y install openldap-clients; sudo yum -y install openldap;
• 客户端登录 ldap 认证的 hiveserver2 时，须要提供用户名和明码，hiveserver2 会到 ldap 中验证用户名和明码，只有验证通过后能力失常登录；

• 以 beeline 登录为例，其命令格局如下：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n ldapUserName -p ldapUserPwd;

  1.3 HIVE 在 kerberos 环境下的认证

• 大数据生态中的各种存储系统，如 HDFS/hive/hbase/zookeeper/kafka 等，都反对开启 Kerberos 平安认证；
• 当大数据集群中的存储系统如 HDFS/hive/hbase/zookeeper/kafka 等开启了 kerberos 平安认证后，拜访这些存储系统的客户端，蕴含各种计算引擎如 hive/hbase/spark/flink 的零碎服务，和用户编写的各种利用如 spark/hive/flink 等，都须要通过 kerberos kdc 的认证取得了 ticket 凭证后，能力与这些存储系统进行失常交互；
• 具体到 hiveserver2，其在跟开启了 kerberos 平安认证的 hdfs/yarn/hbase 等交互时，同样须要配置应用相应的 kerberos principal(个别配置为 hive)，且只有在通过 kdc 验证取得 ticket 后，能力与 hdfs/yarn/zk 进行交互,hive-site.xml 中，相干配置项截图如下：

• 在开启了 kerberos 平安认证的大数据集群环境中，HIVE 既能够配置应用 kerberos 认证机制，也能够配置应用 LDAP 认证机制：hive.server2.authentication = kerberos/ldap，别离对应上文所说的，只开启 Keberos 认证模式 和 开启 Kerberos 认证和 LDA 认证模式

  1.4 只开启 Kerberos 认证模式:hive.server2.authentication = kerberos

• 配置 hive.server2.authentication = kerberos，即要求 hiveserver2 的各种客户端如 cli/gui/java jdbc，只有在通过 kerberos 认证取得 ticket 后，能力失常登陆 hiveserver2 进而提交 sql；
• 因为是在 kerberos 环境下，所以客户端在登录前，须要首先从 kdc 获取 ticket 并保护在 ticket cache 中：a valid Kerberos ticket in the ticket cache before connecting；
• 如果是 cli/beeline 等客户端，个别会通过命令 kinit，基于手工输出的明码或 keytab 文件，来获取特定业务用户的 ticket，并存储在客户端的 ticket cache 中；（如果缓存的 ticket 过期了，须要从新获取）；
• 如果是程序代码，则个别通过 org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(String user, String path) 的形式，基于 keytab 文件来获取特定业务用户的 ticket，并存储在客户端的 ticket cache 中；（UserGroupInformation 在后盾会主动基于 keytab 文件来定时刷新 ticket，确保不会过期）；
• 客户端在获取业务用户的 ticket 胜利后，才能够通过 jdbc 连贯，登录到指定的 hiveserver2；

• 客户端在获取业务用户的 ticket 胜利后，通过 jdbc 连贯登录到指定的 hiveserver2 时，须要特地留神下 hiveserver2 的 url 的格局，其格局举荐应用：jdbc:hive2://xx.xx.xx.xx:10000/default;principal=hive/_HOST@CDH.COM：

  • 这里的 principal 局部，举荐应用三段式来指定，蕴含 pincipal, host 和 realm;
  • pincipal 必须指定为零碎用户 hive，而不能是业务用户如 dap,xyz 等（实质上是因为，hive-site.xml 中配置的 hive 零碎用户是 hive）；
  • host 局部，举荐指定为_HOST，此时在底层应用时会替换为 hiveserver2 节点的 hostname（当然也能够间接指定为 hiveserver2 节点的具体的 hostname）；
  • realm 局部，须要依据理论配置状况进行指定（能够查看配置文件 /etc/krb5.conf）；

  1.5 开启 Kerberos 和 LDAP 双重认证模式:hive.server2.authentication = ldap

• 配置 hive.server2.authentication = ldap，即要求 hiveserver2 的各种客户端如 cli/gui/java jdbc，须要提供用户名和明码，且 hiveserver2 会到 ldap 中验证用户名和明码，只有验证通过后，能力失常登陆 hiveserver2 进而提交 sql；（当然因为整个大数据环境开启了 kerberos, 所以在登录 hiveserver2 之前，一样要通过 kerberos kdc 的认证）
• 因为是在 kerberos 环境下，所以客户端在登录前，须要首先从 kdc 获取 ticket 并保护在 ticket cache 中，这一点跟 kerberos 环境下，hive 的 kerberos 认证形式时始终的：a valid Kerberos ticket in the ticket cache before connecting：
• 如果是 cli/beeline 等客户端，个别会通过命令 kinit，基于手工输出的明码或 keytab 文件，来获取特定业务用户的 ticket，并存储在客户端的 ticket cache 中；（如果缓存的 ticket 过期了，须要从新获取）；
• 如果是程序代码，则个别通过 org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(String user, String path) 的形式，基于 keytab 文件来获取特定业务用户的 ticket，并存储在客户端的 ticket cache 中；（UserGroupInformation 在后盾会主动基于 keytab 文件来定时刷新 ticket，确保不会过期）；

• 客户端在获取业务用户的 ticket 胜利后，才能够通过 jdbc 连贯，登录到指定的 hiveserver2，此时登录格局，跟非 kerberos 环境下，hive 的 ldap 认证形式，是一样的:

  • 此时须要提供用户名和明码，hiveserver2 会到 ldap 服务器中验证用户名和明码，只有验证通过后能力失常登录；
  • 以 beeline 登录为例，其命令格局如下：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n ldapUserName -p ldapUserPwd;

1.6 大数据平台 CDH/TDH/CDP 与 TDH 中，hive 认证形式的差别

• 客户端可用的登录形式，实质上取决于服务端的具体配置；
• 在 TDH 环境下，在大数据集群开启了 kerberos 平安认证的环境下，如果 hive 服务端配置了应用 ldap（hive.server2.authentication = ldap），则必须通过 kerberos 和 ldap 的双重认证后，能力登陆 hiveserver2；
• 在 CDH/CDP 环境下，在 CDH 5.7 及当前的版本中，Cloudera 对 hive 的平安认证进行了加强：在大数据集群开启了 kerberos 平安认证的环境下，即便 hive 服务端配置了应用 ldap（hive.server2.authentication = ldap），客户端也能够通过 url 指定应用 KERBEROS 认证形式来登录；此时理论的业务用户，是登录前，通过 kinit 指定的业务用户！！！此时须要留神，url 中须要指定 principal=HIVE/_HOST@CDH.COM, 以示默认的 ldap 认证形式下，理论应用的是 kerberos 认证形式！！！

• TDH 中，通过平安组件 Guardian 来治理各个组件的平安，Guardian 底层整合了 kerberos 和 ApacheDS；
• TDH 中，同样反对以上四种认证形式，其举荐的 hive 认证形式，其实等同于“kerberos 环境下，hive 的 LDAP 认证形式 : hive.server2.authentication = ldap”；
• 在 TDH 中配置 inceptor 应用“开启 Kerberos 认证和 LDAP 认证模式”，并不需要额定装置 OpenLdap/ApacheDS/microsoft AD 等 ldap 的具体实现，也不须要跟企业外部对立的 LDAP 服务器买通，也不存在泄露企业域账号用户名和明码的危险，因为底层理论应用的是 Guardien 底层自带的一个 ldap 实现（实质是 ApacheDS），创立用户更改明码等操作都是在 Guardien 中操作的，跟企业域账户是独立的；

1.7 HIVE 认证相干参数

hive-site.xml 中，认证相干参数次要有：

• hive.server2.authentication
• hive.server2.authentication.kerberos.keytab
• hive.server2.authentication.kerberos.principal
• hive.server2.authentication.spnego.keytab
• hive.server2.authentication.spnego.principal
• hive.server2.authentication.ldap.url
• hive.server2.authentication.ldap.baseDN
• hive.server2.authentication.ldap.Domain
• hive.metastore.kerberos.keytab.file
• hive.metastore.kerberos.principal
• hive.server2.enable.doAs/hive.server2.enable.impersnation

2. HIVE 受权详解

先来回顾下 hive 的整体架构：

• hive 整体分为客户端和服务端两局部；
• 客户端包含 hive cli, beeline，webui 等；
• 服务端又分为 hiveserver2 和 hms，以及底层的元数据长久存储 metastore db;
• Hive 又作为 hadoop 的客户端，拜访底层的 hdfs 和 yarn;

以后市面上 HIVE 的应用形式分两种：

• 只应用 HMS，将 hive 看做是独自的 table format layer，比方 spark/flink on hive: Hive as a table storage layer：These users have direct access to HDFS and the metastore server (which provides an API for metadata access)；
• 残缺地应用 hive，包含 hiveserver2+ hms, 比方 hive on mr/tez/spark: Hive as a SQL query engine：These users have all data/metadata access happening through HiveServer2. They don’t have direct access to HDFS or the metastore.
• 第一种只应用 hms 的形式下，spark 等利用会间接拜访 hdfs, 所以受权依赖于 hdfs 的 authentication 机制：HDFS access is authorized through the use of HDFS permissions.（Metadata access needs to be authorized using Hive configuration.）
• 第二种应用 hiveserver2 的形式，用户通过 hiveserver2 进而拜访 hms 和 hdfs/s3，hive 更容易对立管控用户权限，也更容易组织底层文件的 layout 和存储格局，比方反对 orc acid 事务表，从而提供高效的数据服务，是 Hive 社区冀望的形式；

以后 HIVE 共有四种 authentication 认证机制：

• Storage Based Authorization in the Metastore Server
• SQL Standards Based Authorization in HiveServer2
• Authorization using Apache Ranger & Sentry
• Old default Hive Authorization (Legacy Mode)

之所以有这么多 authentication 机制，从根本上来说，还是因为 hive 历史倒退的起因：

• 晚期的 hive 仅仅是一个简略的存储引擎之上的 SQL 解析与执行层，对底层存储引擎中的数据没有残缺的掌控力，容许内部利用如 spark/presto/flink 等，间接拜访 hms 获取元数据，并进而读写底层的数据（schema on read）；
• 后续 hive 逐步迭代，增强了对底层存储引擎中的数据的管控，包含文件的目录构造文件名称存储格局等，并进而反对了 orc acid 事务表等高效的数据存取格局，越来越像一款相似 mysql/oracle 等的数据库，举荐用户应用 hiveserver2 来拜访底层数据；
• 所以 hive 须要反对内部计算引擎间接应用 hms 与应用 hiveserver2 两种形式，须要反对 orc acid 事务表，也须要反对其它格局的各种外部表和内部表；

2.1 HIVE 受权详解 -Old default Hive Authorization (Legacy Mode)

• Hive Old Default Authorization 是 hive 2.0 之前默认的 authorization model, 反对相似 RDBMS 中对 user/group/roles 赋予 database/table 各种权限的机制：authorization based on users, groups and roles and granting them permissions to do operations on database or table
• 然而 Hive Old Default Authorization 并不是一个残缺的权限管制模型：leaving many security gaps unaddressed, for example, the permissions needed to grant privileges for a user are not defined, and any user can grant themselves access to a table or database.
• hive 2.0 之后默认的 authorization model 曾经被切换为 SQL standards based authorization mode (HIVE-12429)；

2.2 HIVE 受权详解 – Storage Based Authorization in the Metastore Server

• HMS 提供了对 hive metastore db 中的元数据的拜访，为爱护这些元数据被各种 hms 客户端如 spark/presto/flink 谬误地拜访和批改，HMS 不能齐全依赖这些客户端本身的认证和受权等平安机制，为此 Hive 0.10 通过 HIVE-3705 减少了对 HMS 的 authorization 能力，即 Storage Based Authorization；
• Storage Based Authorization 底层依赖 hdfs permissions 作为 source of truth: it uses the file system permissions for folders corresponding to the different metadata objects as the source of truth for the authorization policy.
• Storage Based Authorization 提供了客户端间接拜访 HMS 时，对底层元数据的爱护：To control metadata access on the metadata objects such as Databases, Tables and Partitions, it checks if you have permission on corresponding directories on the file system; 
• Storage Based Authorization 通过代理机制（hive.server2.enable.doAs =true），也能够提供对客户端通过 hiveserver2 拜访 HIVE 数据时，对底层元数据和数据的爱护：You can also protect access through HiveServer2 by ensuring that the queries run as the end user；
• Storage Based Authorization 能够通过 hdfs acl 提供权限的灵活性：Through the use of HDF ACL, you have a lot of flexibility in controlling access to the file system, which in turn provides more flexibility with Storage Based Authorization；

Storage based authorization 因为其本身的机制原理，在应用上也有其局限性：

• 因为 Storage based authorization 的底层原理是依赖用户对底层存储系统中数据的拜访权限，且该用户在 hiveserver2 开启代理与不开启代理机制下身份不同，所以其次要用来在用户间接拜访 hms 时，提供对底层元数据的爱护；
• 对于用户应用 hiveserver2 的状况，须要限度 HiveServer2 中能够执行的操作，此时不能单纯依附 Storage based authorization，还须要配合“SQL Standards Based Authorization”或“Authorization using Apache Ranger & Sentry，或者配置应用  FallbackHiveAuthorizer：

2.3 HIVE 受权详解 – SQL Standards Based Authorization in HiveServer2

• Storage Based Authorization 只能基于文件系统的目录 / 文件的权限管理机制提供 database/table/partition 粒度的权限管控，为提供更细粒度的权限管控，比方行级别，列级别，视图级别的权限管控，Hive 0.13.0 通过 HIVE-5837 引入了 SQL Standards Based Authorization；
• SQL Standards Based Authorization，其作用域是 HiveServer2，能够跟 / 须要跟 hms 的 storage based authorization 联合应用，以提供对 HIVE 元数据和数据的全面的平安管控；
• SQL Standards Based Authorization，会在 hiveserver2 解析编译用户的 sql query 语句时，校验提交该 sql query 语句的业务用户的权限, 然而在底层执行该 query 时，应用的是 Hive 零碎用户，所以 hive 零碎用户须要有对底层数据对应的目录 / 文件的拜访权限；
• 因为 SQL Standards Based Authorization 的作用域是 HiveServer2，所以对于间接拜访底层 hdfs 数据的用户，比方 spark on hive/Hive CLI/hadoop jar 命令等，须要依赖 hms 的 storage based authorization 来进行平安管控；
• SQL Standards Based Authorization，对 hiveserver2 中能提交的命令，做了限度；
• 启用该 authorization 机制时，Dfs/add/delete/compile/reset 等命令时被禁用的；
• 应用白名单机制，通过参数 hive.security.authorization.sqlstd.confwhitelist，限度了能够通过 set 笼罩哪些参数配置；

2.4 HIVE 受权详解 – Authorization using Apache Ranger & Sentry

• Apache Ranger 和 Apache Sentry 通过插件机制，提供了对 hive authorization 的反对，Sentry 和 Ranger 这两个框架十分相似，都是基于角色的访问控制模型（role-based access control，RBAC），基于角色的访问控制在须要对大量用户进行受权时能大大加重所需的 ACL 配置工作;
• Sentry 最后是由 Cloudera 公司外部开发而来的，初衷是为了让用户可能细粒度的管制 Hadoop 零碎中的数据（次要指 HDFS，Hive 的数据），所以 Sentry 对 HDFS，Hive 以及同样由 Cloudera 开发的 Impala 有着很好的支持性；
• 而 Ranger 最后是由另一家公司 Hortonworks（曾经被 Cloudera 收买）主导开发的，它同样是做细粒度的权限管制，但相比拟于 Sentry 而言，ranger 有着更加丰盛的策略管制，以及更加通用性的大数据组件反对，包含于 HDFS, Hive, HBase, Yarn, Storm, Knox, Kafka, Solr 和 NiFi 等在 Cloudera 公司新推出的大数据平台 cdp 中，不在提供对 sentry 的反对而是对立应用了 Ranger;
• CDH 中默认应用的是 Sentry，HDP 中默认应用的是 Ranger, 因为 sentry 我的项目曾经从 asf 中服役了，目前业界举荐的，CDP 中默认的，都是 Ranger;
• Ranger 作为集中式平台，对 Hadoop 生态中的大多数组件，包含 hdfs/hive/hbase/yarn/kafka 等，综合提供了受权，密钥治理和审计性能；
• Ranger 采纳了 ABAC 模型（Attribute based access control），基于标签策略，依据分类（标记）管制对资源的拜访；
• Ranger 提供了很多高级个性，如 web ui 直观和细粒度的策略查看和治理，全面的可扩大的审核日志记录，动静的行和列级别的访问控制，动态数据掩码可实时爱护敏感数据等。

2.5 HIVE 受权详解 - 总结

• HIVE 的权限管控机制，最罕用的是联合 Storage Based Authorization in the Metastore Server 和 SQL Standards Based Authorization in HiveServer2 或 sentry/ranger 插件；
• 其中前者基于底层文件系统的权限管理机制，提供对 hms API 的权限管控，比方查看 / 新增 / 删除表或分区等；
• 后者提供通过 hiveserver2 拜访 hive 数据时，更细粒度的权限管控，比方行级别，列级别，视图级别的权限管控；
• 当应用 spark/flink/presto on hive 计划时，利用会间接拜访 hms 和 hdfs，只有 Storage Based Authorization 起作用，次要依赖的是 hdfs 的权限管控机制（posix mode + posix acl）
• 当应用 hive on mr/tez/spark 计划时，利用通过 hiveserver2 拜访 hms 和 hdfs，Storage Based Authorization 和 sentry/range 都起作用（须要敞开代理性能 hive.server.enable.doAs=false）；
• 终端业务用户比方 xyz 提交给 HIVESERVER2 的 SQL 作业，通过 HIVESERVER2 的解析编译和优化后，个别会生成 MR/TEZ/SPARK 工作（之所以说个别，是因为有的 SQL 是间接在 HIVESERVER2 中执行的，不会生成分布式的 MR/TEZ/SPARK 工作），这些 MR/TEZ/SPARK 工作最终拜访底层的基础设施 HDFS 和 YARN 时，一样要通过这些基础设施 hdfs/yarn 的权限校验；
• 那么这些底层基础设施 hdfs/yarn 进行权限校验时，是针对 hive 零碎用户进行校验（hiveserver2 这个服务的零碎用户个别是 linux 操作系统上的用户 hive），还是针对终端业务用户比方 hundsun 进行校验呢？这点能够通过参数 hive.server2.enable.doAs 进行管制（老版本参数是 hive.server2.enable.impersonation）：hive.server2.enable.doAs=false/TRUE:“Setting this property to true will have HiveServer2 execute Hive operations as the user making the calls to it.”；
• 当启用了 HIVE 的代理机制时（hive.server.enable.doAs=true），业务终端用户如 xyz 提交的 HIVE SQL 作业底层的 MR/TEZ/SPARK 工作拜访 HDFS/YARN 时，HDFS/YARN 验证的是业务终端用户 xyz 的身份 (后续 HDFS/YARN 的权限校验，校验的也是 xyz 用户的权限)；
• 当没有启用 HIVE 的代理机制时（hive.server.enable.doAs=false），业务终端用户提交的 HIVE SQL 作业底层的 MR/TEZ/SPARK 工作拜访 HDFS/YARN 时，须要验证的是 hiveserver2 服务对应的用户，即 hive 的身份 (后续 HDFS/YARN 的权限校验，校验的也是 hive 用户的权限)；

2.6 HIVE 受权详解 - 相干参数

HIVE 受权相干参数次要有：

• hive.security.authorization.enabled: Enable or disable the Hive client authorization
• hive.security.authorization.manager：org.apache.hadoop.hive.ql.security.authorization.plugin.fallback.FallbackHiveAuthorizerFactory/org.apache.hadoop.hive.ql.security.authorization.StorageBasedAuthorizationProvider/org.apache.hadoop.hive.ql.security.authorization.DefaultHiveMetastoreAuthorizationProvider/org.apache.sentry.binding.hive.authz.SentryHiveAuthorizerFactory;
• hive.metastore.pre.event.listeners: The pre-event listener classes to be loaded on the metastore side to run code whenever databases, tables, and partitions are created, altered, or dropped. Set this configuration property to org.apache.hadoop.hive.ql.security.authorization.AuthorizationPreEventListener in hive-site.xml to turn on Hive metastore-side security；
• hive.security.metastore.authorization.manager: This tells Hive which metastore-side authorization provider to use. Defaults to org.apache.hadoop.hive.ql.security.authorization.StorageBasedAuthorizationProvider .
• hive.security.metastore.authenticator.manager:The authenticator manager class name to be used in the metastore for authentication, defaults to org.apache.hadoop.hive.ql.security.HadoopDefaultMetastoreAuthenticator
• hive.security.authorization.createtable.owner.grants
• hive.security.authorization.sqlstd.confwhitelist
• hive.warehouse.subdir.inherit.perms
• hive.server2.enable.doAs/hive.server2.enable.impersnation

3. 金融行业大数据安全最佳实际

• 在金融行业强调平安的背景下，咱们举荐对大数据集群开启 kerberos 平安认证, 开启用户权限校验：hadoop.security.authentication=kerberos，dfs.permissions.enabled=true
• HDFS 文件的受权，要遵循最小化准则，不能对目标目录抽象设置 777！
• HDFS 文件的受权，倡议次要应用 POSIX MODE 来进行设置，必要时通过 POSIX ACL 进行补充：dfs.namenode.acls.enabled=true
• 业务用户对 HDFS 文件的应用，倡议将所有文件，比方 jar/ 配置文件 / 数据字典等，寄存在对立的目录下，比方 /user/hundsun/dap
• 针对 HIVE 的认证，咱们举荐两种形式：只开启 Kerberos 认证模式 / 开启 Kerberos 认证和 LDAP 认证模式，其中后者的理论含意是“大数据集群（hdfs/yarn/zookeeper/hive 等）开启了 kerberos 平安认证，同时 hive 组件 配置了应用 LDAP 认证”；
• 具体的 LDAP，如果要跟企业域账户买通，则须要应用企业外部对立的 LDAP 服务器；否则倡议应用一个独自的 ldap 服务器（比方 OpenLdap/ApacheDS/microsoft AD 等 ldap 的某个具体实现），比方在 TDH 中，底层理论应用的是 Guardien 底层自带的一个 ldap 实现（实质是 ApacheDS），创立用户更改明码等操作都是在 Guardien 中操作的，更企业域账户是独立的；
• 针对 HIVE 的受权，咱们举荐应用 sentry/ranger 等第三方插件对立进行受权和鉴权，此时须要敞开 hive 的代理性能 Hive.server2.enableDoas=false；
• 咱们举荐各个业务零碎应用该零碎对应的业务用户的身份提交业务 SQL，而不是各个业务零碎对立都应用 HIVE 零碎用户；
• 业务用户对 HIVE 表的应用，如果都是通过 HIVESERVER2 来拜访，倡议应用 ORC 事务内表；如果通过 SPARK 等计算引擎做 ETL，倡议应用 orc/parquet 格局的 HIVE 表面，并存放在对立的目录下，比方 /user/hundsun/dap，针对表面目录的受权，须要联合 HDFS POSIX ACL 来进行;