LDAP 認証用にフリートメンバークラスタを設定する

このドキュメントでは、クラスタ管理者やアプリケーションオペレーターを対象に、Microsoft Entra ID や Google LDAP などのサードパーティの Lightweight Directory Access Protocol（LDAP）プロバイダからの認証をサポートするように Kubernetes クラスタを構成する方法について説明します。詳細については、サードパーティの ID を使用した認証についてをご覧ください。

制限事項

LDAP をサポートするクラスタタイプを使用する必要があります。

始める前に

Install the Google Cloud CLI.
外部 ID プロバイダ（IdP）を使用している場合は、まず連携 ID を使用して gcloud CLI にログインする必要があります。
gcloud CLI を初期化するには、次のコマンドを実行します。
```
gcloud init
```
gcloud CLI を初期化した後に更新して、必要なコンポーネントをインストールします。
```
gcloud components update
gcloud components install kubectl
```
必要なすべてのプロバイダ情報がプラットフォーム管理者から提供されていることを確認します。詳細については、クラスタ認証用に LDAP プロバイダを構成するをご覧ください。

この設定を実施している途中で、LDAP サーバーのドキュメントの参照が必要になることがあります。管理者向けの次のガイドには、広く利用されている一部の LDAP プロバイダの構成が説明されています。たとえば、LDAP サーバーへのログインとクラスタの構成に必要な情報を得る方法などが記載されています。

LDAP サービスアカウントの Secret を登録する

クラスタが LDAP サーバーを認証してユーザーの詳細情報を取得するには、サービスアカウントの Secret が必要です。LDAP 認証は次のメカニズムをサポートしています。

ユーザー名とパスワードを使用する基本認証。
クライアント秘密鍵とクライアント証明書を使用するクライアント証明書認証。

お客様またはプラットフォーム管理者は、クラスタ認証用に LDAP プロバイダを構成するの手順に沿って、プロバイダに関するこの情報を取得している必要があります。クラスタで LDAP サーバーのログイン情報を使用できるようにするには、LDAP ログインの詳細を含む Kubernetes Secret を作成する必要があります。次の例は、両方の認証タイプの Secret を構成する方法を示しています。この例では、Secret を anthos-identity-service Namespace に適用しています。

基本認証の Secret 構成は、次のようになります。

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: "anthos-identity-service"
type: kubernetes.io/basic-auth     # Make sure the type is correct
data:
  username: USERNAME  # Use a base64-encoded username
  password: PASSWORD  # Use a base64-encoded password

ここで、SERVICE_ACCOUNT_SECRET_NAME は、この Secret に付けた名前です。 username と password の値は、前のステップで取得したユーザー名とパスワードに置き換えます。USERNAME は Base64 でエンコードされたユーザー名です。PASSWORD は Base64 でエンコードされたパスワードです。

クライアント証明書の Secret 構成は、次のようになります。

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: anthos-identity-service
type: kubernetes.io/tls            # Make sure the type is correct
data:
  # the data is abbreviated in this example
  tls.crt: |
       MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
  tls.key: |
       MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...

SERVICE_ACCOUNT_SECRET_NAME は、この Secret に付けた名前に置き換えます。TLS 証明書と鍵の値は、前のステップで取得してエンコードした証明書と鍵の値に置き換えます。

この例では、Secret を anthos-identity-service Namespace に適用しています。システムコンポーネントには、この Namespace の Secret を読み取る権限がデフォルトで付与されています。別の Namespace を使用する場合は、次のように、Secret のメタデータを変更してから、新しい RBAC ポリシーを追加して、その Namespace の Secret を読み取る権限を anthos-identity-service Namespace の default ServiceAccount に付与します。

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: NAMESPACE
  name: ais-secret-reader-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ais-secret-reader-role-binding
  namespace: NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ais-secret-reader-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: anthos-identity-service
---

クラスタを構成する

LDAP を使用してクラスタへの認証を構成するには、ClientConfig という名前の Kubernetes カスタムリソースに次の情報を追加します。

ID プロバイダに関する情報と、ユーザー情報を返すために必要なパラメータ。
前のセクションで作成して適用した Secret の名前と Namespace。これにより、クラスタで LDAP サーバーに対する認証を行えるようになります。

クラスタを構成するには、kube-public Namespace の default ClientConfig を編集します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

USER_CLUSTER_KUBECONFIG は、クラスタの kubeconfig ファイルのパスに置き換えます。kubeconfig に複数のコンテキストがある場合は、現行のコンテキストが使用されます。コマンドを実行する前に、現在のコンテキストを正しいクラスタにリセットすることが必要になる場合があります。

