# 安全地運行 Apache Storm ## 安全地運行 Apache Storm 嘗試保護集群時, Apache Storm 提供了一系列配置選項. 默認情況下, 所有驗證和授權都被禁用, 但可以根據需要打開. ## 防火墻/操作系統 級別安全 您仍然可以擁有安全的 storm 集群, 而無需開啟正式的身份驗證和授權. 但是這樣做通常需要配置您的操作系統來限制可以完成的操作. 即使您計劃使用 Auth 運行群集, 通常也是一個好主意. 如何設置這些預防措施的具體細節有很大的不同, 超出了本文檔的范圍. 通常情況下, 啟用防火墻并限制傳入網絡連接僅限于源自群集本身和來自可信主機和服務的網絡連接, 一個完整的端口 storm 使用列表如下. 如果您的群集正在處理的數據是敏感的, 則可能最好設置 IPsec 來加密群集中主機之間發送的所有流量. ### Ports | 默認端口 | Storm 配置 | Client Hosts/進程 | Server | | --- | --- | --- | --- | | 2181 | `storm.zookeeper.port` | Nimbus, Supervisors, and Worker 進程 | Zookeeper | | 6627 | `nimbus.thrift.port` | Storm clients, Supervisors, and UI | Nimbus | | 8080 | `ui.port` | Client Web 瀏覽器 | UI | | 8000 | `logviewer.port` | Client Web 瀏覽器 | Logviewer | | 3772 | `drpc.port` | 外部 DRPC Clients | DRPC | | 3773 | `drpc.invocations.port` | Worker 進程 | DRPC | | 3774 | `drpc.http.port` | 外部 HTTP DRPC Clients | DRPC | | 670{0,1,2,3} | `supervisor.slots.ports` | Worker 進程 | Worker 進程 | ### UI / Logviewer UI 和 logviewer 進程提供了一種方法, 不僅可以看到集群正在做什么, 還可以操縱運行的 topology.通常, 這些進程不應該被暴露, 除了群集的用戶. 通常使用某種形式的身份驗證, 使用 java servlet 過濾器. ``` ui.filter: "filter.class" ui.filter.params: "param1":"value1" ``` 或通過限制 UI / Logviewer 端口僅接受來自本地主機的連接, 然后使用另一個可以驗證/授權傳入連接并代理與 storm 進程的連接的 Web 服務器（如: Apache httpd）將其連接起來. 為了使此工作, ui 進程必須將 logviewer.port 設置為其 storm.yaml 中的代理端口, 而日志查看器必須將其設置為要綁定到的實際端口. servlet 過濾器是首選, 因為它允許單獨的 topology 來詳細說明誰是誰, 誰不被允許訪問與它們相關聯的頁面. Storm UI 可以配置為使用 hadoop-auth 中的 AuthenticationFilter. ``` ui.filter: "org.apache.hadoop.security.authentication.server.AuthenticationFilter" ui.filter.params: "type": "kerberos" "kerberos.principal": "HTTP/nimbus.witzend.com" "kerberos.keytab": "/vagrant/keytabs/http.keytab" "kerberos.name.rules": "RULE:[2:$1@$0]([jt]t@.*EXAMPLE.COM)s/.*/$MAPRED_USER/ RULE:[2:$1@$0]([nd]n@.*EXAMPLE.COM)s/.*/$HDFS_USER/DEFAULT" ``` 確保創建一個主體 'HTTP/{hostname}'（這里的 hostname 應該是運行 UI 守護進程的主機名) 一旦配置用戶需要在訪問 UI 之前執行 kinit. 例如： `curl -i --negotiate -u:anyUser -b ~/cookiejar.txt -c ~/cookiejar.txt http://storm-ui-hostname:8080/api/v1/cluster/summary` 1. Firefox: 轉到 配置并搜索 network.negotiate-auth.trusted-uris 雙擊以添加值 "[http://storm-ui-hostname:8080](http://storm-ui-hostname:8080)" 2. Google-chrome: 從命令行開始 google-chrome --auth-server-whitelist="*storm-ui-hostname" --auth-negotiate-delegate-whitelist="*storm-ui-hostname" 3. IE: 配置受信任的網站以包含 "storm-ui-hostname" 并允許該網站的協商 **注意**: 為了通過 `logviewer` 安全模式查看任何日志, 運行的所有主機 `logviewer` 也應該添加到上述白名單中.對于大集群, 您可以列出主機的域（例如: 設置 `network.negotiate-auth.trusted-uris` 為 `.yourdomain.com`）. **警告**: 在 AD MIT Keberos 設置中, 密鑰大小大于默認的 UI jetty 服務器請求頭大小. 確保在 storm.yaml 中將 ui.header.buffer.bytes 設置為 65536 . 更多詳細信息, 請參見 [STORM-633](https://issues.apache.org/jira/browse/STORM-633) ## UI / DRPC SSL UI 和 DRPC 都允許用戶配置 ssl. ### UI 對于 UI 用戶需要在 storm.yaml 中設置以下配置. 在此步驟之前, 用戶必須注意使用合適的密鑰和證書生成密鑰庫. 1. ui.https.port 2. ui.https.keystore.type（示例: "jks"） 3. ui.https.keystore.path（示例: "/etc/ssl/storm_keystore.jks"） 4. ui.https.keystore.password（密鑰庫密碼） 5. ui.https.key.password（私鑰密碼） 可選配置 1. ui.https.truststore.path（示例: "/etc/ssl/storm_truststore.jks"） 2. ui.https.truststore.password（信任密碼） 3. ui.https.truststore.type（示例: "jks"） 如果用戶想要設置雙向認證 1. ui.https.want.client.auth（如果這設置為客戶端認證身份驗證的真實服務器請求, 但如果沒有提供身份驗證, 則保持連接） 2. ui.https.need.client.auth（如果設置為 true 服務器需要客戶端提供身份驗證） ### DRPC 與 UI 類似, 用戶需要為 DRPC 配置以下內容 1. drpc.https.port 2. drpc.https.keystore.type（示例: "jks"） 3. drpc.https.keystore.path（示例: "/etc/ssl/storm_keystore.jks"） 4. drpc.https.keystore.password（密鑰庫密碼） 5. drpc.https.key.password（私鑰密碼） 可選配置 1. drpc.https.truststore.path（示例: "/etc/ssl/storm_truststore.jks"） 2. drpc.https.truststore.password（信任密碼） 3. drpc.https.truststore.type（示例: "jks"） 如果用戶想要設置雙向認證 1. drpc.https.want.client.auth（如果這設置為客戶端證書認證的真實服務器請求, 但如果沒有提供認證, 則保持連接） 2. drpc.https.need.client.auth（如果設置為 true 服務器需要客戶端提供身份驗證） ## 認證 (Kerberos) Storm 通過 thrift 和 SASL 提供可插拔的身份驗證支持. 此示例僅適用于 Kerberos , 因為它是大多數大型數據項目的常見設置. 在每個節點上設置 KDC 并配置 kerberos 超出了本文檔的范圍, 并假設您已經完成了. ### 創建 Headless Principals and keytabs 每個 Zookeeper 服務器, Nimbus 和 DRPC 服務器將需要一個服務的 principal, 按照慣例, 它將包含將運行的主機的 FQDN. 請注意, zookeeper 用戶必須是 zookeeper. supervisor 和 UI 還需要一個 principal 來運行, 但由于它們是外向連接, 所以他們不需要是服務的 principal. 以下是如何設置 kerberos principal 的示例, 但細節可能會因您的 KDC 和操作系統而異. ``` # Zookeeper (Will need one of these for each box in teh Zk ensamble) sudo kadmin.local -q 'addprinc zookeeper/zk1.example.com@STORM.EXAMPLE.COM' sudo kadmin.local -q "ktadd -k /tmp/zk.keytab zookeeper/zk1.example.com@STORM.EXAMPLE.COM" # Nimbus and DRPC sudo kadmin.local -q 'addprinc storm/storm.example.com@STORM.EXAMPLE.COM' sudo kadmin.local -q "ktadd -k /tmp/storm.keytab storm/storm.example.com@STORM.EXAMPLE.COM" # All UI logviewer and Supervisors sudo kadmin.local -q 'addprinc storm@STORM.EXAMPLE.COM' sudo kadmin.local -q "ktadd -k /tmp/storm.keytab storm@STORM.EXAMPLE.COM" ``` 確保將keytab分發到相應的框, 并設置 FS 權限, 以便只有運行 ZK 或 storm 的 headless 用戶才能訪問它們. #### Storm Kerberos 配置 Storm 和 Zookeeper 都使用 jaas 配置文件來記錄用戶. 每個 jaas 文件可能會有不同的界面被使用. 要在 storm 中啟用 Kerberos 身份驗證, 您需要設置以下 storm.yaml 配置: ``` storm.thrift.transport: "org.apache.storm.security.auth.kerberos.KerberosSaslTransportPlugin" java.security.auth.login.config: "/path/to/jaas.conf" ``` Nimbus 和 supervisor 進程也將連接到 ZooKeeper(ZK), 我們希望將其配置為使用 Kerberos 進行身份驗證. 做這個附加: ``` -Djava.security.auth.login.config=/path/to/jaas.conf ``` 對 nimbus , ui 和 supervisor 的 childopts.給出了寫入時, 默認的 childopts 設置的一個例子： ``` nimbus.childopts: "-Xmx1024m -Djava.security.auth.login.config=/path/to/jaas.conf" ui.childopts: "-Xmx768m -Djava.security.auth.login.config=/path/to/jaas.conf" supervisor.childopts: "-Xmx256m -Djava.security.auth.login.config=/path/to/jaas.conf" ``` 對于 storm 節點, jaas.conf 文件應如下所示. StormServer 部分由 nimbus 和 DRPC 節點使用.它不需要包括在主管節點上. StormClient 部分被所有想要與 nimbus 通訊的 storm client 使用, 包括 ui, logviewer 和 supervisor. 我們將在網關上使用這一部分, 但其結構將會有所不同. Client 部分被想要與 zookeeper 通訊的進程使用, 并且只需要包含在 nimbus 和 supervisor 中. 服務器部分由 zookeeper 服務器使用. 在 jaas 中沒有使用的部分不是問題. ``` StormServer { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="$keytab" storeKey=true useTicketCache=false principal="$principal"; }; StormClient { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="$keytab" storeKey=true useTicketCache=false serviceName="$nimbus_user" principal="$principal"; }; Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="$keytab" storeKey=true useTicketCache=false serviceName="zookeeper" principal="$principal"; }; Server { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="$keytab" storeKey=true useTicketCache=false principal="$principal"; }; ``` 以下是基于 keytab 生成的示例: ``` StormServer { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/keytabs/storm.keytab" storeKey=true useTicketCache=false principal="storm/storm.example.com@STORM.EXAMPLE.COM"; }; StormClient { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/keytabs/storm.keytab" storeKey=true useTicketCache=false serviceName="storm" principal="storm@STORM.EXAMPLE.COM"; }; Client { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/keytabs/storm.keytab" storeKey=true useTicketCache=false serviceName="zookeeper" principal="storm@STORM.EXAMPLE.COM"; }; Server { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/keytabs/zk.keytab" storeKey=true useTicketCache=false serviceName="zookeeper" principal="zookeeper/zk1.example.com@STORM.EXAMPLE.COM"; }; ``` Nimbus 還會將 principal 轉換成 本地用戶名, 以便其他服務可以使用此名稱.配置 Kerberos 身份驗證集 ``` storm.principal.tolocal: "org.apache.storm.security.auth.KerberosPrincipalToLocal" ``` 這只需要在 nimbus 上完成, 但不會對任何節點造成傷害. 我們還需要從 ZooKeeper 的角度通知 topology 誰是 supervisor 守護程序和 nimbus 守護程序正在運行. ``` storm.zookeeper.superACL: "sasl:${nimbus-user}" ``` 這里 _nimbus-user_ 是 nimbus 用于使用 ZooKeeper 進行身份驗證的 Kerberos 用戶. 如果 ZooKeeeper 正在剝離主機和領域, 那么這需要主機和領域也被剝離. #### ZooKeeper 集成 關于如何設置安全的 ZK 的完整細節超出了本文檔的范圍. 但是, 一般來說, 您要在每個服務器上啟用 SASL 身份驗證, 并可選擇剝離主機和領域. ``` authProvider.1 = org.apache.zookeeper.server.auth.SASLAuthenticationProvider kerberos.removeHostFromPrincipal = true kerberos.removeRealmFromPrincipal = true ``` 并且您希望在啟動服務器時在命令行中包含 jaas.conf, 以便可以使用它來查找 keytab. ``` -Djava.security.auth.login.config=/jaas/zk_jaas.conf ``` #### 網關 理想情況下, 最終用戶只需要在與 storm 交互之前運行 kinit.為了無縫地實現這一點, 我們需要在網關上使用默認的 jaas.conf. ``` StormClient { com.sun.security.auth.module.Krb5LoginModule required doNotPrompt=false useTicketCache=true serviceName="$nimbus_user"; }; ``` 如果最終用戶具有無頭鍵的用戶, 則可以覆蓋此 keytab. ### 授權設置 _身份驗證_ 完成了驗證用戶是誰的工作, 但是我們也需要 _授權_ 來執行每個用戶可以執行的任務. nimbus 的首選授權插件是 SimpleACLAuthorizer.要使用 _SimpleACLAuthorizer_, 請設置以下內容： ``` nimbus.authorizer: "org.apache.storm.security.auth.authorizer.SimpleACLAuthorizer" ``` DRPC 有一個獨立的授權器配置. 不要對 DRPC 使用 SimpleACLAuthorizer. 該 _SimpleACLAuthorizer_ 插件需要知道誰主管用戶, 它需要知道所有的管理員用戶, 包括運行UI守護進程在用戶的. 這些通過 _nimbus.supervisor.users_ 和 _nimbus.admins_ 分別設置. 每個可以是一個完整的 Kerberos principal 名稱, 也可以是主機和領域的用戶名. 日志服務器有自己的授權配置.這些都是通過 _logs.users_ 和 _logs.groups_ 設置的. 應將這些設置為集群中所有節點的管理員用戶或組. 提交 topology 時, 提交用戶也可以在此列表中指定用戶. 指定的用戶和組（除了群集范圍內的用戶）將被授予對日志查看器中提交的 topology 的 worker 日志的訪問權限. ### Supervisors 匿名用戶 和 組設置 為了確保 multi-tenancy 用戶的隔離, 需要在 supervisor 節點上運行 supervisors, 匿名用戶 和 唯一組 來執行. 要啟用以下步驟. 1. 向所有 supervisor 主機添加 headlessuser. 2. 創建唯一的組, 并使其成為 supervisor 節點上 匿名用戶的主組. 3. 對于這些 supervisor 節點, 設置以下 storm 屬性. ### Multi-tenant 調度 為了更好地支持 multi-tenancy, 我們已經編寫了一個新的調度程序. 啟用此調度程序集. ``` storm.scheduler: "org.apache.storm.scheduler.multitenant.MultitenantScheduler" ``` 請注意, 此調度程序的許多功能都依賴于 storm 身份驗證. 沒有他們, 調度程序將不知道用戶是什么, 也不會正確地隔離 topology. multi-tenant 調度程序的目標是提供一種將 topology 彼此隔離的方法, 但也限制了個人用戶可以在群集中擁有的資源. 調度器當前有一個配置, 可以通過 =storm.yaml= 或通過一個名為 =multitenant-scheduler.yaml= 的單獨配置文件來設置, 該配置文件應該放在與 =storm.yaml= 相同的目錄中. 最好使用 =multitenant-scheduler.yaml=, 因為它可以更新而不需要重新啟動 nimbus. 當前只有一個配置 =multitenant-scheduler.yaml=, =multitenant.scheduler.user.pools= 是從用戶名的映射到用戶保證能夠用于其 topology 結構的最大節點數. 例如： ``` multitenant.scheduler.user.pools: "evans": 10 "derek": 10 ``` ### 以提交 topology 的用戶身份運行 worker 進程 默認情況下, storm 運行作為運行 supervisor 的用戶的 worker. 這不是安全的理想選擇. 使 storm 作為啟動它們的用戶進行 topology 運行. ``` supervisor.run.worker.as.user: true ``` 有幾個與此相關的文件需要正確配置以使 storm 安全. worker-launcher可執行文件是一個特殊程序, 允許 supervisor 以不同的用戶身份啟動 worker. 為了這個工作, 它需要由 root 擁有, 但是該組被設置為只有 supervisor 匿名用戶是其中的一部分的組. 它還需要擁有6550個權限. 還有一個 worker-launcher.cfg 文件, 通常位于 /etc/ 下, 應該如下所示: ``` storm.worker-launcher.group=$(worker_launcher_group) min.user.id=$(min_user_id) ``` 其中 worker_launcher_group 是 supervisor 其中一部分的同一組, 并且 min.user.id 設置為系統上的第一個真實用戶標識. 此配置文件也需要由 root 擁有, 不具有世界或組寫權限. ### 冒充一個用戶 storm client 可以代表另一個用戶提交請求. 例如, 如果 `userX` 提交 oozie 工作流程, 并且作為工作流執行的一部分；如果用戶 `oozie` 想要代表 `userX` 它提交 topology, 可以通過利用模擬功能來實現. 為了提交 topology 作為其他用戶, 您可以使用 `StormSubmitter.submitTopologyAs` API.或者, 您可以使用 `NimbusClient.getConfiguredClientAs` nimbus client 作為其他用戶, 并使用此 client 執行任何 nimbus 操作（即: kill/rebalance/activate/deactivate）. 默認情況下禁用模擬授權, 這意味著任何用戶都可以執行模擬. 為了確保只有授權用戶可以執行模擬, 您應該啟動 nimbus `nimbus.impersonation.authorizer` 設置 `org.apache.storm.security.auth.authorizer.ImpersonationAuthorizer`. 該 `ImpersonationAuthorizer` 用于 `nimbus.impersonation.acl` 為 ACL 對用戶進行授權. 以下是用于支持模擬的nimbus配置示例: ``` nimbus.impersonation.authorizer: org.apache.storm.security.auth.authorizer.ImpersonationAuthorizer nimbus.impersonation.acl: impersonating_user1: hosts: [comma separated list of hosts from which impersonating_user1 is allowed to impersonate other users] groups: [comma separated list of groups whose users impersonating_user1 is allowed to impersonate] impersonating_user2: hosts: [comma separated list of hosts from which impersonating_user2 is allowed to impersonate other users] groups: [comma separated list of groups whose users impersonating_user2 is allowed to impersonate] ``` 為了支持 oozie 用例, 可以提供以下配置: ``` nimbus.impersonation.acl: oozie: hosts: [oozie-host1, oozie-host2, 127.0.0.1] groups: [some-group-that-userX-is-part-of] ``` ### 自動憑證的推送和更新 個人 topology 能夠向 worker 推送憑證（票證和令牌）, 以便他們可以訪問安全服務. 將它暴露給所有的用戶可能會對他們造成痛苦. 要在常見情況下隱藏這些插件, 可以使用插件來填充憑據, 將另一方解壓縮到 java 主題中, 并且還允許 Nimbus 在需要時更新憑據. 這些由以下配置控制. topology.auto-credentials 是一個 java 插件的列表, 所有這些插件都必須實現 IAutoCredentials 接口, 該接口填充網關上的憑據, 并在 worker 端解包它們. 在 kerberos 安全集群上, 默認情況下應設置為指向 org.apache.storm.security.auth.kerberos.AutoTGT. nimbus.credential.renewers.classes 也應設置為此值, 以便 nimbus 可以代表用戶定期更新 TGT. nimbus.credential.renewers.freq.secs 控制更新者輪詢多長時間查看是否需要更新, 但默認值應該是正常的. 此外, Nimbus 本身可以用于代表用戶提交 topology 來獲取憑據. 這可以使用 nimbus.autocredential.plugins.classes 進行配置, 這是完全限定類名的列表, 所有這些都必須實現 INimbusCredentialPlugin. Nimbus 將調用所有配置的實現的 populateCredentials 方法作為 topology 提交的一部分. 您應該使用此配置與 topology.auto-credentials 和 nimbus.credential.renewers.classes, 以便憑據可以在 worker 端填充, 并且 nimbus 可以自動更新它們. 目前有兩個使用此配置的示例, AutoHDFS 和 AutoHBase, 它們自動填充 topology 提交程序的 hdfs 和 hbase 委托令牌, 以便他們不必在所有可能的工作主機上分發密鑰表. ### 范圍 默認情況下, storm 允許提交任何大小的 topology. 但 ZK 等人對 topology 結構實際上有多大的限制. 以下配置允許您限制 topology 的最大大小. | YAML 設置 | 描述 | | --- | --- | | nimbus.slots.perTopology | topology 可以使用的 slots/workers 的最大數量. | | nimbus.executors.perTopology | topology 可以使用的最大 executors/threads. | ### 日志清理 LogViewer 守護進程現在也負責清理舊的日志文件, 以防止 dead topologies. | YAML 設置 | 描述 | | --- | --- | | logviewer.cleanup.age.mins | worker 的日志必須在該日志被考慮進行清理之前（最后修改時間）多大.（生活 worker 的日志永遠不會被 logviewer 清理：他們的日志通過回撥滾動.） | | logviewer.cleanup.interval.secs | 日志記錄器清理工作日志的時間間隔（秒）. | ### 允許特定用戶或組訪問 storm 使用 SimpleACLAuthorizer, 任何具有有效 Kerberos 票證的用戶都可以部署 topology 或進行其他操作, 例如 激活, 停用, 訪問集群信息. 可以通過指定 nimbus.users 或 nimbus.groups 來限制此訪問. 如果 nimbus.users 僅配置列表中的用戶可以部署 topology 或訪問集群. 類似地, nimbus.groups 限制對屬于這些組的用戶的 storm 集群訪問. 要配置, 請在 storm.yaml 中指定以下配置: ``` nimbus.users: - "testuser" ``` 或者 ``` nimbus.groups: - "storm" ``` ### DRPC 希望更多在這個很快