轉載請注明出處:http://www.cnblogs.com/xiaodf/
4. 為CDH 5集群添加Kerberos身份驗證
4.1 安裝sentry
1、點擊“操作”,“添加服務”;
2、選擇sentry,並“繼續”;
3、選擇一組依賴關系
4、確認新服務的主機分配
5、配置存儲數據庫;
在mysql中創建對應用戶和數據庫:
mysql>create database sentry default character set utf8 collate utf8_general_ci; mysql>grant all on sentry.* to 'admin'@'server35' identified by '111111'; mysql>flush privileges;
6、測試連接
7、創建Sentry數據表,啟動Sentry服務
4.2 詳細部署過程
4.2.1 安裝Cloudera Manager和CDH
如果您尚未執行此操作,Cloudera 強烈建議您首先安裝和配置 Cloudera Manager Server 和 Cloudera Manager Agent 以及 CDH 來設置一個功能完備的 CDH 群集,然后再開始執行以下步驟來實施 Hadoop 安全功能。
4.2.2 如果您使用的是 AES-256 加密,請安裝 JCE 策略文件(推薦不使用AES-256加密)
如果您使用的是 CentOS 或 RHEL 5.5 或更高版本(默認情況下對票證使用 AES-256 加密),您必須在所有群集和 Hadoop 用戶主機上安裝 Java Cryptography Extension (JCE) 無限制強度權限策略文件。可通過兩種方法執行此操作:
1、 在 Cloudera Manager Admin Console 中,導航到主機頁面。向群集添加新主機向導和重新運行升級向導都使您能夠選擇讓 Cloudera Manager 為您安裝 JCE 策略文件。
2、 您可以按照 jce_policy-x.zip 文件中包含的 README.txt 文件中的 JCE 策略文件安裝說明進行操作。
注意:您可以通過從 kdc.conf 或 krb5.conf 文件的 supported_enctypes 字段中刪除 aes256-cts:normal 來將 Kerberos 配置為不使用 AES-256。請注意,在更改 kdc.conf 文件之后,您需要重啟 KDC 和 kadmin 服務器,這些更改才會生效。您可能還需要重新創建或更改相關主體的密碼,可能包括 Ticket Granting Ticket 主體(例如,krbtgt/EXAMPLE.COM@EXAMPLE.COM)。如果在執行所有這些步驟之后仍在使用 AES- 256,這是因為在創建 Kerberos 數據庫時存在 aes256-cts:normal 設置。要解決此問題,請創建新的 Kerberos 數據庫,然后重啟 KDC 和 kadmin 服務器。
4.2.3 為 Cloudera Manager Server 獲取或創建 Kerberos 主體
為了能在集群中創建和部署host principals和keytabs,Cloudera Manager Server必須有一個Kerberos principal來創建其他的賬戶。如果一個principal的名字的第二部分是admin(例如, username/admin@YOUR-LOCAL-REALM.COM ),那么該principal就擁有administrative privileges。
在KDC server主機上,創建一個名為[cloudra-scm]的principal,並為其設置密碼。執行命令:
[root@vmw201 ~]# kadmin.local Authenticating as principal root/admin@HADOOP.COM with password. Kadmin.local: addprinc -pw cloudera-scm-1234 cloudera-scm/admin@HADOOP.COM WARNING: no policy specified for cloudera-scm/admin@HADOOP.COM; defaulting to no policy Principal "cloudera-scm/admin@HADOOP.COM" created.
輸入listprincs可以看到創建了一個名為cloudera-scm/admin@HADOOP.COM的principal:
4.2.4 導入KDC Account Manager憑據
1、在 Cloudera Manager Admin Console 中,選擇管理 > 安全 > Kerberos憑據。
2、導航到憑據選項卡並單擊導入 Kerberos Account Manager 憑據。
3、在導入 Kerberos Account Manager 憑據對話框中,針對可以在 KDC 中為 CDH 群集創建主體的用戶輸入用戶名和密碼。這是您在4.1.3中:為 Cloudera Manager Server 獲取或創建 Kerberos 主體 中創建的用戶/主體。Cloudera Manager 會將用戶名和密碼加密到 Keytab 中,並在需要時使用它來創建新的主體。
4.2.5 在cloudera Manager Admin Console中配置Kerberos默認領域
1、在 Cloudera Manager Admin Console 中,選擇管理 > 設置。
2、單擊Kerberos類別,然后在 Kerberos 安全領域字段中為群集輸入您在 krb5.conf 文件中配置的 Kerberos 領域(例如 EXAMPLE.COM 或 HADOOP.EXAMPLE.COM)、KDC Server主機、Kerberos加密類型。
3、 單擊保存更改。
4.2.6 停止所有服務
1、在主頁上,單機集群名稱右側的 ,停止所有服務。
2、在主頁上,單擊 Cloudera Management Service 右側的 ,選擇停止。
4.2.7 啟用 HDFS安全性
1、點擊主頁上的HDFS,選擇配置
2、修改下面參數
hadoop.security.authentication ---> kerberos hadoop.security.authorization ---> true dfs.datanode.data.dir.perm ---> 700 dfs.datanode.address --->1004 dfs.datanode.http.address --->1006 Hadoop.security.group.mapping->org.apache.hadoop.security.ShellBasedUnixGroupsMapping
3、單擊保存更改
4.2.8 啟用HBASE安全性
1、點擊主頁上的HBASE,選擇配置
2、修改下面參數
hbase.security.authentication ---> Kerberos hbase.security.authorization ---> true
3、 單擊保存
4.2.9 啟用kafka安全性
1、單擊主頁上的kafka,選擇配置。
2、修改下面參數
kerberos.auth.enable ---> true security.inter.broker.protocol ---> SASL_PLAINTEXT
3、單擊保存
4.2.10 啟用zookeeper安全性
1、單擊主頁上的zookeeper,選擇配置。
2、修改下面參數
enableSecurity ---> true
3、單擊保存
4.2.11 Hive開啟sentry服務以及開啟Hive安全性
1、在“Sentry 服務”中選擇“Sentry”
2、修改下面參數
Hive.warehouse.subdir.inherit.perms-->true
3、選擇hive-site.xml 的 Hive 服務高級配置代碼段(安全閥),增加如下配置:
<property> <name>sentry.hive.testing.mode</name> <value>false</value> </property>
4、選擇“范圍”中的“HiveServer2”,修改如下配置:
hive.server2.enable.impersonation, hive.server2.enable.doAs-->false
5、選擇hive-site.xml 的 HiveServer2 高級配置代碼段(安全閥),添加如下配置
<property> <name>hive.security.authorization.task.factory</name> <value>org.apache.sentry.binding.hive.SentryHiveAuthorizationTaskFactoryImpl</value> </property>
6、選擇hive-site.xml 的 Hive Metastore Server 高級配置代碼段(安全閥),添加如下參數:
<property> <name>hive.metastore.client.impl</name> <value>org.apache.sentry.binding.metastore.SentryHiveMetaStoreClient</value> <description>Sets custom Hive Metastore client which Sentry uses to filter out metadata.</description> </property> <property> <name>hive.metastore.pre.event.listeners</name> <value>org.apache.sentry.binding.metastore.MetastoreAuthzBinding</value> <description>list of comma separated listeners for metastore events.</description> </property> <property> <name>hive.metastore.event.listeners</name> <value>org.apache.sentry.binding.metastore.SentryMetastorePostEventListener</value> <description>list of comma separated listeners for metastore, post events.</description> </property> <property> <name>hive.metastore.filter.hook</name> <value>org.apache.sentry.binding.metastore.SentryMetaStoreFilterHook</value> </property>
4.2.12 配置yarn
在“允許的系統用戶”參數“allowed.system.users”中添加hive用戶
Yarn->配置->min.user.id修改為合適的值,當前為0
4.2.13 配置sentry
管理員組(sentry.service.admin.group)和允許的連接用戶(sentry.service.allow.connect)中添加admin用戶和組;
選擇“服務范圍”,修改管理員組,將默認“hive”、“impala”、“hue”刪除,並增加“admin”。
在sentry-site.xml 的 Sentry 服務高級配置代碼段(安全閥)中添加如下參數:
<property> <name>sentry.service.processor.factories</name> <value>org.apache.sentry.provider.db.service.thrift.SentryPolicyStoreProcessorFactory,org.apache.sentry.hdfs.SentryHDFSServiceProcessorFactory</value> </property> <property> <name>sentry.policy.store.plugins</name> <value>org.apache.sentry.hdfs.SentryPlugin</value> </property> <property> <name>sentry.hdfs.integration.path.prefixes</name> <value>/user/hive/warehouse</value> </property>
4.2.14 等待“生成憑據”命令完成
在 Cloudera Manager 中為任何服務啟用安全保護之后,將自動觸發稱為“生成憑據”的命令。您可以在顯示正在運行的命令的屏幕右上角看到該命令的進度。請等待此命令完成(通過內含“0”的灰色框表示)。
4.2.15 使 Hue 能夠使用 Cloudera Manager 與 Hadoop 安全一起工作
如果您使用的是 Hue 服務,那么您必須向 Hue 服務添加 Kerberos Ticket Renewer 的角色實例,以使 Hue 能夠使用 Cloudera Manager 與安全的 Hadoop 群集一起正常工作。
Hue Kerberos Ticket Renewer 僅為主體 hue/<hostname>@HADOOP.COM續訂 Hue 服務的票證。然后,將使用該 Hue 主體為 Hue 內的應用程序(如 Job Browser、File Browser 等)模擬其他用戶。其他服務(如 HDFS 和 MapReduce)不使用 Hue Kerberos Ticket Renewer。它們將在啟動時獲取票證,並使用這些票證獲取各種訪問權限的委派令牌。每個服務根據需要處理自己的票證續訂。
1. 轉到Hue服務。
2. 單擊實例選項卡。
3. 單擊添加角色實例按鈕。
4. 為與Hue Server相同的主機分配Kerberos Ticket Renewer序角色實例。
5. 在向導完成后,狀態將顯示已完成,並且 Kerberos Ticket Renewer 角色實例已配置。Hue 服務現在將與安全的 Hadoop 群集一起工作。
4.2.16啟動所有服務
啟動所有服務,在主頁上,單擊群集名稱右側的 並選擇啟動。
啟動 Cloudera Management Service,在主頁上,單擊Cloudera Management Service右側的 並選擇啟動。
4.2.17 部署客戶端配置
在主頁,單擊群集名稱右側的 ,並選擇部署客戶端配置。
4.2.18 創建 HDFS 超級用戶主體
要為用戶創建主目錄,您需要對超級用戶帳戶具有訪問權限。在 HDFS 中,運行 NameNode 進程的用戶帳戶(默認情況下為 hdfds)是一個超級用戶。在安裝 CDH 的過程中,CDH 會自動在每個群集主機上創建 hdfs 超級用戶帳戶。當為 HDFS 服務啟用 Kerberos 時,您無法通過 sudo -u hdfs 命令訪問 hdfs 超級用戶帳戶。要在 Kerberos 處於啟用狀態時能夠訪問 hdfs 超級用戶帳戶,您必須創建一個 Kerberos 主體或 AD 用戶,並且其第一個或唯一一個組成部分必須是 hdfs。或者,您也可以指定其成員屬於超級用戶的超級用戶組。
在kadmin.local或kadmin shell 中,鍵入以下命令來創建名為hdfs的Kerberos主體:
kadmin: addprinc hdfs@HADOOP.COM
此命令會提示您為 hdfs 主體創建密碼。請使用強密碼,因為此主體對 HDFS 中的所有文件提供超級用戶訪問權限。
要作為 hdfs 超級用戶運行命令,您必須為 hdfs 主體獲取 Kerberos 憑據。要執行此操作,請運行以下命令並提供密碼:
$ kinit hdfs@HADOOP.COM
指定超級用戶組
要指定超級用戶組而不使用默認 hdfs 帳戶,請按照以下步驟進行操作:
1.導航到HDFS服務 > 配置選項卡。
2.在“搜索”字段中鍵入超級用戶以顯示超級用戶組屬性。
3.將默認supergroup的值更改為適合您的環境的組名稱。
4.單擊保存更改。
為使此更改生效,您必須重啟群集。
4.2.19 為每個用戶帳戶獲取或創建 Kerberos 主體
在您的群集上配置和啟用 Kerberos 之后,您和其他所有 Hadoop 用戶都必須具有 Kerberos 主體或 Keytab 才能獲取被允許訪問該群集和使用 Hadoop 服務的 Kerberos 憑據。在此過程的下一步中,您需要創建自己的 Kerberos 主體,以便驗證 Kerberos 安全是否正在您的群集上工作。如果您和其他 Hadoop 用戶已經有 Kerberos 主體或 Keytab,或者您的 Kerberos 管理員可以提供它們,那么您可以直接跳到下一步。
在 kadmin.local 或 kadmin shell 中,使用以下命令為您的帳戶創建主體,請將 username 替換為用戶名:
kadmin: addprinc username@HADOOP.COM
4.2.20為每個用戶准備群集
在您和其他用戶可以訪問群集之前,您必須執行一些任務來為每個用戶准備主機。
1. 確保群集中的所有主機都有一個linux用戶帳戶並且該帳戶的名稱與用戶的主體名稱的第一個組成部分相同。例如,如果用戶的主體名稱是 joe@HADOOP.COM,則每個框中應存在linux帳戶joe。
2. 為每個用戶帳戶在 HDFS 上的 /user 下創建一個子目錄(例如 /user/joe)。將該目錄的所有者和組更改為該用戶。
$ hadoop fs -mkdir /user/joe $ hadoop fs -chown joe /user/joe
4.2.21為 Hadoop 角色的 HTTP Web Console 啟用身份驗證(可選)
HDFS、MapReduce 和 YARN 角色的 Web Console 的訪問身份驗證可通過相應的服務的配置選項啟用。要啟用此身份驗證,請執行以下操作:
1.從群集選項卡中,選擇要為其啟用身份驗證的服務(HDFS、MapReduce 或 YARN)。
2.單擊配置選項卡。
3.展開服務范圍 > 安全,選中啟用 HTTP Web Console 的身份驗證屬性,然后保存您所做的更改。
將觸發一個命令來生成新的所需憑據。
4. 在命令完成后,請重啟該服務的所有角色。
4.2.22 確認Kerberos在集群上正常工作
登錄到某一個節點后,切換到hdfs用戶,然后用kinit來獲取credentials
現在用’hadoop dfs -ls /’應該能正常輸出結果
用kdestroy銷毀credentials后,再使用hadoop dfs -ls /會發現報錯
4.3 kafka使用SASL驗證
kafka目前支持的機制有GSSAPI(Kerberos)和PLAIN ,在以上步驟中,Kafka brokers的SASL已配置,接下來配置Kafka客戶端
4.3.1 生成jaas文件
客戶端(生產者,消費者,connect,等等)用自己的principal認證集群(通常用相同名稱作為運行客戶端的用戶)。因此,獲取或根據需要創建這些principal。然后,為每個principal創建一個JAAS文件,KafkaClient描述了生產者和消費者客戶端如何連接到broker。下面是一個客戶端使用keytab的配置例子(建議長時間運行的進程)。在/etc/kafka/目錄下創建kafka_client_jaas.conf文件
KafkaClient { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true storeKey=true keyTab="/etc/kafka/conf/kafka_client.keytab" principal="kafka-client-1@HADOOP.COM"; };
創建kafka-client-1@HADOOP.COM
kadmin:addprinc -randkey kafka-client-1 kadmin:xst -k /etc/kafka/conf/kafka_client.keytab kafka-client-1
在使用producer和consumer java接口時,要在代碼main方法中,加入
System.setProperty(“java.security.auth.login.config”,”/etc/kafka/kafka_client_jaas.conf”);
保證程序可以讀取到jaas文件。
在producer和consumer的config里加入
props.put("sasl.kerberos.service.name", "kafka"); props.put("sasl.mechanism", " GSSAPI"); props.put("security.protocol", "SASL_PLAINTEXT");
對於java程序配置到以上步驟就可以了,以下步驟可以跳過。
對於命令行工具,比如kafka-console-consumer 或 kafka-console-producer,kinit連同 “useTicketCache=true”使用,如:
KafkaClient { com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true; };
4.3.2 通過JAAS作為JVM參數(每個客戶端的JVM)
在/opt/cloudera/parcels/KAFKA/lib/kafka/bin/kafka-run-class.sh文件中JVM performance options參數的KAFKA_JVM_PERFORMANCE_OPTS中加入
-Djava.security.auth.login.config=/etc/kafka/kafka_client_jaas.conf
4.3.3 生成producer.properties和consumer.properties文件
在/etc/kafka/conf/目錄下生成producer.properties和consumer.properties
security.protocol=SASL_PLAINTEXT (or SASL_SSL) sasl.mechanism=GSSAPI sasl.kerberos.service.name=kafka
4.3.4 使用命令行工具進行生產消費
本文檔中使用到的kafka parcel版本為2.0.2-1.2.0.2.p0.5,部署kerberos后,要使用新生產者:
kafka-console-producer --broker-list 172.16.18.201:9092 –topic test --producer.config config/producer.properties
新消費者:
kafka-console-consumer --bootstrap-server 172.16.18.201:9092 --topic test --new-consumer --from-beginning --consumer.config config/consumer.properties
5. HDFS權限控制
5.1HDFS啟用 ACL
默認情況下,ACL 在集群上被禁用。要啟用,將 dfs.namenode.acls.enabled 屬性設為 true(在 NameNode 的 hdfs-site.xml 中)。
dfs.namenode.acls.enabled-->TRUE
5.2使用 Cloudera Manager 啟用 HDFS-Sentry 插件
1. 在服務范圍類別下,轉到安全。
2. 選中啟用 Sentry 同步復選框。
3 .使用 Sentry 同步路徑前綴屬性列出應強制實施 Sentry 權限前綴的 HDFS 路徑。可以指定多個 HDFS 路徑前綴。默認情況下,該屬性指向 user/hive/warehouse 並且必須始終為非空。此處列出的 HDFS 地區以外的表就不會出現 HDFS 權限同步。
4. 單擊保存更改。
5. 重新啟動群集。請注意,在群集重新啟動后,可能還需要兩分鍾讓權限同步生效。
5.3測試 Sentry 同步插件
直接在 HDFS 中訪問表文件。例如:
列出文件夾中的文件,並驗證在 HDFS(包括 ACL)中顯示的文件權限是否與 Sentry 中配置的相匹配。
運行科訪問這些文件的 MapReduce、Pig 或 Spark 作業。選擇除 HiveServer2 和 Impala 以外的任何工具。
6. Kafka權限控制
6.1啟動kafka acl
6.1.1在cm主頁中點擊kafka,點擊配置 > 高級
6.1.2 配置kakfa.properties的kafka Broker高級配置代碼段(安全閥)
authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer super.users=User:kafka;
User:kafka默認對應principal:kafka@HADOOP.COM(超級賬戶,具有為其他賬戶賦予權限的權利)
6.2 命令行界面
6.2.1 kafka-acl支持選項
Kafka認證管理CLI(和其他所有的CLI)可以在bin目錄中找到。CLI腳本名是kafka-acls.sh。以下列出了所有腳本支持的選項:
選項 描述 默認 類型選擇 --add 添加一個acl Action --remove 移除一個acl Action --list 列出acl Action --authorizer Authorizer的完全限定類名 Kafka.security.auth. SimpleAclAuthorizer Configuration --authorizer -properties Key=val,傳給authorizer進行初始化,例如:zookeeper.connect=localhost:2181 Configuration --cluster 指定集群作為資源。 Resource --topic [topic name] 指定topic作為資源 Resource --group [group-name] 指定consumer-group作為資源 Resource --allow -principal 添加到允許訪問的ACL中,Principal是Principal Type:name格式,可以指定多個 Principal --deny -principal 添加到拒絕訪問的ACL中,Principal是Principal Type:name格式,可以指定多個 Principal --allow-host --allow-principal中的princiapl的IP的地址被訪問。 如果--allow-principal指定的默認值是*,則意味着指定“所有主機” Host --deny-host --deny-principal中的princiapl的IP的地址被訪問。 如果--allow-principal指定的默認值是*,則意味着指定“所有主機” Host --produce 為producer角色添加/刪除acl。生成acl,允許在topic上WRITE, DESCRIBE和CREATE集群。 Convenience --consumer 為consumer角色添加/刪除acl。生成acl,允許在topic上READ, DESCRIBE和consumer-group上READ。 Convenience
6.2.2 添加acl
假設你要添加一個acl “允許198.51.100.0和User:Alice對主題是Test-Topic有Read和Write的執行權限” 。通過執行下列選項
kafka-acls --authorizer-properties zookeeper.connect=172.16.18.201:2181/kafka --add --allow-principal User:Alice --allow-host 172.16.18.202 ---operation Read --operation Write --topic Test-topic
默認情況下,所有的principal在沒有一個明確的對資源操作訪問的acl都是拒絕訪問的。在極少的情況下,定義了acl允許訪問所有,但一些principal我們將必須使用 --deny-principal 和 --deny-host選項。例如,如果我們想讓所有用戶讀取Test-topic,只拒絕IP為198.51.100.3的User:BadBob,我們可以使用下面的命令:
kafka-acls --authorizer-properties zookeeper.connect=172.16.18.201:2181/kafka --add --allow-principal User:* --allow-host * --deny-principal User:BadBob --deny-host 198.51.100.3 --operation Read --topic Test-topic
需要注意的是--allow-host和deny-host僅支持IP地址(主機名不支持)。上面的例子中通過指定--topic [topic-name]作為資源選項添加ACL到一個topic。同樣,用戶通過指定--cluster和通過指定--group [group-name]消費者組添加ACL。
6.2.3 刪除acl
刪除和添加是一樣的,--add換成--remove選項,要刪除第一個例子中添加的,可以使用下面的命令:
kafka-acls --authorizer-properties zookeeper.connect=172.16.18.201:2181/kafka --remove --allow-principal User:Alice --allow-host 172.16.18.202 --operation Read --operation Write --topic Test-topic
6.2.4 acl列表
我們可以通過指定與資源--list選項列出任何資源的ACL,alc列表存儲在zookeeper中。要列出Test-topic,我們可以用下面的選項執行CLI所有的ACL:
kafka-acls --authorizer-properties zookeeper.connect=172.16.18.201:2181/kafka --list --topic Test-topic
6.2.5 添加或刪除作為生產者或消費者的principal
acl管理添加/移除一個生產者或消費者principal是最常見的使用情況,所以我們增加更便利的選項處理這些情況。為主題Test-topic添加一個生產者User:Alice,我們可以執行以下命令的生產:
kafka-acls --authorizer-properties zookeeper.connect=172.16.18.201:2181/kafka --add --allow-principal User:Alice --producer --topic Test-topic
同樣,添加Alice作為主題Test-topic的消費者,用消費者組為Group-1,我們只用 --consumer 選項:
kafka-acls --authorizer-properties zookeeper.connect=172.16.18.201:2181/kafka --add --allow-principal User:Bob --consumer --topic test-topic --group Group-1
注意,消費者的選擇,我們還必須指定消費者組。從生產者或消費者角色刪除主體,我們只需要通過--remove選項。