データベースロール管理¶

CloudNativePGは当初から、PostgreSQLインスタンスで必要な特定のロールの作成を管理してきました。

postgres スーパーユーザー、streaming_replica 、cnpg_pooler_pgbouncer などの一部の予約ユーザー（PgBouncer Pooler を使用する場合）
アプリケーションデータベースの低権限所有者として設定されたアプリケーションユーザー

このプロセスについては、 BootstrapConfiguration セクションで説明されています。

クラスター仕様のmanaged スタンザにより、CloudNativePGは、 .spec.managed.roles で指定されたロールの完全なライフサイクル管理を提供するようになりました。

この機能により、既存のロールの宣言的管理と、新しいロールがデータベースにまだ存在しない場合は作成できます。ロールの作成は、データベースのブートストラップが完了した後に発生します。

宣言的なロール管理を備えたクラスターのマニフェストの例は、次のファイルにあります。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example-with-roles
spec:
  instances: 3
  storage:
    size: 1Gi

  managed:
    roles:
    - name: dante
      ensure: present
      comment: my database-side comment
      login: true
      superuser: false
      createdb: true
      createrole: false
      inherit: false
      replication: false
      bypassrls: false
      connectionLimit: 4
      validUntil: "2053-04-12T15:04:05Z"
      inRoles:
        - pg_monitor
        - pg_signal_backend
      passwordSecret:
        name: cluster-example-dante
- --
apiVersion: v1
data:
  username: ZGFudGU=
  password: ZGFudGU=
kind: Secret
metadata:
  name: cluster-example-dante
type: kubernetes.io/basic-auth

。

これはそのファイルからの抜粋です。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
spec:
  managed:
    roles:
    - name: dante
      ensure: present
      comment: Dante Alighieri
      login: true
      superuser: false
      inRoles:
        - pg_monitor
        - pg_signal_backend

spec.managed.roles のロール仕様は PostgreSQL structure and naming conventions に従います。各ロールに定義できる属性の完全なリストについては、

APIリファレンスを参照してください。

いくつかの点に注意してください。

ensure 属性は、PostgreSQLの 一部ではありません 。これにより、宣言的なロール管理でロールを作成および削除できます。 2つの可能な値は、present （デフォルト）とabsent です。
inherit 属性は、PostgreSQLの規則に従って、デフォルトでtrueです。
PostgreSQLの規則に従って、 connectionLimit 属性のデフォルトは-1です。
inRoles を持つロールメンバーシップは、デフォルトでメンバーシップなしになります。

宣言的なロール管理により、PostgreSQLインスタンスが仕様に準拠していることを保証します。ユーザーがデータベースでロール属性を直接変更した場合、CloudNativePGオペレーターは次の調整サイクル中にそれらの変更を元に戻します。

実現不可能なロール構成¶

PostgreSQLでは、場合によっては、データベースがコマンドを受け入れることができず、拒否されます。: PostgreSQL documentation on error codes を参照してください

詳細については。

ロール操作は、このような基本的なエラーを生成する可能性があります。 2つの例：

PostgreSQLにロール（グループ）poets のメンバーとしてロールpetrarca を作成するように依頼しますが、 poets は存在しません。
PostgreSQLにロールdante を削除するように依頼しますが、ロールdante はデータベースinferno の所有者です。

これらの基本的なエラーは、人間の管理者からの明確化なしに、データベースもCloudNativePGオペレーターも修正できません。上記の2つの例は、ロールpoets を作成するか、データベースinferno をそれぞれ削除することで修正できますが、それらは人為的エラーが原因である可能性があり、そのような場合、提案された「修正」は間違ったことである可能性があります。

CloudNativePGは、このような基本的なエラーが発生したときに記録し、クラスターのステータスに表示します。続くのは…

管理対象ロールのステータス¶

以下に示すように、CRDステータスには、管理対象ロールのステータスのセクションが含まれます。

status:
  […snipped…]
  managedRolesStatus:
    byStatus:
      not-managed:
      - app
      pending-reconciliation:
      - dante
      - petrarca
      reconciled:
      - ariosto
      reserved:
      - postgres
      - streaming_replica
    cannotReconcile:
      dante:
      - could not perform DELETE on role dante: owner of database inferno
      petrarca:
      - could not perform UPDATE_MEMBERSHIPS on role petrarca: role "poets" does not exist

データベース（およびCloudNativePG）が尊重できず、人間の介入が必要なオペレーションの特別なサブセクションcannotReconcile に注意してください。

このセクションでは、オペレーターの使用のために予約されているロールと、宣言管理下にないロールについて説明し、データベースインスタンス内のロールの包括的なビューを提供します。

重要

下位互換性の観点から、宣言型ロール管理は、データベースに存在するが仕様に含まれていないロールを無視するように設計されています。これらのロールのライフサイクルは引き続きPostgreSQL内で管理されるため、CloudNativePGユーザーは都合の良いときにこの機能を採用できます。

データベースロール管理¶

実現不可能なロール構成¶

管理対象ロールのステータス¶

前のトピックへ

次のトピックへ

目次