Ansible Playbook を使用した Confluent Platform での認証の構成¶

Kafka での認証¶

Ansible Playbooks for Confluent Platform では、Kafka 用に以下の認証モードをサポートします。

SASL PLAIN: ユーザー名とパスワードを使用するシンプルな認証です。
SASL SCRAM: ZooKeeper に保存されたユーザー名とパスワードを使用します。認証情報はインストール中に作成されます。
SASL GSSAPI（Kerberos）: Kerberos または Active Directory サーバーを認証に使用します。
mTLS: Kafka とクライアント間における双方向のトラフィックのセキュリティと信頼度を保証します。

デフォルトのインストールでは、Kafka に認証は設定されません。

SASL PLAIN 認証の構成¶

SASL PLAIN 認証を構成するには、hosts.yml ファイルに以下を設定します。このコードスニペット例では、デフォルトのユーザー以外に、user1、user2、user3 という 3 つのユーザーを追加しています。

sasl_plain_users のデフォルトキーは Confluent Platform コンポーネントに必須です。これには、Kafka ブローカー用の admin、外部コンポーネントが使用する client、schema_registry、kafka_connect、ksql、control_center、kafka-rest、kafka_connect_replicator が含まれます。

all:
  vars:
    sasl_protocol: plain
    sasl_plain_users:
      admin:
        principal: 'kafka'
        password: 'admin-secret'
      schema_registry:
        principal: 'schema-registry'
        password: 'schema_registry-secret'
      kafka_connect:
        principal: 'kafka-connect'
        password: 'kafka_connect-secret'
      ksql:
        principal: 'ksqldb'
        password: 'ksql-secret'
      kafka_rest:
        principal: 'kafka_rest'
        password: 'kafka_rest-secret'
      control_center:
        principal: 'control-center'
        password: 'control_center-secret'
      kafka_connect_replicator:
        principal: 'kafka_connect_replicator'
        password: 'kafka_connect_replicator-secret'
      client:
        principal: 'client'
        password: 'client-secret'
      user1:
        principal: 'user1'
        password: my-secret
      user2:
        principal: 'user2'
        password: my-secret
      user3:
        principal: 'user3'
        password: my-secret

SASL SCRAM（SHA-512）認証の構成¶

SHA-512 を使用する SASL SCRAM 認証を構成するには、hosts.yml ファイルに次のオプションを設定します。

all:
  vars:
    sasl_protocol: scram

インストール中に、各コンポーネントにユーザーが作成されます。このユーザーには、Kafka ブローカーの管理ユーザーと、外部コンポーネントから使用するためのクライアントユーザーがあります。

追加のユーザーを構成するには、hosts.yml ファイルに次のセクションを追加します。

all:
  vars:
    sasl_scram_users:
      user1:
        principal: user1
        password: my-secret

SASL SCRAM（SHA-256）認証の構成¶

SHA-256 を使用する SASL SCRAM 認証を構成するには、hosts.yml ファイルに次のオプションを設定します。

all:
  vars:
    sasl_protocol: scram256

インストール中に、各コンポーネントにユーザーが作成されます。このユーザーには、Kafka ブローカーの管理ユーザーと、外部コンポーネントから使用するためのクライアントユーザーがあります。

追加のユーザーを構成するには、hosts.yml ファイルに次のセクションを追加します。

all:
  vars:
    sasl_scram256_users:
      user1:
        principal: user1
        password: my-secret

SASL GSSAPI（Kerberos）認証の構成¶

現在のところ、Ansible Playbook では、KDC（Key Distribution Center）および Active Directory KDC の構成は行われません。Playbook とは別に KDC をセットアップし、独自のキータブを指定して SASL GSSAPI（Kerberos を使用した SASL）を構成する必要があります。

各コンポーネントとその内部ホストについて、ユーザーの組織の Kerberos KDC サーバー内にプリンシパルを作成します。
各プリンシパルについてキータブを生成します。このキータブファイルは Ansible コントロールノードに配置する必要があります。

Kerberos パッケージをインストールし、各ホストに /etc/krb5.conf ファイルを構成するには、hosts.yaml ファイルに以下の構成パラメーターを追加します。

Kerberos パッケージをインストールするかどうかと、/etc/krb5.conf ファイルを構成するかどうかを指定します。デフォルトは true です。

/etc/krb5.conf ファイルがホストで構成済みの場合は、kerberos_configure を false に設定します。
```
all:
  vars:
    kerberos_configure: <true-or-false>
```

Kafka ブローカー Kerberos プリンシパルの realm 部分と、KDC が実行されているマシンのホスト名を指定します。

all:
  vars:
    kerberos:
      realm: <kafka-principal-realm>
      kdc_hostname: <kdc-hostname>
      admin_hostname: <kdc-hostname>

