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]
Copy

[1]（必須）``plain`` に設定します。
[3]、[5]、[6] のいずれかが必須となります。
[2] jaasConfig を使用する場合は、ユーザー名とパスワードを指定します。後は CFK が自動的に構成します。たとえば、ユーザーを追加、削除、アップデートすると、CFK が自動的に JAAS 構成をアップデートします。Kafka に SASL/PLAIN を構成する場合は、この方法を推奨します。
- [3] 一連のユーザー名とパスワードを含んだ Kubernetes シークレットを指定します。
  
  想定されるキー（ファイル名）は plain-users.json です。
  
  キーの値（ファイルのデータ）は、次のようになります。
```
{
"username1": "password1",
"username2": "password2",
"username3": "password3"
}
```
  Copy
[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”;
```
  Copy
- [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”;
```
  Copy
  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]
Copy

[1]（必須）``plain`` に設定します。
[2] と [4] のいずれかが必須です。
[2] jaasConfig を使用する場合は、ユーザー名とパスワードを指定します。後は CFK が自動的に構成します。たとえば、ユーザーを追加、削除、アップデートすると、CFK が自動的に JAAS 構成をアップデートします。
- [3] Kafka に対する認証用のユーザー名とパスワードを含んだ Kubernetes シークレットを指定します。
  
  想定されるキー（ファイル名）は plain.txt です。
  
  想定されるキーの値（ファイルのデータ）は、次のようになります。
```
username=<username>
password=<password>
```
  Copy
[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";
```
  Copy
- [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";
```
  Copy
  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]
Copy

[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]
Copy

[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]
Copy

[1]（必須）``digest`` に設定します。
[2]、[3]、[4] のいずれかが必須となります。
[2] jaasConfig を使用する場合は、ユーザー名とパスワードを指定します。後は CFK が自動的に構成します。たとえば、ユーザーを追加、削除、アップデートすると、CFK が自動的に JAAS 構成をアップデートします。ZooKeeper に SASL/DIGEST を構成する場合は、この方法を推奨します。
- [3] ユーザー名とパスワードを含んだ Kubernetes シークレットを指定します。
  
  想定されるキー（ファイル名）は digest-users.json です。
  
  想定されるキーの値（ファイルのデータ）は、次のようになります。
```
{
"username1": "password1",
"username2": "password2"
}
```
  Copy
[4] JAAS を構成するには、jaasConfigPassThrough を使用する方法もあります。カスタムのログインハンドラーを使用するなど、カスタマイズが必要な場合は、CFK による自動構成を使用せずに構成を直接指定することができます。
- [5] 想定されるキーとその値を含んだ Kubernetes シークレットを指定します。想定されるキー（ファイル名）は digest-jaas.conf です。想定されるキーの値（ファイルのデータ）は、次のようになります。
```
Server {
  org.apache.zookeeper.server.auth.DigestLoginModule required
    user_super="adminsecret"
    user_user1="user1-secret";
 };
```
  Copy
- [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";
};
```
  Copy
  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]
Copy

[1]（必須）``digest`` に設定します。
[2]、[3]、[4] のいずれかが必須となります。
[2] jaasConfig を使用する場合は、ユーザー名とパスワードを指定します。後は CFK が自動的に構成します。たとえば、ユーザーを追加、削除、アップデートすると、CFK が自動的に JAAS 構成をアップデートします。ZooKeeper に SASL/DIGEST を構成する場合は、この方法を推奨します。
- [3] ZooKeeper に対する認証用のユーザー名とパスワードを含んだ Kubernetes シークレットを指定します。
  
  想定されるキー（ファイル名）は digest.txt です。
  
  キーの値（ファイルのデータ）は、次のようになります。ユーザー名とパスワードの前後には二重引用符が必要となります。
```
username="<username>"
password="<password>"
```
  Copy
[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";
};
```
  Copy
  Vault での directoryPathInContainer プロパティの使用について詳しくは、GitHub の CFK サンプルを参照してください。

mTLS 認証¶

ZooKeeper 認証としての mTLS の構成¶

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

spec:
  ...
  authentication:
    type: mtls
Copy

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

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

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

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

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

基本認証¶

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

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

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

REST Proxy: admin、developer、user、krp-user の各ロールを使用できます。
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]
Copy

[1]（必須）``basic`` に設定します。
[2] または [3]（必須）
[2] ユーザー名とパスワードを含んだ Kubernetes シークレットを指定します。

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

キーの値は次のとおりです。
```
username1: password1,role1
username2: password2,role2
```
Copy
[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]
Copy

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

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

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

キーの値は次のとおりです。
```
username=<username>
password=<password>
```
Copy

mTLS 認証¶

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

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

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

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

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

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

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

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

Confluent Control Center の LDAP 認証¶

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

ユーザーとグループを LDAP サーバーから取得するように 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"
Copy

[1]（必須）``ldap`` に設定します。
[2] LDAP の認証情報のシークレットです。

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

キーの値は次のとおりです。
```
username=<bindDn_value>
password=<bindPassword_value>
```
Copy
セキュリティに懸念がある場合は、CR で bindDn と bindPassword に空の値を渡します。CFK がそれらの値を置き換え、適切なものとして追加します。

bindDn のパスワードでは、制限されているすべての LDAP 文字をエスケープします。最適な結果を得るために、エスケープが必要な文字を使用しないことをお勧めします。LDAP 命名属性のベストプラクティスに従ってください。
[3]（省略可）デフォルトでは、["Administrators", "Restricted"] に設定されます。
[4]（省略可）アクセスが読み取り専用に制限されているロールのリストです。Control Center での編集や作成は許可されません。
[5]（必須）詳細については、「LdapLoginModule の構成」を参照してください。

Confluent Control Center の LDAP over SSL 認証¶

LDAP over SSL（LDAPS）を使用して Control Center の暗号化と認証を構成する場合、configOverrides 機能を使用して LDAPS のトラストストアを JVM にエクスポートする必要があります。

この要件は、Control Center が外部の MDS を使用して認証を行う RBAC が有効な環境には適用されません。

次のように、Confluent Control Center の CR で JVM のトラストストアに LDAP SSL 証明書を追加します。

spec:
  configOverrides:
    jvm:
      -Djavax.net.ssl.trustStore=<path to truststore.jks>
      -Djavax.net.ssl.trustStorePassword=<password for the truststore>
Copy

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

ベアラー認証¶

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

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

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

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

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

キーの値は次のとおりです。
```
username=<username>
password=<password>
```
Copy

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