ClientConfig 構成の形式は次のとおりです。

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: NAME
    ldap:
      certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
      connectionType: CONNECTION_TYPE
      host: HOST_NAME
      serviceAccountSecret:
        name: SERVICE_ACCOUNT_SECRET_NAME
        namespace: NAMESPACE
        type: SECRET_FORMAT
      user:
        baseDN: BASE_DN
        filter: FILTER
        identifierAttribute: IDENTIFIER_ATTRIBUTE
        loginAttribute: LOGIN_ATTRIBUTE
      group:
        baseDN: BASE_DN
        filter: FILTER
        identifierAttribute: IDENTIFIER_ATTRIBUTE

同じ ClientConfig に OIDC、LDAP、SAML の ID プロバイダ構成を複数追加できます。クラスタは、定義された順序で各構成による認証を試行し、認証が最初に成功した時点で停止します。次の ClientConfig の例では、特定の順序で複数の ID プロバイダを定義しています。

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - aws:
      region: us-west-2
    name: AWS Login
  - ldap:
  # Multiple lines are omitted here.
  - saml:
  # Multiple lines are omitted here.
  - azureAD:
  # Multiple lines are omitted here.
  - oidc:
    name: Okta OIDC
  # Multiple lines are omitted here.
  - oidc:
    name: Google OIDC
  # Multiple lines are omitted here.

ClientConfig LDAP フィールド

次の表に、ClientConfig ldap オブジェクトのフィールドを示します。追加する必要があるフィールドは、ID プロバイダトークンと、プラットフォーム管理者がプロバイダを構成した方法によって異なります。

フィールド	必須	説明	形式
name	○	この LDAP 構成を識別する名前	文字列
host	○	LDAP サーバーのホスト名または IP アドレス。ポートは省略可能であり、指定しない場合のデフォルトは 389 です。たとえば、`ldap.server.example.com` や `10.10.10.10:389` です。	文字列
certificateAuthorityData	特定の LDAP 接続タイプで必須	LDAP サーバー用の Base64 エンコードされた PEM 形式の認証局証明書が含まれます。これは、`ldaps` 接続と `startTLS` 接続に対してのみ指定する必要があります。	文字列
connectionType	○	LDAP サーバーへの接続時に使用する LDAP 接続タイプ。デフォルトは `startTLS` です。`insecure` モードはサーバーへのすべての通信が平文であるため、開発にのみ使用してください。	文字列
serviceAccountSecret
name	○	LDAP サービスアカウントの認証情報を格納する Kubernetes Secret の名前。	文字列
namespace	○	LDAP サービスアカウントの認証情報を格納する Kubernetes Secret の Namespace。	文字列
type	○	さまざまな種類のシークレットをサポートするために、サービスアカウントシークレットの形式を定義します。Secret 構成で `basic-auth` を指定した場合は、これを `basic` にする必要があります。それ以外の場合は、`tls` にする必要があります。指定しない場合のデフォルトは `basic` です。	文字列
user
baseDN	○	ユーザーエントリを検索する LDAP ディレクトリ内のサブツリーの場所。	文字列
filter	×	ユーザーの検索時に適用するオプションのフィルタ。これにより、ログインできるユーザーアカウントをさらに制限できます。指定しない場合のデフォルトは `(objectClass=User)` です。	文字列
identifierAttribute	×	認証後にユーザーの ID として使用する属性を指定します。これは、ユーザーがユーザー名を使用してログインできるようにする loginAttribute フィールドとは別のものですが、実際の ID がメールアドレスか完全な識別名（DN）になります。たとえば、loginAttribute を `sAMAccountName`、identifierAttribute を `userPrincipalName` に設定すると、ユーザーは `bsmith` としてログインできるようになりますが、ユーザーの実際の RBAC ポリシーは `bsmith@example.com` として記述されます。ユーザーごとに一意になることから、`userPrincipalName` の使用をおすすめします。指定しない場合は、デフォルトの `userPrincipalName` が使用されます。	文字列
loginAttribute	×	入力ユーザー名と照合する属性の名前。LDAP データベースでユーザーを検索するために使用されます（例: `(<LoginAttribute>=<username>)`）。また、オプションのフィルタフィールドと組み合わせて使用されます。デフォルトは `userPrincipalName` です。	文字列
group（オプションフィールド）
baseDN	○	グループエントリを検索する LDAP ディレクトリ内のサブツリーの場所。	文字列
filter	×	ユーザーが所属するグループを検索するときに使用するフィルタ（省略可）。これを使用することで、特定のグループのみを明示的に照合して、各ユーザーから返されるグループの数を減らすことができます。デフォルトは `(objectClass=Group)` です。	文字列
identifierAttribute	×	ユーザーが所属する各グループの識別名。たとえば、これが `distinguishedName` に設定されている場合、RBAC やその他のグループの期待値は完全な DN として記述する必要があります。指定しない場合は、デフォルトの `distinguishedName` が使用されます。	文字列

次のステップ

構成を適用したら、外部プロバイダからクラスタへのユーザーアクセスの設定に進みます。

LDAP 認証用にフリート メンバー クラスタを設定する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。