Active Directory グループのサポートを AlloyDB Omni と統合する

ドキュメントのバージョンを選択してください。

このページでは、AlloyDB Omni で Active Directory グループベースの認証と認可を設定して管理する方法について説明します。Active Directory グループベースのサポートにより、Active Directory のユーザーのグループ メンバーシップに基づいて PostgreSQL ロール メンバーシップの管理が自動化されます。これにより、ユーザー管理が効率化され、権限が同期されます。

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

Active Directory 統合ワークフロー

Active Directory 統合は、次のワークフローに示すように、PostgreSQL 拡張機能（google_pg_auth）を使用して実装されます。

  1. ユーザーのログイン: ユーザーは、GSSAPI を使用して標準の Active Directory 認証情報で AlloyDB Omni に対して認証を行います。
  2. ロールの自動作成: ユーザーに対応する PostgreSQL ロールが存在しない場合、システムが自動的に作成します（例: CREATE ROLE "user@REALM" WITH LOGIN;）。
  3. LDAP グループ チェック: システムは LDAP を使用して Active Directory に安全に接続し、ユーザーの現在のグループ メンバーシップを取得します。
  4. メンバーシップの同期: システムは、ユーザーの Active Directory グループと、構成したマッピングを比較します。
    • マッピングされた Active Directory グループに属しているユーザーが、対応する PostgreSQL グループに属していない場合、ユーザーにメンバーシップが付与されます。
    • マッピングされた Active Directory グループに属していないユーザーが、対応する PostgreSQL グループに属している場合、ユーザーのメンバーシップは取り消されます。
  5. ログイン完了: ユーザーの接続が完了し、データベースにログインします。ユーザーの権限は、ユーザーが属する PostgreSQL ロールによって決まります。このロールは、Active Directory グループのステータスと同期しています。

この同期はユーザーがログインするたびに自動的に行われるため、PostgreSQL のアクセス権は Active Directory の現在の状態を反映します。

始める前に

Active Directory グループのサポートを AlloyDB Omni と統合する前に、次の要件を満たしていることを確認してください。

  • GSSAPI 認証: AlloyDB Omni インスタンスで GSSAPI ベースの認証が構成され、動作している必要があります。詳細については、Active Directory と AlloyDB Omni を統合するをご覧ください。

  • PostgreSQL グループロール: 次の例に示すように、Active Directory グループにマッピングする PostgreSQL グループロールを手動で作成する必要があります。

    CREATE ROLE 'postgres_developers';
CREATE ROLE 'postgres_read_only';

  • 権限: これらの PostgreSQL グループロールにデータベース権限（SELECT や INSERT など）を手動で割り当てる必要があります。この統合ではメンバーシップのみが管理されます。次の例に示すように、グループ自体の権限は管理されません。

    GRANT SELECT ON ALL TABLES IN SCHEMA sales TO postgres_read_only;
GRANT USAGE ON SCHEMA finance TO postgres_developers;
GRANT USAGE ON SCHEMA sales TO postgres_read_only;
GRANT SELECT, INSERT ON finance.transactions TO postgres_developers;

Active Directory グループのサポートを構成する

AlloyDB Omni で Active Directory グループのサポートを構成するには、google_pg_auth 拡張機能を有効にし、postgresql.conf ファイルで Active Directory の詳細を指定して、認証情報を安全に処理します。

  1. LDAP パスワードを入力します。

    次の例に示すように、AD_LDAP_PASSWORD 環境変数を使用して、ldap_bind_dn サービス アカウントのパスワードを AlloyDB Omni コンテナに提供する必要があります。

    docker run -d --name CONTAINER_NAME \
          -e POSTGRES_PASSWORD=NEW_PASSWORD \
          -e AD_LDAP_PASSWORD=AD_LDAP_PASSWORD \
          -vDATA_DIR:/var/lib/postgresql/data \
          -p HOST_PORT:5432 \
          --restart=always \
          google/alloydbomni:IMAGE_TAG

  2. google_pg_auth 拡張機能を有効にします。

    1. postgresql.conf ファイルで、次のパラメータを追加または変更して拡張機能を有効にし、LDAP 接続を構成します。postgresql.conf ファイルは、AlloyDB Omni イメージの起動時にマウントしたデータ ディレクトリにあります。

      # ---------------------------------------------------------------------------
# ALLOYDB ACTIVE DIRECTORY INTEGRATION SETTINGS
# ---------------------------------------------------------------------------

google_pg_auth.enable_auth = on
google_pg_auth.ldap_uri = "AD_LDAP_SERVER_HOST"
google_pg_auth.ldap_base_dn = AD_LDAP_BASE_DN
google_pg_auth.ldap_bind_dn = AD_LDAP_BIND_DN
google_pg_auth.auth_cache_ttl_sec = 3600

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

      • AD_LDAP_SERVER_HOST: Active Directory LDAP サーバーの URI（例: ldap://ad-controller.example.com）。
      • AD_LDAP_BASE_DN: LDAP 検索を実行するためのベース識別名（DN）。例: DC=example,DC=com
      • AD_LDAP_BIND_DN: AlloyDB Omni が接続と LDAP 検索の実行に使用する Active Directory ユーザー アカウントの識別名（DN）。例: setupadmin@ad-example.com
      • auth_cache_ttl_sec は、AlloyDB Omni が LDAP サーバーへの再接続を試みる前に、ユーザーごとに AlloyDB Omni がデータをキャッシュに保存するまでの経過時間です。auth_cache_ttl_sec の値は、最小値の 60 秒から最大値の 86,400 秒（24 時間）までの範囲で指定できます。

    2. postgresql.conf の shared_preload_libraries パラメータに google_pg_auth を追加します。

    3. postgresql.conf ファイルに次の行を追加します。

      shared_preload_libraries='google_pg_auth,google_columnar_engine,google_job_scheduler,google_storage'

    4. データベースを再起動します。

      docker restart CONTAINER_NAME

  3. LDAPS 証明書を構成します。

    LDAPS 経由で Active Directory サーバーへの安全な接続を確保するには、CA 証明書が必要です。

    LDAPS 証明書ファイルを、AlloyDB Omni イメージの事前定義された場所（/etc/ldap/ldap.crt）に配置します。

