1. Home
2. Confluent for Kubernetes
3. Confluent Platform の構成
4. Confluent for Kubernetes でのセキュリティの構成

Confluent for Kubernetes を使用した認証の構成

デフォルトでは、Confluent Platform コンポーネントで認証は構成されません。このドキュメントでは、サポートされている認証の概念を紹介するとともに、Confluent for Kubernetes （CFK）を使用して Confluent Platform の認証を構成する方法について説明します。

Confluent Platform におけるセキュリティの概念の詳細については、「セキュリティ」を参照してください。

認証の構成に関する包括的なチュートリアルシナリオについては、「Deploy Secure Confluent Platform」を参照してください。

認証の概要

Kafka をはじめとする Confluent コンポーネントに接続するユーザーとアプリケーションの ID は認証によって検証されます。

Kafka にアクセスするための認証

Kafka にアクセスするクライアントアプリケーションと Confluent Platform コンポーネントについて、CFK は次の認証メカニズムをサポートしています。

• SASL/PLAIN 認証: クライアントの認証にはユーザー名とパスワードが使用されます。ユーザー名とパスワードは、サーバー側で Kubernetes シークレットとして格納されます。
• mTLS 認証: クライアントの認証には TLS 証明書が使用されます。証明書には、クライアントアプリケーションのプリンシパル名を識別する CN が含まれています。

ZooKeeper にアクセスするための認証

ZooKeeper にアクセスする Kafka について、CFK は次の認証メカニズムをサポートしています。

• ダイジェスト認証
• mTLS 認証

Confluent Platform コンポーネントにアクセスするための認証

Connect、ksqlDB、Schema Registry、Confluent Control Center の各コンポーネントについて、CFK は次の認証メカニズムをサポートします。

• 基本認証: 認証にはユーザー名とパスワードが使用されます。ユーザー名とパスワードは Kubernetes シークレットとして格納されます。
• mTLS 認証: クライアントの認証には TLS 証明書が使用されます。
• LDAP 認証（Confluent Control Center のみ）: ユーザープリンシパルとパスワードの認証情報が LDAP サーバーに格納されます。

MDS にアクセスするための認証

Metadata Service (MDS) にアクセスするクライアントアプリケーションと Confluent Platform コンポーネントについて、CFK は次の認証メカニズムをサポートしています。

• ベアラー認証

Kafka にアクセスするための認証の構成

SASL/PLAIN 認証

SASL/PLAIN は、ユーザー名とパスワードによるシンプルなメカニズムで、セキュアな認証を実装するために、一般には TLS ネットワーク暗号化を併用します。

ユーザー名は認証されたプリンシパルとして使用され、このプリンシパルが認可に使用されます。

Kafka の認証メカニズムとしての SASL/PLAIN の構成

認証メカニズムとして SASL/PLAIN を使用するように、Kafka カスタムリソース（CR）で次のように Kafka リスナーを構成します。

spec:
  ...
  listeners:
    external:
      authentication:
        type: plain                 --- [1]
        jaasConfig:                 --- [2]
          secretRef:                --- [3]
        jaasConfigPassThrough:      --- [4]
          secretRef:                --- [5]
          directoryPathInContainer: --- [6]

• [1]（必須） plain に設定します。

• [3]、[5]、[6] のいずれかが必須となります。

• [2] jaasConfig を使用する場合は、ユーザー名とパスワードを指定します。後は CFK が自動的に構成します。たとえば、ユーザーを追加、削除、アップデートすると、CFK が自動的に JAAS 構成をアップデートします。Kafka に SASL/PLAIN を構成する場合は、この方法を推奨します。

  • [3] 一連のユーザー名とパスワードを含んだ Kubernetes シークレットを指定します。

    想定されるキー（ファイル名）は plain-users.json です。

    キーの値（ファイルのデータ）は、次のようになります。

    {
    "username1": "password1",
    "username2": "password2",
    "username3": "password3"
    }
    

