このページの目次
ストリーミング API の設定
概要
この章では、Kafka 経由でメトリック メッセージをサブスクライブできるようにストリーミング API を構成する方法について説明します。
Pr
以下で説明します。
- ストリーミングAPIを有効にする方法
- 外部クライアントをリッスンするように Kafka を構成する方法
- ACLを使用するようにKafkaを構成し、上記のクライアントのSSL暗号化を設定する方法
カフカとは?
Kafkaは、さまざまなイベントソース(センサー、データベース、モバイルデバイス)からイベントストリームの形式で送信されたデータをリアルタイムでキャプチャし、後で取得および操作できるようにこれらのイベントストリームを永続的に保存できるイベントストリーミングプラットフォームです。
Kafkaを使用すると、イベントストリーミングをエンドツーエンドで、分散され、高度にスケーラブルで、弾力性があり、フォールトトレラントで安全な方法で管理できます。
Kafkaはさまざまな方法で構成でき、スケーラビリティと冗長システムのために設計されています。このドキュメントでは、Paragon Active AssuranceコントロールセンターにあるストリーミングAPI機能を利用するための設定方法にのみ焦点を当てています。より高度なセットアップについては、Kafkaの公式ドキュメント kafka.apache.org/26/documentation.html を参照してください。
用語
- カフカ: イベントストリーミングプラットフォーム。
- カフカのトピック: イベントのコレクション。
- Kafka 加入者/消費者: Kafka トピックに格納されているイベントの取得を担当するコンポーネント。
- カフカブローカー: Kafka クラスターのストレージ層サーバー。
- SSL/TLS: SSL は、インターネット経由で情報を安全に送信するために開発された安全なプロトコルです。TLSは、1999年に導入されたSSLの後継です。
- Sasl: ユーザー認証、データ整合性チェック、および暗号化のメカニズムを提供するフレームワーク。
- ストリーミングAPIサブスクライバー: Paragon Active Assuranceで定義された、外部アクセス用のトピックに保存されているイベントの取得を担当するコンポーネント。
- 認証局: 公開キー証明書を発行および取り消す信頼されたエンティティ。
- 認証局ルート証明書: 認証局を識別する公開キー証明書。
ストリーミングAPIの仕組み
前述のように、ストリーミング API を使用すると、外部クライアントは Kafka からメトリックに関する情報を取得できます。
テストまたは監視タスク中にテストエージェントによって収集されたすべてのメトリックは、ストリームサービスに送信されます。処理フェーズの後、Stream サービスはこれらのメトリクスを追加のメタデータと共に Kafka に公開します。
カフカトピックス
Kafkaには、すべてのデータが公開される トピック の概念があります。Paragon Active Assuranceには、このようなKafkaのトピックが多数用意されています。ただし、これらのサブセットのみが外部アクセス用です。
コントロールセンターの各Paragon Active Assuranceアカウントには、2つの専用トピックがあります。以下は、 ACCOUNT
アカウントの短い名前です。
paa.public.accounts.{ACCOUNT}.metrics
- 特定のアカウントのすべてのメトリクスメッセージがこのトピックに公開されます
- 大量のデータ
- 高い更新頻度
paa.public.accounts.{ACCOUNT}.metadata
- メトリックデータに関連するメタデータ(メトリックに関連付けられたテスト、モニター、テストエージェントなど)が含まれます。
- 少量のデータ
- 更新頻度が低い
ストリーミング API の有効化
これらの手順は、を使用してコントロールセンターサーバーで sudo
実行します。
ストリーミングAPIはコントロールセンターにオーバーヘッドを追加するため、デフォルトでは有効になっていません。APIを有効にするには、まずメイン構成ファイルでKafkaへのメトリックの公開を有効にする必要があります。
/etc/netrounds/netrounds.conf
KAFKA_METRICS_ENABLED = True
この機能を有効にすると、コントロールセンターのパフォーマンスに影響を与える可能性があります。それに応じてインスタンスの寸法が決まっていることを確認してください。
次に、これらのメトリックを正しい Kafka トピックに転送できるようにするには、次のようにします。
/etc/netrounds/metrics.yaml
streaming-api: true
ストリーミング API サービスを有効にして開始するには、次のコマンドを実行します。
sudo ncc services enable timescaledb metrics sudo ncc services start timescaledb metrics
最後に、サービスを再起動します。
sudo ncc services restart
ストリーミングAPIがコントロールセンターで動作することを検証
これらの命令は、コントロール・センター・サーバー上で実行されます。
正しい Kafka トピックに関するメトリクスを受信していることを確認できるようになりました。これを行うには、ユーティリティをインストールします kafkacat
。
sudo apt-get update sudo apt-get install kafkacat
コントロールセンターでテストまたはモニターを実行している場合は、これらのトピックに関するメトリックとメタデータを受信するために使用できます kafkacat
。
アカウントの短い名前に置き換え myaccount
ます(これはコントロールセンターのURLに表示されるものです)。
export METRICS_TOPIC=paa.public.accounts.myaccount.metrics export METADATA_TOPIC=paa.public.accounts.myaccount.metadata
次のコマンドを実行すると、メトリックが表示されます。
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
メタデータを表示するには、次のコマンドを実行します (これは頻繁には更新されないことに注意してください)。
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e
kafkacat
既定ではデコードされません。これらのトピックを正しく購読するには、「
クライアントの例」セクションを参照してください。
これにより、コントロールセンター内からストリーミングAPIが機能していることが確認されます。ただし、ほとんどの場合、代わりに外部クライアントからデータにアクセスすることに関心があります。次のセクションでは、外部アクセス用に Kafka を開く方法について説明します。
外部ホスト用に Kafka を開く
これらの命令は、コントロール・センター・サーバー上で実行されます。
デフォルトでは、コントロールセンターで実行されているKafkaは、内部使用のためにローカルホストでのみリッスンするように構成されています。Kafka 設定を変更することで、外部クライアントに対して Kafka を開くことができます。
- カフカへの接続: 注意事項
- SSL/TLS暗号化
- SSL/TLS 証明書の概要
- 必要な証明書の作成
- コントロールセンターでのKafkaブローカーSSL/TLS設定
- アクセス コントロール リスト(ACL)の設定
カフカへの接続: 注意事項
これらの概念を理解していない場合、Kafkaとの接続の問題が発生する可能性があるため、これを注意深くお読みください。
このドキュメントで説明されているコントロールセンターのセットアップでは、Kafka ブローカーは 1 つだけです。
ただし、Kafkaブローカーは、多くのKafkaブローカーで構成される可能性のあるKafka クラスター の一部として実行されることを意図していることに注意してください。
Kafka ブローカーに接続する場合、初期接続は Kafka クライアントによって設定されます。この接続を介して、Kafkaブローカーは、1つ以上のKafkaブローカーのリストである「アドバタイズされたリスナー」のリストを返します。
このリストを受信すると、Kafka クライアントは切断し、これらのアドバタイズされたリスナーの 1 つに再接続します。アドバタイズされたリスナーには、Kafka クライアントがアクセスできるホスト名または IP アドレスが含まれている必要があります。含まれていない場合、クライアントは接続に失敗します。
特定のホスト名に関連付けられたSSL証明書を含むSSL暗号化を使用する場合、接続が拒否される可能性があるため、Kafkaクライアントが接続する正しいアドレスを受け取ることがさらに重要です。
カフカリスナーの詳細については、こちらをご覧ください: www.confluent.io/blog/kafka-listeners-explained
SSL/TLS暗号化
信頼できるクライアントのみがKafkaとストリーミングAPIにアクセスできるようにするには、次のように構成する必要があります。
- 認証: クライアントは、クライアントと Kafka 間の SSL/TLS セキュア接続を介してユーザー名とパスワードを提供する必要があります。
- 承認: 認証されたクライアントは、ACL によって規制されるタスクを実行できます。
概要は次のとおりです。
SSL / TLS暗号化がKafkaでどのように機能するかを完全に理解するには、公式ドキュメントを参照してください。 docs.confluent.io/platform/current/kafka/encryption.html
SSL/TLS 証明書の概要
このサブセクションでは、次の用語を使用します。
証明 書: 認証局 (CA) によって署名された SSL 証明書。各カフカブローカーには1つあります。
キーストア: 証明書を保管する鍵ストア・ファイル。鍵ストア・ファイルには、証明書の秘密鍵が含まれています。したがって、安全に保管する必要があります。
トラスト ストア: 信頼できる CA 証明書を含むファイル。
外部クライアントとコントロールセンターで実行されているKafka間の認証を設定するには、両側に、認証局(CA)によって署名された関連証明書とCAルート証明書で定義された キーストア が必要です。
これに加えて、クライアントには CA ルート証明書を持つ トラストストア も必要です。
CA ルート証明書は、Kafka ブローカーと Kafka クライアントに共通です。
必要な証明書の作成
これについては、 付録で説明します。
コントロールセンターでのKafkaブローカーSSL/TLS設定
これらの命令は、コントロール・センター・サーバー上で実行されます。
続行する前に、 付録の指示に従って、SSL 証明書を含む鍵ストアを作成する必要があります。以下で説明するパスは、これらの手順に基づいています。
SSL 鍵ストアは、ファイル拡張子が .jks のディスクに保管されるファイルです。
Kafka ブローカーと Kafka クライアントの両方に必要な証明書を作成したら、コントロールセンターで実行されている Kafka ブローカーを設定して続行できます。次のことを知っておく必要があります。
<public_hostname>
: コントロールセンターの公開ホスト名。これは、Kafka クライアントから解決可能でアクセスできる必要があります。<keystore_pwd>
: SSL 証明書の作成時に指定された鍵ストア・パスワード。<admin_pwd>
および<client_pwd>
:これらは、管理者ユーザーとクライアントユーザーにそれぞれ設定するパスワードです。例に示されているように、さらにユーザーを追加できることに注意してください。
以下の/etc/kafka/server.properties
プロパティを編集または追加(アクセス可能sudo
)し、次のように上記の変数を挿入します。
削除 PLAINTEXT://localhost:9092
しないでください。これにより、内部サービスが通信できなくなるため、コントロールセンターの機能が機能しなくなります。
... # The addresses that the Kafka broker listens on. listeners=PLAINTEXT://localhost:9092,SASL_SSL://0.0.0.0:9093 # These are the hosts advertised back to any client connecting. advertised.listeners=PLAINTEXT://localhost:9092,SASL_SSL://<public_hostname>:9093 ... ####### CUSTOM CONFIG # SSL CONFIGURATION ssl.endpoint.identification.algorithm= ssl.keystore.location=/var/ssl/private/kafka.server.keystore.jks ssl.keystore.password=<keystore_pwd> ssl.key.password=<keystore_pwd> ssl.client.auth=none ssl.protocol=TLSv1.2 # SASL configuration sasl.enabled.mechanisms=PLAIN listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \ username="admin" \ password="<admin_pwd>" \ user_admin="<admin_pwd>" \ user_client="<client_pwd>"; # NOTE more users can be added with user_<name>= # Authorization, turn on ACLs authorizer.class.name=kafka.security.authorizer.AclAuthorizer super.users=User:admin
アクセス コントロール リスト(ACL)の設定
ローカルホストで ACL を有効にする
最初にローカルホストのACLを設定して、コントロールセンター自体が引き続きKafkaにアクセスできるようにする必要があります。これが行われないと、物事は壊れます。
######### ACLs entries for anonymous users /usr/lib/kafka/bin/kafka-acls.sh \ --authorizer kafka.security.authorizer.AclAuthorizer \ --authorizer-properties zookeeper.connect=localhost:2181 \ --add --allow-principal User:ANONYMOUS --allow-host 127.0.0.1 --cluster /usr/lib/kafka/bin/kafka-acls.sh \ --authorizer kafka.security.authorizer.AclAuthorizer \ --authorizer-properties zookeeper.connect=localhost:2181 \ --add --allow-principal User:ANONYMOUS --allow-host 127.0.0.1 --topic '*' /usr/lib/kafka/bin/kafka-acls.sh \ --authorizer kafka.security.authorizer.AclAuthorizer \ --authorizer-properties zookeeper.connect=localhost:2181 \ --add --allow-principal User:ANONYMOUS --allow-host 127.0.0.1 --group '*'
次に、外部ユーザーがトピックを読む paa.public.*
ことができるように、外部読み取り専用アクセスのACLを有効にする必要があります。
よりきめ細かい制御については、Kafka の公式ドキュメントを参照してください。
######### ACLs entries for external users /usr/lib/kafka/bin/kafka-acls.sh \ --authorizer kafka.security.authorizer.AclAuthorizer \ --authorizer-properties zookeeper.connect=localhost:2181 \ --add --allow-principal User:* --operation read --operation describe \ --group 'NCC' /usr/lib/kafka/bin/kafka-acls.sh \ --authorizer kafka.security.authorizer.AclAuthorizer \ --authorizer-properties zookeeper.connect=localhost:2181 \ --add --allow-principal User:* --operation read --operation describe \ --topic paa.public. --resource-pattern-type prefixed
これが完了したら、サービスを再起動する必要があります。
sudo ncc services restart
クライアントが安全な接続を確立できることを確認するには、(コントロールセンターサーバーではなく)外部のクライアントコンピューターで次のコマンドを実行します。以下は、 PUBLIC_HOSTNAME
コントロールセンターのホスト名です。
openssl s_client -debug -connect ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep "Secure Renegotiation IS supported"
Secure Renegotiation IS supported
内部サービスに Kafka サーバーへのアクセスが許可されていることを確認するには、次のログファイルを確認してください。
/var/log/kafka/server.log
/var/log/kafka/kafka-authorizer.log
外部クライアント接続の検証
カフカキャット
これらの手順は、(コントロールセンターサーバーではなく )クライアントコンピューターで 実行します。
メトリック情報を表示するには、コントロールセンターで少なくとも 1 つのモニターが実行されていることを確認します。
外部クライアントとしての接続を確認および検証するには、「ストリーミングAPIがコントロールセンターで機能することの確認ストリーミングAPIがコントロールセンターで動作することを確認する」セクションでインストールされたユーティリティを使用できますkafkacat
。
次の手順を実行します。
以下は、 CLIENT_USER
コントロールセンターのファイルで /etc/kafka/server.properties
以前に指定されたユーザー、つまり、 user_client
そこに設定されたパスワードです。
サーバー側の SSL 証明書の署名に使用する CA ルート証明書がクライアントに存在する必要があります。
-
client.properties
次の内容のファイルを作成します。security.protocol=SASL_SSL ssl.ca.location={PATH_TO_CA_CERT} sasl.mechanisms=PLAIN sasl.username={CLIENT_USER} sasl.password={CLIENT_PASSWORD}
どこ
{PATH_TO_CA_CERT}
は、Kafka ブローカーが使用する CA ルート証明書の場所です{CLIENT_USER}
および{CLIENT_PASSWORD}
はクライアントのユーザー資格情報です。
-
次のコマンドを実行して、 によって消費
kafkacat
されるメッセージを確認します。export KAFKA_FQDN=<Control Center hostname> export METRICS_TOPIC=paa.public.accounts.<account short name>.metrics kafkacat -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
ここで
{METRICS_TOPIC}
、 は接頭辞"paa.public."
付きの Kafka トピックの名前です。
古いバージョンには kafkacat
、 -F
ファイルからクライアント設定を読み取るためのオプションがありません。このようなバージョンを使用している場合は、以下に示すように、コマンドラインから同じ設定を指定する必要があります。
kafkacat -b ${KAFKA_FQDN}:9093 \ -X security.protocol=SASL_SSL \ -X ssl.ca.location={PATH_TO_CA_CERT} \ -X sasl.mechanisms=PLAIN \ -X sasl.username={CLIENT_USER} \ -X sasl.password={CLIENT_PASSWORD} \ -t ${METRICS_TOPIC} -C -e
接続をデバッグするには、次のオプションを使用できます -d
。
Debug consumer communications kafkacat -d consumer -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e # Debug broker communications kafkacat -d broker -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
使用している Kafka クライアント ライブラリのプロパティは、「」 client.properties
のプロパティと異なる可能性があるため、必ず参照してください。
メッセージ形式
メトリックとメタデータのトピックに使用されるメッセージは、 プロトコル バッファー (protobuf) 形式でシリアル化されます ( developers.google.com/protocol-buffers を参照)。これらのメッセージのスキーマは、次の形式に従います。
メトリック Protobuf スキーマ
syntax = "proto3"; import "google/protobuf/timestamp.proto"; package paa.streamingapi; option go_package = ".;paa_streamingapi"; message Metrics { google.protobuf.Timestamp timestamp = 1; map<string, MetricValue> values = 2; int32 stream_id = 3; } /** * A metric value can be either an integer or a float. */ message MetricValue { oneof type { int64 int_val = 1; float float_val = 2; } }
メタデータ Protobuf スキーマ
syntax = "proto3"; package paa.streamingapi; option go_package = ".;paa_streamingapi"; message Metadata { int32 stream_id = 1; string stream_name = 2; map <string, string> tags = 13; }
クライアントの例
これらのコマンドは、コントロールセンターではなく、ラップトップなどの外部クライアントで実行することを目的としています。
メトリック情報を表示するには、コントロールセンターで少なくとも 1 つのモニターが実行されていることを確認します。
コントロールセンターの tarball には、ストリーミング API の使用方法を示す Python スクリプトの例を含むアーカイブ paa-streaming-api-client-examples.tar.gz
(client-examples) が含まれています。
クライアントの例のインストールと構成
Paragon Active Assuranceコントロールセンターのフォルダには、 client-examples
次のものがあります。
export CC_VERSION=4.4.0
cd ./paa-control-center_${CC_VERSION}
ls paa-streaming-api-client-examples*
外部クライアントコンピュータにインストール client-examples
するには、次の手順に従います。
# Create directory for extracting the content of the client examples tarball mkdir paa-streaming-api-client-examples # Extract the content of the client examples tarball tar xzf paa-streaming-api-client-examples.tar.gz -C paa-streaming-api-client-examples # Go to the newly created directory cd paa-streaming-api-client-examples
client-examples
実行するには Docker が必要です。Docker のダウンロードとインストール手順は、 https://docs.docker.com/engine/install にあります。
クライアントの例の使用
client-examples
ツールは基本モードまたは詳細モードで実行して、さまざまな複雑さの例を作成できます。どちらの場合も、クライアント側をさらにカスタマイズするための追加のプロパティを含む構成ファイルを使用して例を実行することもできます。
基本モード
基本モードでは、メトリックとそのメタデータは個別にストリーミングされます。この目的のために、クライアントは外部アクセスに使用できる各Kafkaトピックをリッスンし、受信したメッセージをコンソールに出力するだけです。
基本的な例の実行を開始するには、次のコマンドを実行します。
./build.sh run-basic --kafka-brokers localhost:9092 --account ACCOUNT_SHORTNAME
ここで ACCOUNT_SHORTNAME
、はメトリックを取得するアカウントの短い名前です。
この例の実行を終了するには、Ctrl + C キーを押します (クライアントはタイムアウト イベントを待機するため、実行が停止するまでに若干の遅延が発生する場合があります)。
詳細モード
メトリックは、コントロールセンターで実行されている HTTPモニター に対してのみ表示されます。
詳細モードでの実行では、メトリックとメタデータ メッセージの相関関係が表示されます。これは、対応するメタデータメッセージを参照するフィールドの各メトリックメッセージ stream id
の存在のおかげで可能です。
高度な例を実行するには、次のコマンドを実行します。
./build.sh run-advanced --kafka-brokers localhost:9092 --account ACCOUNT_SHORTNAME
ここで ACCOUNT_SHORTNAME
、はメトリックを取得するアカウントの短い名前です。
この例の実行を終了するには、Ctrl + C キーを押します (クライアントはタイムアウト イベントを待機するため、実行が停止するまでに若干の遅延が発生する場合があります)。
追加設定
オプションの後に という形式でkey=value
プロパティを含むファイル名を指定することで、クライアント--config-file
の追加設定で例を実行することができます。
./build.sh run-advanced \ --kafka-brokers localhost:9092 \ --account ACCOUNT_SHORTNAME \ --config-file client_config.properties
上記のコマンドで参照されるすべてのファイルは、現在のディレクトリに配置され、相対パスのみを使用して参照される必要があります。これは、 --config-file
引数と、ファイルの場所を記述する構成ファイル内のすべてのエントリの両方に適用されます。
外部クライアント認証の検証
を使用して、コントロールセンターの client-examples
外部からクライアント認証を検証するには、以下のステップを実行します。
-
Paragon Active Assuranceコントロールセンターのフォルダから、次のフォルダに切り替えます
paa-streaming-api-client-examples
。cd paa-streaming-api-client-examples
- CA ルート証明書
ca-cert
を現在のディレクトリにコピーします。 -
client.properties
次の内容のファイルを作成します。security.protocol=SASL_SSL ssl.ca.location=ca-cert sasl.mechanism=PLAIN sasl.username={CLIENT_USER} sasl.password={CLIENT_PASSWORD}
ここで
{CLIENT_USER}
、 と{CLIENT_PASSWORD}
はクライアントのユーザー資格情報です。 -
基本的な例を実行します。
export KAFKA_FQDN=<Control Center hostname> ./build.sh run-basic --kafka-brokers ${KAFKA_FQDN}:9093 \ --account ACCOUNT_SHORTNAME --config-file client.properties
ここで
ACCOUNT_SHORTNAME
、はメトリックを取得するアカウントの短い名前です。 -
高度な例を実行する:
export KAFKA_FQDN=<Control Center hostname> ./build.sh run-advanced --kafka-brokers ${KAFKA_FQDN}:9093 \ --account ACCOUNT_SHORTNAME --config-file client.properties
付録
この付録では、以下を作成する方法について説明します。
- Kafka ブローカーの SSL 証明書を格納するための 鍵ストア ・ファイル
- Kafka ブローカー証明書の署名に使用される認証局 (CA) ルート証明書を格納するための トラストストア ・ファイル。
Kafka ブローカー証明書の作成
実際の認証局を使用した証明書の作成 (推奨)
信頼できる CA から実際の SSL 証明書を取得することをお勧めします。
CA を決定したら、次に示すように、CA ルート証明書 ca-cert
ファイルを独自のパスにコピーします。
export CA_PATH=~/my-ca mkdir ${CA_PATH} cp ca-cert ${CA_PATH}
独自の認証局を作成する
通常、証明書は実際の認証局によって署名されている必要があります。前のサブセクションを参照してください。以下は一例です。
ここでは、999日間有効な独自の認証局(CA)ルート証明書ファイルを作成します(本番環境では推奨されません)。
# Create a directory for storing the CA export CA_PATH=~/my-ca mkdir ${CA_PATH} # Generate the CA certificate openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999
クライアントトラストストアの作成
これで、上記で生成されたもの ca-cert
を含むトラストストアファイルを作成できます。このファイルは、ストリーミング API にアクセスする Kafka クライアントで必要になります。
keytool -keystore kafka.client.truststore.jks \ -alias CARoot \ -importcert -file ${CA_PATH}/ca-cert
CA 証明書がトラストストアに入ったので、クライアントはそれを使用して署名されたすべての証明書を信頼します。
ファイルを kafka.client.truststore.jks
クライアントコンピューター上の既知の場所にコピーし、設定でポイントする必要があります。
Kafka ブローカーのキーストアの作成
Kafka ブローカーの SSL 証明書を生成してからキーストア kafka.server.keystore.jks
を生成するには、次の手順に従います。
SSL 証明書の生成
以下では、999 は鍵ストアの有効期間の日数であり FQDN
、はクライアントの完全修飾ドメイン名 (ノードの公開ホスト名) です。
Kafka FQDN
クライアントがコントロールセンターへの接続に使用するホスト名と完全に一致することが重要です。
sudo mkdir -p /var/ssl/private sudo chown -R $USER: /var/ssl/private cd /var/ssl/private export FQDN=<Control Center hostname> keytool -keystore kafka.server.keystore.jks \ -alias server \ -validity 999 \ -genkey -keyalg RSA -ext SAN=dns:${FQDN}
証明書署名要求を作成し、 という名前のファイル cert-server-request
に保存します。
keytool -keystore kafka.server.keystore.jks \ -alias server \ -certreq \ -file cert-server-request
実際のファイルを使用している場合は、ファイルを cert-server-request
認証局(CA)に送信する必要があります。その後、署名された証明書が返されます。これを cert-server-signed
以下のように参照します。
自己作成 CA 証明書を使用した SSL 証明書の署名
繰り返しになりますが、実動システムでは独自の CA を使用することはお勧めしません。
署名付き証明書cert-server-signed
を生成するファイル cert-server-request
を使用して、CA を使用して証明書に署名します。下記参照。ca-password
は、CA 証明書の作成時に設定したパスワードです。
cd /var/ssl/private openssl x509 -req \ -CA ${CA_PATH}/ca-cert \ -CAkey ${CA_PATH}/ca-key \ -in cert-server-request \ -out cert-server-signed \ -days 999 -CAcreateserial \ -passin pass:{ca-password}
キーストアへの署名付き証明書のインポート
ルート証明書を ca-cert
キーストアにインポートします。
keytool -keystore kafka.server.keystore.jks \ -alias ca-cert \ -import \ -file ${CA_PATH}/ca-cert
と呼ばれる署名付き証明書をインポートします cert-server-signed
。
keytool -keystore kafka.server.keystore.jks \ -alias server \ -import \ -file cert-server-signed
このファイルは kafka.server.keystore.jks
、コントロール・センター・サーバー上の既知の場所にコピーし、 で /etc/kafka/server.properties
参照する必要があります。