第11章 TLS 証明書の管理
AMQ Streams は、Kafka と AMQ Streams コンポーネントとの間で TLS プロトコルを使用して暗号化された通信をサポートします。Kafka ブローカー間の通信 (Interbroker 通信)、ZooKeeper ノード間の通信 (Internodal 通信)、およびこれらと AMQ Streams Operator 間の通信は、常に暗号化されます。Kafka クライアントと Kafka ブローカーとの間の通信は、クラスターが設定された方法に応じて暗号化されます。Kafka および AMQ Streams コンポーネントでは、TLS 証明書も認証に使用されます。
Cluster Operator は、自動で TLS 証明書の設定および更新を行い、クラスター内での暗号化および認証を有効にします。また、Kafka ブローカーとクライアントとの間の暗号化または TLS 認証を有効にする場合、他の TLS 証明書も設定されます。ユーザーが用意した証明書は更新されません。
TLS 暗号化が有効になっている TLS リスナーまたは外部リスナーの、Kafka リスナー証明書 と呼ばれる独自のサーバー証明書を提供できます。詳細は、「Kafka リスナー証明書」 を参照してください。
図11.1 TLS によってセキュリティーが保護された通信のアークテクチャー例
11.1. 認証局
暗号化のサポートには、AMQ Streams コンポーネントごとに固有の秘密鍵と公開鍵証明書が必要です。すべてのコンポーネント証明書は、クラスター CA と呼ばれる内部認証局 (CA) により署名されます。
同様に、TLS クライアント認証を使用して AMQ Streams に接続する各 Kafka クライアントアプリケーションは、秘密鍵と証明書を提供する必要があります。クライアント CA という第 2 の内部 CA を使用して、Kafka クライアントの証明書に署名します。
11.1.1. CA 証明書
クラスター CA とクライアント CA の両方には、自己署名の公開鍵証明書があります。
Kafka ブローカーは、クラスター CA またはクライアント CA のいずれかが署名した証明書を信頼するように設定されます。クライアントによる接続が不要なコンポーネント (ZooKeeper など) のみが、クラスター CA によって署名された証明書を信頼します。外部リスナーの TLS 暗号化が無効でない限り、クライアントアプリケーションはクラスター CA により署名された証明書を必ず信頼する必要があります。これは、相互 TLS 認証 を実行するクライアントアプリケーションにも当てはまります。
デフォルトで、AMQ Streams はクラスター CA またはクライアント CA によって発行された CA 証明書を自動で生成および更新します。これらの CA 証明書の管理は、Kafka.spec.clusterCa および Kafka.spec.clientsCa オブジェクトで設定できます。ユーザーが用意した証明書は更新されません。
クラスター CA またはクライアント CA に、独自の CA 証明書を提供できます。詳細は、「独自の CA 証明書のインストール」 を参照してください。独自の証明書を提供する場合は、証明書の更新が必要なときに手作業で更新する必要があります。
11.1.2. 独自の CA 証明書のインストール
この手順では、Cluster Operator で生成される CA 証明書と鍵を使用する代わりに、独自の CA 証明書と秘密鍵をインストールする方法について説明します。
以下の手順を使用して、独自のクラスターまたはクライアント CA 証明書をインストールできます。
この手順では、PEM 形式の CA 証明書の更新を説明します。PKCS #12 形式の証明書を使用することもできます。
前提条件
- Cluster Operator が稼働している必要があります。
- Kafka クラスターがデプロイされていない必要があります。
クラスター CA またはクライアントの、PEM 形式による独自の X.509 証明書および鍵が必要です。
ルート CA ではないクラスターまたはクライアント CA を使用する場合、証明書ファイルにチェーン全体を含める必要があります。チェーンの順序は以下のとおりです。
- クラスターまたはクライアント CA
- 1 つ以上の中間 CA
- ルート CA
- チェーン内のすべての CA は、X509v3 の基本制約 (Basic Constraint) で CA として設定する必要があります。
手順
CA 証明書を対応する
Secretに配置します。既存のシークレットを削除します。
oc delete secret CA-CERTIFICATE-SECRETCA-CERTIFICATE-SECRET は
Secretの名前で、クラスター CA 証明書の場合はCLUSTER-NAME-cluster-ca-cert、クライアント CA 証明書の場合はCLUSTER-NAME-clients-ca-certです。「Not Exists」エラーを無視します。
新規シークレットを作成およびラベル付けします。
oc create secret generic CA-CERTIFICATE-SECRET --from-file=ca.crt=CA-CERTIFICATE-FILENAME
CA キーを対応する
Secretに配置します。既存のシークレットを削除します。
oc delete secret CA-KEY-SECRETca-KEY-SECRET は CA キーの名前です。これは、クラスター CA キーの場合は
CLUSTER-NAME-cluster-ca、クライアント CA キーの場合はCLUSTER-NAME-clients-caです。新規シークレットを作成します。
oc create secret generic CA-KEY-SECRET --from-file=ca.key=CA-KEY-SECRET-FILENAME
シークレットに
strimzi.io/kind=Kafkaおよびstrimzi.io/cluster=CLUSTER-NAME ラベルを付けます。oc label secret CA-CERTIFICATE-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=CLUSTER-NAME oc label secret CA-KEY-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=CLUSTER-NAME
クラスターの
Kafkaリソースを作成し、生成された CA を使用 しない ようにKafka.spec.clusterCaまたはKafka.spec.clientsCaオブジェクトを設定します。独自指定の証明書を使用するようにクラスター CA を設定する
Kafkaリソースの例 (抜粋)kind: Kafka version: kafka.strimzi.io/v1beta1 spec: # ... clusterCa: generateCertificateAuthority: false
関連情報
- 以前インストールした CA 証明書を更新する場合は 「独自の CA 証明書の更新」 を参照してください。
- 「独自の Kafka リスナー証明書の指定」