• [4] JAAS を構成する別の方法として、jaasConfigPassThrough を使用します。カスタムのログインハンドラーを使用するなど、カスタマイズが必要な場合は、CFK による自動構成を使用せずに構成を直接指定することができます。

  • [5] 想定されるキーとその値を含んだ Kubernetes シークレットを指定します。

    想定されるキー（ファイル名）は plain-jaas.conf です。

    キーの想定される値（ファイルのデータ）は、JAAS 構成テキストです。JAAS 構成については、こちらの Confluent Platform ドキュメント を参照してください。次の例では、標準的なログインモジュールを使用し、2 人の追加ユーザーを指定しています。

    sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
       username="admin" \
       password="admin-secret" \
       user_admin="admin-secret" \
       user_user1="user1-secret" \
       user_user2=”user2-secret”;
    

  • [6] 必要な認証情報をコンテナー内のディレクトリパスから指定します。

    想定されるキー（ファイル名）は plain-jaas.conf です。jaasConfigPassThrough.directoryPathInContainer に /vaults/secrets が構成されている場合、想定されるファイル（plain-jaas.conf）はそのディレクトリパスにあります。

    次の例では、想定されるキーの値（ファイルのデータ）に標準的なログインモジュールを使用し、2 人の追加ユーザーを指定しています。

    sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
       username="admin" \
       password="admin-secret" \
       user_admin="admin-secret" \
       user_user1="user1-secret" \
       user_user2=”user2-secret”;
    

    Vault での directoryPathInContainer プロパティの使用について詳しくは、GitHub の CFK サンプル を参照してください。

Kafka に対する認証を SASL/PLAIN で行う Confluent コンポーネントの構成

Kafka と通信を行う Confluent コンポーネントごとに、コンポーネントの CR で次のように SALS/PLAIN 認証を構成します。

spec:
  ...
  dependencies:
    kafka:
      authentication:
        type: plain                 --- [1]
        jaasConfig:                 --- [2]
          secretRef:                --- [3]
        jaasConfigPassThrough:      --- [4]
          secretRef:                --- [5]
          directoryPathInContainer: --- [6]

• [1]（必須） plain に設定します。

• [2]、[3]、[4] のいずれかが必須となります。

• [2] jaasConfig を使用する場合は、ユーザー名とパスワードを指定します。後は CFK が自動的に構成します。たとえば、ユーザーを追加、削除、アップデートすると、CFK が自動的に JAAS 構成をアップデートします。

  • [3] Kafka に対する認証用のユーザー名とパスワードを含んだ Kubernetes シークレットを指定します。

    想定されるキー（ファイル名）は plain.txt です。

    想定されるキーの値（ファイルのデータ）は、次のようになります。

    username=<username>
    password=<password>
    

• [4] JAAS を構成する別の方法として、jaasConfigPassThrough を使用します。カスタムのログインハンドラーを使用するなど、カスタマイズが必要な場合は、CFK による自動構成を使用せずに構成を直接指定することができます。

  • [5] 想定されるキーとその値を含んだ Kubernetes シークレットを指定します。

    想定されるキー（ファイル名）は plain-jaas.conf です。

    キーの想定される値（ファイルのデータ）は、JAAS 構成テキストです。JAAS 構成については、こちらの Confluent Platform ドキュメント を参照してください。次の例では、標準的なログインモジュールを使用し、2 人の追加ユーザーを指定しています。

    sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
       username="admin" \
       password="admin-secret" \
       user_admin="admin-secret" \
       user_user1="user1-secret" \
       user_user2="user2-secret";
    

  • [6] 必要な認証情報をコンテナー内のディレクトリパスから指定します。

    想定されるキー（ファイル名）は plain-jaas.conf です。

    jaasConfigPassThrough.directoryPathInContainer に /vaults/secrets が構成されている場合、想定されるファイル（plain-jaas.conf）はそのディレクトリパスにあります。次の例では、想定されるキーの値（ファイルのデータ）に標準的なログインモジュールを使用し、2 人の追加ユーザーを指定しています。

    sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
       username="admin" \
       password="admin-secret" \
       user_admin="admin-secret" \
       user_user1="user1-secret" \
       user_user2="user2-secret";
    

    Vault での directoryPathInContainer プロパティの使用について詳しくは、GitHub の CFK サンプル を参照してください。

mTLS 認証

Kafka の認証メカニズムとしての mTLS の構成

mTLS では、認証メカニズムとして TLS 証明書が利用されます。この証明書によって ID が示されます。

