Kubernetes で Active Directory ユーザーのサポートを統合する

ドキュメントのバージョンを選択します。

このドキュメントでは、Kubernetes ベースの AlloyDB Omni データベース クラスタで Active Directory 統合を有効にして、既存の Active Directory ベースのユーザーが AlloyDB Omni データベースにアクセスできるようにする方法について説明します。Active Directory の統合により、Kerberos メカニズムを使用して認証されたユーザーが AlloyDB Omni にアクセスするための認可が GSSAPI を介して提供されます。

詳細については、Active Directory の概要をご覧ください。

このドキュメントは、Kubernetes マニフェスト ファイルの適用と kubectl コマンドライン ツールの使用に精通していることを前提としています。詳細については、コマンドライン ツール(kubectl)をご覧ください。

始める前に

Active Directory との統合を有効にするには、次の要件を満たしている必要があります。

  • Kubernetes 環境にデプロイされた AlloyDB Omni クラスタ
  • Active Directory サーバー Keytab

AlloyDB Omni Kubernetes オペレーター 1.4.0 から 1.5.0 に移行する

AlloyDB Omni オペレーター バージョン 1.4.0 以前の Active Directory 統合を使用している場合は、AlloyDB Omni オペレーター バージョン 1.5.0 に移行する必要があります。

AlloyDB Omni オペレーター バージョン 1.5.0 に移行する手順は次のとおりです。

  1. AlloyDB Omni オペレーター をバージョン 1.5.0 にアップグレードします
  2. ユーザー定義の認証リソースを作成します。
    1. 新しい UserDefinedAuthentication リソース マニフェストを作成します。
    2. spec.dbclusterRef に、ターゲット DBCluster の名前を入力します。
    3. spec.keytabSecretRef に keytab シークレットの名前を入力します。
    4. Active Directory と Kerberos 認証に関連する既存の pg_hba.conf ルールを spec.pgHbaEntries フィールドにコピーします。
    5. 既存の pg_ident.conf rules(ある場合)を spec.pgIdentEntries フィールドにコピーします。
    6. この新しいマニフェスト(kubectl apply -f user-auth-crd.yaml など)を適用します。
  3. プレビュー構成を削除して、クラスタを再デプロイします。
    1. DBCluster リソース定義で、以前に Active Directory 統合の構成に使用したすべてのアノテーションを削除します。例えば、ホストベースの認証(HBA)ルール、ident ルール、keytab ファイル アノテーションなどです。
    2. 作成した pg_hbapg_ident の構成マップを削除します。
    3. 更新された DBCluster マニフェストを再度適用します。