グループ マッピングを管理する

Active Directory グループと PostgreSQL ロール間のマッピングは、SQL 関数を使用して作成、管理できます。

クラスタにログインして拡張機能を読み込む

docker exec -it CONTAINER_NAME psql -h localhost -U postgres
postgres=# CREATE EXTENSION google_pg_auth;
CREATE EXTENSION

グループ マッピングを作成する

すでに作成した PostgreSQL グループロールに Active Directory グループをマッピングするには、map_ad_group() 関数を使用します。

SELECT google_pg_auth.map_ad_group(ad_group_name TEXT, ad_group_sid TEXT, pg_role_name TEXT);

たとえば、ad-developers Active Directory グループを pg-developers PostgreSQL ロールにマッピングするには、次のコマンドを使用します。

SELECT google_pg_auth.map_ad_group('ad-developers', 'S-1-5-21-.....', 'postgres_read_only');

Active Directory の特定のグループの SID を取得するには、Active Directory サーバーで次のコマンドを使用します。

C:\Users\Admin> Get-ADGroup -Identity ad-developers | select SID

             SID
-----------------------------------------------
S-1-5-21-3168537779-1985441202-1799118680-1612

グループ マッピングを削除する

既存のマッピングを削除するには、unmap_ad_group() 関数を使用します。この関数によりそのグループの同期を停止できますが、ユーザーがすでにメンバーである場合は、PostgreSQL グループからユーザーを削除しません。

SELECT google_pg_auth.unmap_ad_group(ad_group_sid TEXT, pg_role_name TEXT);

次の例をご覧ください。

SELECT google_pg_auth.unmap_ad_group('quinn@google.com', 'postgres_read_only');

AlloyDB Omni データベースに接続する

Active Directory ユーザーを使用して AlloyDB Omni データベースにログインします。接続するクライアントで kinit を有効にする必要があります。

次の例では、postgres-client Pod に kinit と psql がインストールされており、psql クライアントを使用して AlloyDB Omni クラスタに接続するように構成されています。

root@postgres-client:/# kinit AD_USER_NAME
Password for user1REALM:

root@postgres-client:/# psql -h ALLOYDB_SERVER_HOST_NAME -U AD_USER_NAME@REALM -d postgres
psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 16.3)
GSSAPI-encrypted connection
Type "help" for help.

user1=#

AlloyDB Omni データベースでのアクセス権は、次の情報に基づいて自動的に決定されます。

  • Active Directory グループの現在のメンバーシップ。
  • 管理者が定義した Active Directory グループと PostgreSQL ロールのマッピング。
  • 管理者がこれらの PostgreSQL ロールに付与した権限。

初めて接続する場合は、PostgreSQL ユーザーロール（your_ad_user@YOURDOMAIN.COM）が自動的に作成されます。

管理者がログインするたびにシステムは現在の Active Directory グループ メンバーシップを確認し、対応する PostgreSQL ロール メンバーシップを一致するように更新します。この同期を行うために、特別な操作を行う必要はありません。

データベース接続の例

ユーザー Quinn が ad_developers という名前の Active Directory グループに属しているとします。管理者は、ad_developers を pg_read_only という名前の postgres ロールにマッピングしました。このロールには、sales というテーブルに対する読み取り権限があります。ユーザーはログインするとテーブルにアクセスできます。

root@postgres-client:/# kinit quinn@REALM
Password for quinn@YOUR.REALM:

root@postgres-client:/# psql -h ALLOYDB_SERVER_HOST_NAME -U quinn@REALM -d postgres
psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 16.3)
GSSAPI-encrypted connection
Type "help" for help.

postgres=# select * from sales;
// Query will be run successfully

次の例では、Quinn が Active Directory の ad_developers グループから削除されます。

root@postgres-client:/# kinit quinn@REALM
Password for quinn@YOUR.REALM:

root@postgres-client:/# psql -h ALLOYDB_SERVER_HOST_NAME -U quinn@REALM -d postgres
psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 16.3)
GSSAPI-encrypted connection
Type "help" for help.

postgres=# select * from sales;
// Query will fail

制限事項

  • グループと権限の手動管理: この機能は、既存の PostgreSQL グループのユーザー メンバーシップのみを自動化します。これらのグループの作成と権限の付与は手動で行います。
  • 同期の遅延: メンバーシップはユーザーがログインしたときにのみ同期されます。Active Directory でユーザーのグループ メンバーシップを変更しても、AlloyDB Omni にはユーザーの次回のログイン セッションまで反映されません。
  • パフォーマンス: LDAP 検索により、ユーザーの初回ログイン プロセスにわずかにレイテンシが発生します。キャッシュ保存は、構成された有効期間（auth_cache_ttl_sec）内の以降のログインにおけるレイテンシを軽減するのに役立ちます。
  • エラー処理: LDAP サーバーにアクセスできない場合や、同期プロセス中に他のエラーが発生した場合は、AlloyDB Omni によりエラーがログに記録されます。ただし、GSSAPI 認証は成功しているため、ユーザーのログインは成功します。このセッションのグループ メンバーシップの同期のみが失敗します。

次のステップ