証明書の CN（Common Name: 一般名）は認証されたプリンシパルとして使用され、このプリンシパルが認可に使用されます。

認証メカニズムとして mTLS を使用するには、次のように Kafka リスナーを Kafka の CR で構成します。

spec:
  ...
  listeners:
    external:
      authentication:
        type: mtls                                     --- [1]
        principalMappingRules:
        - RULE:.*CN[\s]?=[\s]?([a-zA-Z0-9.]*)?.*/$1/   --- [2]
      tls:
        enabled: true                                  --- [3]

• [1]（必須） mTLS に設定します。

• [2]（省略可）証明書の CN（Common Name: 一般名）からプリンシパル名を抽出するマッピングルールを指定します。

  マッピングルールに使用される正規表現（regex）は Java マッピング API です。正規表現の検証には、「Regular Expression Test Drive」などのサイトを使用できます。

• [3]（mTLS 認証では必須） true に設定します。

Kafka に対する認証を mTLS で行う Confluent コンポーネントの構成

Kafka と通信を行う Confluent コンポーネントごとに、コンポーネントの CR で次のように mTLS 認証メカニズムを構成します。

spec:
  ...
  dependencies:
    kafka:
      authentication:
        type: mtls               --- [1]
      tls:
        enabled: true            --- [2]

• [1]（必須） mtls に設定します。
• [2]（mTLS 認証では必須） true に設定します。

ZooKeeper にアクセスするための認証の構成

SASL/DIGEST 認証

ZooKeeper の認証としての DIGEST の構成

ZooKeeper は、SASL DIGEST-MD5 メカニズムを使用した認証をサポートします。

ZooKeeper の CR で、次のように DIGEST 認証を有効にします。

spec:
  ...
  authentication:
    type: digest                 --- [1]
    jaasConfig:                  --- [2]
      secretRef:                 --- [3]
    jaasConfigPassThrough:       --- [4]
      secretRef:                 --- [5]
      directoryPathInContainer:  --- [6]

• [1]（必須） digest に設定します。

• [2]、[3]、[4] のいずれかが必須となります。

• [2] jaasConfig を使用する場合は、ユーザー名とパスワードを指定します。後は CFK が自動的に構成します。たとえば、ユーザーを追加、削除、アップデートすると、CFK が自動的に JAAS 構成をアップデートします。ZooKeeper に SASL/DIGEST を構成する場合は、この方法を推奨します。

  • [3] ユーザー名とパスワードを含んだ Kubernetes シークレットを指定します。

    想定されるキー（ファイル名）は digest-users.json です。

    想定されるキーの値（ファイルのデータ）は、次のようになります。

    {
    "username1": "password1",
    "username2": "password2"
    }
    

• [4] JAAS を構成する別の方法として、jaasConfigPassThrough を使用します。カスタムのログインハンドラーを使用するなど、カスタマイズが必要な場合は、CFK による自動構成を使用せずに構成を直接指定することができます。

  • [5] 想定されるキーとその値を含んだ Kubernetes シークレットを指定します。想定されるキー（ファイル名）は digest-jaas.conf です。想定されるキーの値（ファイルのデータ）は、次のようになります。

    Server {
      org.apache.zookeeper.server.auth.DigestLoginModule required
        user_super="adminsecret"
        user_user1="user1-secret";
     };
    

  • [6] 必要な認証情報をコンテナー内のディレクトリパスから指定します。想定されるキー（ファイル名）は digest-jaas.conf です。

    jaasConfigPassThrough.directoryPathInContainer に /vaults/secrets が構成されている場合、想定されるファイル（digest-jaas.conf）はそのディレクトリパスにあります。次の例では、想定されるキーの値（ファイルのデータ）に標準的なログインモジュールを使用し、1 人の追加ユーザーを指定しています。

    Server {
      org.apache.zookeeper.server.auth.DigestLoginModule required
        user_super="adminsecret"
        user_bob="bob-secret";
    };
    

    Vault での directoryPathInContainer プロパティの使用について詳しくは、GitHub の CFK サンプル を参照してください。

ZooKeeper に対する認証にダイジェストを使用するための Kafka の構成

