配置客戶端以安全連線到Apache Kafka叢集4:TLS客戶端身份驗證

語言: CN / TW / HK

在本系列的前幾篇文章中,我們討論了Kafka的Kerberos,LDAP和PAM身份驗證。在這篇文章中,我們將研究如何配置Kafka叢集和客戶端以使用TLS客戶端身份驗證。

此處顯示的示例將以粗體突出顯示與身份驗證相關的屬性,以將其與其他必需的安全屬性區分開,如下例所示。假定已為Apache Kafka叢集啟用了TLS,並且應該為每個安全叢集啟用TLS。


security.protocol=SSL
ssl.truststore.location=/opt/cloudera/security/jks/truststore.jks

我們將kafka-console-consumer用於以下所有示例。所有概念和配置也適用於其他應用程式。

TLS客戶端身份驗證

TLS客戶端身份驗證是Kafka支援的另一種身份驗證方法。它允許客戶端使用自己的TLS客戶端證書連線到叢集以進行身份驗證。

證書管理和金鑰庫生成不在本文討論範圍之內,但是這些是標準的TLS做法。請注意,證書Keystores與Kerberos Keytab一樣敏感,應該這樣對待。金鑰庫許可權應始終進行限制性設定,以免它們受到損害,並且不應共享。每個客戶端都應獲得自己的證書。

必須設定以下Kafka客戶端屬性,以配置Kafka客戶端以使用TLS證書進行身份驗證:

# Uses SSL security protocolsecurity.protocol=SSLssl.keystore.location=./alice-keystore.jksssl.keystore.password=supersecret1ssl.key.password=supersecret1# TLS truststoressl.truststore.location=/opt/cloudera/security/jks/truststore.jks

上面的配置使用TLS(SSL)進行身份驗證資料加密。

在Kafka Broker上啟用TLS身份驗證

安裝Kafka服務時,預設情況下未為Kafka代理啟用TLS身份驗證,但是通過Cloudera Manager對其進行配置相當容易。

預設情況下,在安全叢集中,Kafka具有配置用於處理SASL_SSL身份驗證的單個偵聽器。要啟用TLS身份驗證,我們需要在其他埠上建立一個附加的偵聽器來處理SSL協議。這是通過Kafka broker的listeners屬性配置的。設定此屬性後,我們還需要注意在其中列出原始的SASL_SSL偵聽器,以確保客戶端(如果正在使用的話)仍可以通過Kerberos和LDAP進行身份驗證。

此外,要使用TLS客戶端身份驗證,我們必須確保broker和客戶端相互信任彼此的證書。在前面的示例中,我們已經為客戶端配置了一個信任庫,其中包含代理的證書發行者的證書(ssl.truststore.location屬性)。現在,如果這是與頒發代理證書的CA不同的CA ,還必須確保已將頒發客戶端證書的CA的證書新增到代理的信任庫中。

我們建議客戶端證書(和代理證書)由您擁有和控制的私有CA頒發。切勿將不受控制的CA證書(特別是公共CA)新增到叢集信任庫中。

在Cloudera Data Platform(CDP)部署中,在共享同一環境的所有叢集和服務之間一致地啟用TLS。該環境具有公共的共享資料體驗(SDX)層,其中包含在所有環境叢集之間共享的公共安全和治理上下文,並且TLS證書可以由SDX的嵌入式FreeIPA服務發行和管理。

  1. 在Cloudera Manager中,單擊Kafka>例項> Kafka Broker(單擊單個代理)> Configuration 。將顯示一個警報,您可以通過單擊“繼續編輯角色例項”將其忽略。

  2. 為Kafka代理設定以下屬性(使用您自己的代理的標準主機名)並儲存配置。我們在此安全閥中同時設定了兩個不同的屬性:listenersssl.principal.mapping.rules 。請在listeners屬性中注意每個偵聽器的不同協議埠。

  3. 對所有其他代理重複該過程。

  4. 現在在服務級別上設定以下內容,單擊Kafka>配置,然後在下面的配置中選中“ required ”。儲存您的更改:

  5. 如上所述,Kafka需要信任頒發給您的客戶的證書。如果這些證書是由與Kafka Broker證書不同的CA簽名的,則需要將客戶端證書的CA新增到Kafka信任庫中。您可以在Cloudera Manager的以下屬性中找到信任庫的位置:

  6. 執行以下命令(以root身份)將CA證書新增到信任庫中:

keytool \  -importcert \  -keystore /opt/cloudera/security/jks/truststore.jks \  -storetype JKS \  -alias ldap-ca \  -file /path/to/ca-cert.pem

 

  1. 單擊Kafka>操作>重新啟動以重新啟動Kafka服務並使更改生效。

安全中間代理協議

代理間通訊所使用的安全協議由Kafka的security.inter.broker.protocol屬性控制。Cloudera Manager將此屬性的預設設定設定為INFERRED 

在此配置中,CM將根據以下邏輯設定security.inter.broker.protocol屬性:

  • 如果正在使用Kerberos或LDAP身份驗證:

    • 如果啟用了TLS,請將其設定為SASL_SSL

    • 如果未啟用TLS,請將其設定為SASL_PLAINTEXT

  • 除此以外:

    • 如果啟用了TLS,請將其設定為SSL

    • 如果未啟用TLS,請將其設定為PLAINTEXT

如果您使用不同的安全協議定義了多個偵聽器,並且推斷的中間代理協議不是您要使用的協議,則可以使用上面顯示的屬性覆蓋。

Principal名稱對映

當客戶端使用TLS金鑰庫進行身份驗證時,預設情況下,Kafka會假定該客戶端的使用者名稱是證書的使用者名稱,通常是可分辨名稱,如下所示: 