Active Directory サポートを構成する

  1. Keytab を使用してシークレットを作成して適用します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: KEYTAB_SECRET_NAME
      namespace: DB_CLUSTER_NAMESPACE
    type: Opaque
    data:
      krb5.keytab: |
       KEYTAB_FILE_CONTENT
    

    以下は、Active Directory サーバーで keytab を生成するコマンドの例です。

    ktpass /princ postgres/DBCLUSTER_HOST@REALM /Pass PASSWORD /mapuser postgres /crypto ALL /ptype KRB5_NT_Principal /out OUTPUT_PATH
    

    ALLOYDB_HOST は、DBCluster または DBCluster IP アドレスを指すホストです。

  2. 次のユーザー定義の認証カスタム リソース マニフェストを適用します。

    apiVersion: alloydbomni.dbadmin.goog/v1
    kind: UserDefinedAuthentication
    metadata:
      name: USER_DEFINED_AUTHENTICATION_NAME
      namespace: DB_CLUSTER_NAMESPACE
    spec:
      dbclusterRef:
        name: DB_CLUSTER_NAME
      keytabSecretRef:
        name: KEYTAB_SECRET_NAME
      pgHbaEntries:
        PG_HBA_ENTRIES
      pgIdentEntries:
        PG_IDENT_ENTRIES
    

    次のように置き換えます。

    • USER_DEFINED_AUTHENTICATION_NAME: UserDefinedConfiguration の名前(例: DB_CLUSTER_NAME-ad-auth)。
    • DB_CLUSTER_NAMESPACE: このバックアップ プランの Kubernetes Namespace。 Namespace は、データベース クラスタの Namespace と一致する必要があります。
    • DB_CLUSTER_NAME: データベース クラスタの名前。作成時に割り当てたものです。
    • KEYTAB_SECRET_NAME: 作成した keytab の名前。
    • PG_HBA_ENTRIES: pg_hba.conf エントリ(文字列リスト)。これらのエントリは、pg_hba.conf のデフォルト エントリを上書きします。無効な構成を追加すると、ユーザーはログインできません。

      上の例では、GSS ベースの認証のエントリの後にパスワード ベースの認証のエントリを追加しました。つまり、ユーザーは GSS API を使用してログインします。このログイン方法が失敗した場合は、パスワードベースの認証がフォールバックとして使用されます。

      詳細については、pg_hba.conf ファイルをご覧ください。

    • PG_IDENT_ENTRIES: pg_ident.conf エントリ(文字列リスト)。ユーザー名のマッピングを実装するには、pg_hba.conf ファイルの options フィールドに map= を指定します。詳細については、ID マップをご覧ください。

      次の例をご覧ください。

       apiVersion: v1
       kind: Secret
       metadata:
         name: db-keytab-dbcluster-sample
       type: Opaque
       data:
         krb5.keytab: |
           DUMMY_KEYTAB
       ---
       apiVersion: alloydbomni.dbadmin.goog/v1
       kind: UserDefinedAuthentication
       metadata:
         name: dbcluster-sample-ad-auth
       spec:
         dbclusterRef:
           name: dbcluster-sample
         keytabSecretRef:
           name: db-keytab-dbcluster-sample
         pgHbaEntries:
           - hostgssenc all           all      0.0.0.0/0     gss
           - hostgssenc all           all      ::1/128       gss
           - hostssl all all 0.0.0.0/0 scram-sha-256
           - hostssl all all ::/0 scram-sha-256
         pgIdentEntries:
           - usermap  active_directory_user postgres_user
      

Active Directory ユーザーとしてデータベース ロールを作成する

  1. Active Directory ユーザーに一致するロールをデータベースに作成します。Active Directory ユーザーのロールを作成するには、クラスタに接続して次のコマンドを実行します。

    username=# CREATE ROLE "USERNAME@REALM" WITH LOGIN;
    
  2. Active Directory ユーザーを使用してデータベースにログインします。接続するクライアントで kinit が有効になっている必要があります。この例では、postgres-client Pod に kinit と psql がインストールされ、psql クライアントを使用して AlloyDB Omni クラスタに接続するように構成されています。

    kubectl exec -it postgres-client -n DB_CLUSTER_NAMESPACE -- bash
    root:/# kinit USERNAME
    Password for USERNAME@REALM:
    
    root:/# psql -h HOSTNAME -d DB_NAME -U USERNAME@REALM
    psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 16.3)
    GSSAPI-encrypted connection
    Type "help" for help.
    
  3. SQL クエリを実行します。

    username=# select * from TABLE_NAME;
    

Active Directory 認証を無効にする

Active Directory 認証を無効にするには、次の Helm コマンドを実行します。

helm upgrade alloydbomni-operator PATH_TO_CHART -n alloydb-omni-system --set userDefinedAuthentication.enabled=false

このコマンドは、次の出力を返します。

Release "alloydbomni-operator" has been upgraded. Happy Helming!
NAME: alloydbomni-operator
LAST DEPLOYED: CURRENT_TIMESTAMP
NAMESPACE: alloydb-omni-system
STATUS: deployed
REVISION: 2
TEST SUITE: None

次のステップ