ZooKeeper に対する Kafka の認証にダイジェスト認証を使用するためには、Kafka の CR を次のように構成します。

spec:
  ...
  dependencies:
    zookeeper:
      authentication:
        type: digest                --- [1]
        jaasConfig:                 --- [2]
          secretRef:                --- [3]
        jaasConfigPassThrough:      --- [4]
          secretRef:                --- [5]
          directoryPathInContainer: --- [6]

• [1]（必須） digest に設定します。

• [2]、[3]、[4] のいずれかが必須となります。

• [2] jaasConfig を使用する場合は、ユーザー名とパスワードを指定します。後は CFK が自動的に構成します。たとえば、ユーザーを追加、削除、アップデートすると、CFK が自動的に JAAS 構成をアップデートします。ZooKeeper に SASL/DIGEST を構成する場合は、この方法を推奨します。

  • [3] ZooKeeper に対する認証用のユーザー名とパスワードを含んだ Kubernetes シークレットを指定します。

    想定されるキー（ファイル名）は digest.txt です。

    キーの値（ファイルのデータ）は、次のようになります。ユーザー名とパスワードの前後には二重引用符が必要となります。

    username="<username>"
    password="<password>"
    

• [4] JAAS を構成する別の方法として、jaasConfigPassThrough を使用します。カスタムのログインハンドラーを使用するなど、カスタマイズが必要な場合は、CFK による自動構成を使用せずに構成を直接指定することができます。

  • [5] 想定されるキーとその値を含んだ Kubernetes シークレットを指定します。

    想定されるキーとファイル名は digest-jaas.conf です。

    以下では、例として、digest-jaas.conf の値（ファイルのデータ）に標準のログインモジュールと 1 人のユーザーを使用しています。想定されるキーの値（ファイルのデータ）は、次のようになります。

    Client { //zookeeper dependencies
        org.apache.zookeeper.server.auth.DigestLoginModule required
        username="bob"
        password="password";
    };
    

    Vault での directoryPathInContainer プロパティの使用について詳しくは、GitHub の CFK サンプル を参照してください。

mTLS 認証

ZooKeeper 認証としての mTLS の構成

ZooKeeper の CR で、次のように mTLS 認証を有効にします。

spec:
  ...
  authentication:
    type: mtls

ZooKeeper に対する認証に mTLS を使用するための Kafka の構成

ZooKeeper に対する Kafka の認証に mTLS 認証を使用するためには、Kafka の CR を次のように構成します。

spec:
  ...
  dependencies:
    zookeeper:
      authentication:
        type: mtls               --- [1]
      tls:
        enabled: true            --- [2]

• [1]（必須） mtls に設定します。
• [2]（mTLS 認証では必須） true に設定します。

Confluent Platform コンポーネントにアクセスするための認証の構成

基本認証

Confluent Platform コンポーネントの基本認証の構成

認証情報は、<username>: <password>, <role that user is assigned to> という形式でサーバー側に格納されます。

デフォルトでは次のロールがサポートされます。

• ksqlDB: admin、developer、user、ksql-user の各ロールが利用できます。
• Schema Registry: admin、developer、user、sr-user の各ロールが利用できます。
• Confluent Control Center: Administrators ロールと Restricted ロールが利用できます。

警告

Connect については、ロールがサポートされません。

基本認証は、コンポーネントの CR で次のように構成します。

spec:
  ...
  authentication:
    type: basic                  --- [1]
    basic:
      secretRef:                 --- [2]
      directoryPathInContainer:  --- [3]
      restrictedRoles:           --- [4]
      roles:                     --- [5]

• [1]（必須） basic に設定します。

• [2] または [3]（必須）

• [2] ユーザー名とパスワードを含んだ Kubernetes シークレットを指定します。

  想定されるキーは basic.txt です。

  キーの値は次のとおりです。

  username1: password1,role1
  username2: password2,role2
  

• [3] 基本認証に必要な認証情報を指定します。Vault での directoryPathInContainer プロパティの使用について詳しくは、GitHub の CFK サンプル を参照してください。

• [4]（省略可）|c3| におけるサーバー上の限定ロールのリストです。

• [5]（省略可）サーバー側のロールのリストです。