Kerberos プリンシパル kafka/kafka1.hostname.com@EXAMPLE.COM に Kerberos 構成を設定する例を次に示します。

all:
  vars:
    kerberos_configure: true
    kerberos:
      realm: example.com
      kdc_hostname: ip-192-24-45-82.us-west.compute.internal
      admin_hostname: ip-192-24-45-82.us-west.compute.internal

インベントリ内の各ホストでは、Kerberos プリンシパルと、Ansible コントローラー上のキータブの場所を定義する変数も設定する必要があります。hosts.yml の内容は以下のようになります。

zookeeper:
  hosts:
    ip-192-24-34-224.us-west.compute.internal:
      zookeeper_kerberos_keytab_path: /tmp/keytabs/zookeeper-ip-192-24-34-224.us-west.compute.internal.keytab
      zookeeper_kerberos_principal: zookeeper/ip-192-24-34-224.us-west.compute.internal@REALM.EXAMPLE.COM
    ip-192-24-37-15.us-west.compute.internal:
      zookeeper_kerberos_keytab_path: /tmp/keytabs/zookeeper-ip-192-24-34-224.us-west.compute.internal.keytab
      zookeeper_kerberos_principal: zookeeper/ip-192-24-34-224.us-west.compute.internal@REALM.EXAMPLE.COM
    ip-192-24-34-224.us-west.compute.internal:
      zookeeper_kerberos_keytab_path: /tmp/keytabs/zookeeper-ip-192-24-34-224.us-west.compute.internal.keytab
      zookeeper_kerberos_principal: zookeeper/ip-192-24-34-224.us-west.compute.internal@REALM.EXAMPLE.COM

kafka_broker:
  hosts:
    ip-192-24-34-224.us-west.compute.internal:
      kafka_broker_kerberos_keytab_path: /tmp/keytabs/kafka-ip-192-24-34-224.us-west.compute.internal.keytab
      kafka_broker_kerberos_principal: kafka/ip-192-24-34-224.us-west.compute.internal@REALM.EXAMPLE.COM
    ip-192-24-37-15.us-west.compute.internal:
      kafka_broker_kerberos_keytab_path: /tmp/keytabs/kafka-ip-192-24-34-224.us-west.compute.internal.keytab
      kafka_broker_kerberos_principal: kafka/ip-192-24-34-224.us-west.compute.internal@REALM.EXAMPLE.COM
    ip-192-24-34-224.us-west.compute.internal:
      kafka_broker_kerberos_keytab_path: /tmp/keytabs/kafka-ip-192-24-34-224.us-west.compute.internal.keytab
      kafka_broker_kerberos_principal: kafka/ip-192-24-34-224.us-west.compute.internal@REALM.EXAMPLE.COM

schema_registry:
  hosts:
    ip-192-24-34-224.us-west.compute.internal:
      schema_registry_kerberos_keytab_path: /tmp/keytabs/schemaregistry-ip-192-24-34-224.us-west.compute.internal.keytab
      schema_registry_kerberos_principal: schemaregistry/ip-192-24-34-224.us-west.compute.internal@REALM.EXAMPLE.COM

kafka_connect:
  hosts:
    ip-192-24-34-224.us-west.compute.internal:
      kafka_connect_kerberos_keytab_path: /tmp/keytabs/connect-ip-192-24-34-224.us-west.compute.internal.keytab
      kafka_connect_kerberos_principal: connect/ip-192-24-34-224.us-west.compute.internal@REALM.EXAMPLE.COM

kafka_rest:
  hosts:
    ip-192-24-34-224.us-west.compute.internal:
      kafka_rest_kerberos_keytab_path: /tmp/keytabs/restproxy-ip-192-24-34-224.us-west.compute.internal.keytab
      kafka_rest_kerberos_principal: restproxy/ip-192-24-34-224.us-west.compute.internal@REALM.EXAMPLE.COM

ksql:
  hosts:
    ip-192-24-34-224.us-west.compute.internal:
      ksql_kerberos_keytab_path: /tmp/keytabs/ksql-ip-192-24-34-224.us-west.compute.internal.keytab
      ksql_kerberos_principal: ksql/ip-192-24-34-224.us-west.compute.internal@REALM.EXAMPLE.COM

control_center:
  hosts:
    ip-192-24-34-224.us-west.compute.internal:
      control_center_kerberos_keytab_path: /tmp/keytabs/controlcenter-ip-192-24-34-224.us-west.compute.internal.keytab
      control_center_kerberos_principal: controlcenter/ip-192-24-34-224.us-west.compute.internal@REALM.EXAMPLE.COM

mTLS 認証の構成¶

相互 TLS（mTLS）認証を構成するには、TLS 暗号化を有効にする必要があります。

hosts.yml ファイルに以下のパラメーターを設定します。