cn=alice,cn=groups,cn=accounts,dc=hadoopsecurity,dc=local

使用這些長名稱很麻煩。安全策略和組對映通常是根據使用者的簡稱(alice )而不是完整的專有名稱來定義的。因此,我們需要配置Kafka以將證書的主題轉換為短名稱,我們可以將其用作使用者的唯一識別符號。

如果您使用的是Kafka 2.4.0 (*)或更高版本,則可以通過使用必要的對映規則設定ssl.principal.mapping.rules引數來完成此操作。對於較舊的版本,您可以提供一個自定義的主體構建器。建立定製構建器超出了本文件的範圍,但是您可以在此處找到一個很好的示例。 

該規則採用正則表示式的形式來匹配證書的使用者名稱,並應用轉換來匹配。可以有多個規則,以逗號分隔。最後一條規則通常是DEFAULT規則,它僅使用完整的主題名稱

例如,考慮以下設定:

ssl.principal.mapping.rules=RULE:^.*[Cc][Nn]=([a-zA-Z0-9.]*).*$/$1/L,DEFAULT

上面的配置有2條規則,它們按順序處理:

RULE:^[Cc][Nn]=([a-zA-Z0-9.]*).*$/$1/LDEFAULT

將使用與證書的主題名稱匹配的第一個規則,而後一個規則將被忽略。該預設規則是“包羅永珍的”。如果以前的匹配項都不匹配,它將始終匹配並且不會進行任何替換。

上面第一個規則的正則表示式(^[Cc][Nn]=([a-zA-Z0-9.]*).*$)將匹配以CN = (:cn = ,Cn = ,cN =),後跟使用者的簡稱(應僅包含以下字元:a-zA-Z0-9.),後跟任何其他字元。它用使用者短名稱替換匹配的字串,該使用者短名稱是括號內匹配的內容,在規則的第二部分中以$ 1引用。您可以在實際操作中看到它,並在此處使用正則表示式和示例。

規則末尾的L將結果字串轉換為小寫。您可以在Kafka官方文件中看到更多詳細資訊和規則示例。

證書吊銷列表

證書吊銷列表(或CRL)是已頒發證書的證書頒發機構(CA)在其計劃的到期日期之前已將其撤消的數字證書的列表,並且不再受信任。CRL是TLS身份驗證的重要功能,可確保可以將已被破壞的客戶端證書標記為已過期,以便Kafka代理拒絕來自使用它們的客戶端的連線。

儘管Kafka尚未直接支援CRL的使用(請參閱KAFKA-3700),但是Java框架中提供了該選項。可以通過CRL分發點(CRLDP)或通過線上證書狀態協議(OCSP)來執行吊銷檢查。要使用這兩種方法中的任何一種,必須首先確保使用這些方法之一將證書頒發機構(CA)正確配置為進行證書吊銷檢查,並且證書中包含用於此操作的必要資訊。CA的配置和具有正確屬性的證書的生成不在本文件的範圍之內。

要為Kafka啟用證書吊銷檢查,請執行以下步驟:

要使用CRLDP啟用吊銷檢查

a.在Cloudera Manager中,轉到Kafka>配置,然後搜尋Additional Broker Java Options屬性。

b.將以下值附加到該屬性的末尾:

-Dcom.sun.security.enableCRLDP=true
-Dcom.sun.net.ssl.checkRevocation=true


要使用OCSP啟用吊銷檢查

a.除了上述針對CRLDP的屬性外,還將以下值附加到同一屬性的末尾:

-Djava.security.properties=<(echo "ocsp.enable=true")

進行以上任何更改後,都必須重新啟動Kafka服務。如果在CA和證書中未正確配置對CRLDP和/或OCSP的支援,則該服務可能無法啟動。

即使未啟用證書吊銷,也可以通過確保吊銷和/或拒絕所有適用於那些證書的授權策略(通過Ranger,Sentry或ACL)來阻止對Kafka資源的訪問。

示例

以下是使用Kafka控制檯使用者使用TLS身份驗證從主題讀取的示例。請注意,在連線到叢集時,我們使用SSL偵聽器的埠(9094)而不是預設的9093提供引導伺服器。

$ cat tls-client.propertiessecurity.protocol=SSLssl.keystore.location=./alice-keystore.jksssl.keystore.password=supersecret1ssl.key.password=supersecret1ssl.truststore.location=/opt/cloudera/security/jks/truststore.jks $ kafka-console-consumer \    --bootstrap-server host-1.example.com:9094 \    --topic test \    --consumer.config ./tls-client.properties

注意:上面的客戶端配置包含敏感的憑據。將此配置儲存在檔案中時,請確保已設定檔案許可權,以便只有檔案所有者才能讀取它。

還有更多

我們將在本部落格系列中回顧所有這些身份驗證方法,這些方法為您提供了靈活的配置Kafka叢集的方法,以便與適用於您的環境的身份驗證機制整合在一起。

我們將在本系列的下一篇文章中繼續探索其他身份驗證替代方案。同時,如果您有興趣瞭解Cloudera的Kafka產品,請下載此白皮書

(*)ssl.principal.mapping.rules屬性自Kafka 2.2.0起可用,但不能處理證書專有名稱(KAFKA-8860)中的空格。Kafka 2.4.0是更強大的起點。

原文作者:Andre Araujo

原文連結:https://blog.cloudera.com/how-to-configure-clients-to-connect-to-apache-kafka-clusters-securely-part-4-tls-client-authentication/




本文分享自微信公眾號 - 大資料雜貨鋪(bigdataGrocery)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。