他の Confluent Platform コンポーネントに対する認証を基本認証で行う Confluent コンポーネントの構成

基本認証に使用されるユーザー名とパスワードは、secretRef または directoryPathInContainer を通じて読み込まれます。

警告

Confluent Control Center は、基本認証を使用した Connect と ksqlDB への接続をサポートしません。

基本認証は、コンポーネントの CR で次のように有効にします。<component> は、このコンポーネントの認証の対象となる Confluent Platform コンポーネントです。

spec:
  ...
  dependencies:
    <component>:
      url:
      authentication:
        type: basic              --- [1]
        basic:
          secretRef:             --- [2]

• [1]（必須） basic に設定します。

• [2]（必須）

  ユーザー名とパスワードは secretRef を通じて読み込まれます。

  想定されるキーは basic.txt です。

  キーの値は次のとおりです。

  username=<username>
  password=<password>
  

mTLS 認証

Confluent Platform コンポーネントの mTLS 認証の構成

mTLS 認証は、コンポーネントの CR で次のように構成します。

spec:
  ...
  authentication:
    type: mtls                --- [1]

• [1]（必須） mtls に設定します。

他の Confluent Platform コンポーネントに対する認証を mTLS 認証で行う Confluent コンポーネントの構成

mTLS 認証は、コンポーネントの CR で次のようにして有効にします。<component> は、このコンポーネントの認証の対象となる Confluent Platform コンポーネントです。

spec:
  ...
  dependencies:
    <component>:
      url:
      authentication:
        type: mtls               --- [1]
      tls:
        enabled: true            --- [2]

• [1]（必須） mtls に設定します。
• [2]（mTLS 認証では必須） true に設定します。

Confluent Control Center の LDAP 認証

基本認証方式と mTLS 認証方式に加え、Confluent Control Center では認証方式として LDAP がサポートされます。

ユーザーとグループを LDAP サーバーから取得するように Confluent Control Center の CR を構成できます。

kind: ControlCenter
spec:
  authentication:
    type: ldap                                       --- [1]
    ldap:
      secretRef:                                     --- [2]
      roles:                                         --- [3]
      restrictedRoles:                               --- [4]
      property:                                      --- [5]
        #  useLdaps: "true"
        #  contextFactory: "com.sun.jndi.ldap.LdapCtxFactory"
        #  hostname: ""
        #  port: "389"
        #  bindDn: ""
        #  bindPassword: ""
        #  authenticationMethod: ""
        #  forceBindingLogin: "true"
        #  userBaseDn: ""
        #  userRdnAttribute: "sAMAccountName"
        #  userIdAttribute: "sAMAccountName"
        #  userPasswordAttribute: "userPassword"
        #  userObjectClass: "user"
        #  roleBaseDn: ""
        #  roleNameAttribute: "cn"
        #  roleMemberAttribute: "member"
        #  roleObjectClass: "group"

• [1]（必須） ldap に設定します。

• [2] LDAP の認証情報のシークレットです。

  想定されるキーは ldap.txt です。

  キーの値は次のとおりです。

  username=<username>
  password=<password>
  

• [3]（省略可）デフォルトでは、["Administrators", "Restricted"] に設定されます。

• [4]（省略可）アクセスが読み取り専用に制限されているロールのリストです。Control Center での編集や作成は許可されません。

• [5]（必須）詳細については、「LdapLoginModule の構成」を参照してください。

MDS にアクセスするための認証の構成

ベアラー認証

MDS と通信を行う Confluent コンポーネントごとに、コンポーネントの CR で次のようにベアラー認証メカニズムを構成します。

spec:
  dependencies:
    mds:
      authentication:
        type: bearer               --- [1]
        bearer:
          secretRef:               --- [2]

• [1]（必須） bearer に設定します。

• [2]（必須）

  ユーザー名とパスワードは secretRef を通じて読み込まれます。

  想定されるキーは bearer.txt です。

  キーの値は次のとおりです。

  username=<username>
  password=<password>
  

RBAC が有効になっている場合（spec.authorization.type: rbac）、CFK は常に Confluent コンポーネントにベアラー認証を使用し、spec.authentication 設定を無視します。RBAC が有効になっている状態でコンポーネントの認証タイプを mTLS に設定することはできません。