all:
  vars:
    ssl_enabled: true
    ssl_mutual_auth_enabled: true

ZooKeeper での認証¶

Ansible Playbooks for Confluent Platform では、ZooKeeper のサーバー/サーバー認証およびクライアント/サーバー認証の構成がサポートされています。Kafka は ZooKeeper クライアントとして動作します。

デフォルトのインストールでは、ZooKeeper に認証は設定されません。

サーバー/サーバー認証¶

Ansible Playbooks for Confluent Platform では、以下の ZooKeeper サーバー/サーバー認証モードがサポートされています。

DIGEST-MD5 を利用した SASL: ユーザーのパスワードのハッシュ値を認証に使用します。
mTLS: Kafka とクライアント間における双方向のトラフィックのセキュリティと信頼度を保証します。

デフォルトのインストールでは、ZooKeeper に認証は設定されません。

SASL DIGEST-MD5 認証の構成¶

ZooKeeper で DIGEST-MD5 を利用した SASL 認証を有効にするには、hosts.yml ファイルに次の変数を設定します。

all:
  vars:
    zookeeper_quorum_authentication_type: digest

mTLS 認証の構成¶

ZooKeeper で mTLS 認証を有効にするには、hosts.yml ファイルに次の変数を設定します。

all:
  vars:
    zookeeper_quorum_authentication_type: mtls

クライアント/サーバー認証¶

Ansible Playbooks for Confluent Platform では、以下の ZooKeeper クライアント/サーバー認証モードがサポートされています。

DIGEST-MD5 を利用した SASL: ユーザーのパスワードのハッシュ値を認証に使用します。
SASL GSSAPI（Kerberos）: Kerberos または Active Directory サーバーを認証に使用します。
mTLS: Kafka とクライアント間における双方向のトラフィックのセキュリティと信頼度を保証します。

SASL DIGEST-MD5 認証の構成¶

ZooKeeper で DIGEST-MD5 を利用した SASL 認証を有効にするには、hosts.yml ファイルに次の変数を設定します。

all:
  vars:
    zookeeper_client_authentication_type: digest

SASL GSSAPI（Kerberos）認証の構成¶

ZooKeeper で DIGEST-MD5 を利用した SASL 認証を有効にするには、hosts.yml ファイルに次の変数を設定します。

all:
  vars:
    zookeeper_client_authentication_type: kerberos

各ホストについて、以下の変数も指定する必要があります。

zookeeper_kerberos_principal: "zk/{{inventory_hostname}}.confluent@{{kerberos.realm | upper}}"
zookeeper_kerberos_keytab_path: "roles/confluent.test/molecule/{{scenario_name}}/keytabs/zookeeper-{{inventory_hostname}}.keytab"

mTLS 認証の構成¶

ZooKeeper で mTLS 認証を有効にするには、hosts.yml ファイルに次の変数を設定します。

all:
  vars:
    zookeeper_client_authentication_type: mtls

コンポーネントでの認証¶

Ansible Playbooks for Confluent Platform では、Confluent Platform の他のコンポーネント用に mTLS 認証および基本認証を使用できます。

デフォルトのインストールでは、Confluent Platform コンポーネントに認証は設定されません。

mTLS 認証の構成¶

すべてのコンポーネントで mTLS を有効にするには、hosts.yml ファイルに次のパラメーターを設定します。

all:
  vars:
    ssl_enabled: true
    kafka_broker_rest_proxy_authentication_type: mtls
    schema_registry_authentication_type: mtls
    kafka_connect_authentication_type: mtls
    kafka_rest_authentication_type: mtls
    ksql_authentication_type: mtls
    control_center_authentication_type: mtls

基本認証の構成¶

コンポーネントで基本認証を有効にするには、hosts.yml ファイルに次のパラメーターを設定します。

all:
  vars:
    kafka_broker_rest_proxy_authentication_type: basic
    schema_registry_authentication_type: basic
    kafka_connect_authentication_type: basic
    kafka_rest_authentication_type: basic
    ksql_authentication_type: basic
    control_center_authentication_type: basic

Ansible Playbook を使用した Confluent Platform での認証の構成¶

Kafka での認証¶

SASL PLAIN 認証の構成¶

SASL SCRAM（SHA-512）認証の構成¶

SASL SCRAM（SHA-256）認証の構成¶

SASL GSSAPI（Kerberos）認証の構成¶

mTLS 認証の構成¶

ZooKeeper での認証¶

サーバー/サーバー認証¶

SASL DIGEST-MD5 認証の構成¶

mTLS 認証の構成¶

クライアント/サーバー認証¶

SASL DIGEST-MD5 認証の構成¶

SASL GSSAPI（Kerberos）認証の構成¶

mTLS 認証の構成¶

コンポーネントでの認証¶

mTLS 認証の構成¶

基本認証の構成¶

次のステップ¶