第12章 セキュリティー

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 リスナー証明書」 を参照してください。

図12.1 TLS によってセキュリティーが保護された通信のアークテクチャー図例

セキュアな通信

12.1. 認証局

暗号化のサポートには、AMQ Streams コンポーネントごとに固有の秘密鍵と公開鍵証明書が必要です。すべてのコンポーネント証明書は、クラスター CA と呼ばれる内部認証局 (CA) により署名されます。

同様に、TLS クライアント認証を使用して AMQ Streams に接続する各 Kafka クライアントアプリケーションは、秘密鍵と証明書を提供する必要があります。クライアント CA という第 2 の内部 CA を使用して、Kafka クライアントの証明書に署名します。

12.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 証明書のインストール」 を参照してください。独自の証明書を提供する場合は、証明書の更新が必要なときに手作業で更新する必要があります。

12.1.2. CA 証明書の有効期間

CA 証明書の有効期間は、証明書の生成からの日数で提示されます。有効期間は、それぞれ以下で設定できます。

  • クラスター CA 証明書の場合は Kafka.spec.clusterCa.validityDays。
  • クライアント CA 証明書の場合は Kafka.spec.clientsCa.validityDays。

12.1.3. 独自の CA 証明書のインストール

この手順では、Cluster Operator で生成される CA 証明書と秘密鍵を使用する代わりに、独自の CA 証明書と秘密鍵をインストールする方法について説明します。

前提条件

  • Cluster Operator が稼働中です。
  • Kafka クラスターがデプロイされていない必要があります。

  • クラスター CA またはクライアントの、PEM 形式による独自の X.509 証明書および鍵が必要です。

    • ルート CA ではないクラスターまたはクライアント CA を使用する場合、証明書ファイルにチェーン全体を含める必要があります。チェーンの順序は以下のとおりです。

      1. クラスターまたはクライアント CA
      2. 1 つ以上の中間 CA
      3. ルート CA
    • チェーン内のすべての CA は、X509v3 の基本制約 (Basic Constraint) で CA として設定する必要があります。

手順

  1. 使用する CA 証明書を対応する Secret に挿入します (クラスター CA の場合は <cluster>-cluster-ca-cert、クライアント CA の場合は <cluster>-clients-ca-cert)。

    以下のコマンドを実行します。 

    # Delete any existing secret (ignore "Not Exists" errors)
oc delete secret <ca-cert-secret>
# Create and label the new secret
oc create secret generic <ca-cert-secret> --from-file=ca.crt=<ca-cert-file>

  2. 使用する CA キーを対応する Secret に挿入します (クラスター CA の場合は <cluster>-cluster-ca、クライアント CA の場合は <cluster>-clients-ca)。 

    # Delete the existing secret
oc delete secret <ca-key-secret>
# Create the new one
oc create secret generic <ca-key-secret> --from-file=ca.key=<ca-key-file>

  3. 両方の Secrets に strimzi.io/kind=Kafka および strimzi.io/cluster=<my-cluster> というラベルを付けます。 

    oc label secret <ca-cert-secret> strimzi.io/kind=Kafka strimzi.io/cluster=<my-cluster>
oc label secret <ca-key-secret> strimzi.io/kind=Kafka strimzi.io/cluster=<my-cluster>

  4. クラスターの Kafka リソースを作成し、生成された CA を使用 しない ように Kafka.spec.clusterCa または Kafka.spec.clientsCa オブジェクトを設定します。

    独自指定の証明書を使用するようにクラスター CA を設定する Kafka リソースの例 (抜粋)

    kind: Kafka
version: kafka.strimzi.io/v1beta1
spec:
  # ...
  clusterCa:
    generateCertificateAuthority: false

関連情報