資格情報管理

KE2.0 システムで利用する各種ユーザ名・パスワード（資格情報）の管理について示します。

KE2.0 を構成する各サービス（PostgreSQL / RabbitMQ）には、それぞれ独立した認証情報が存在します。ke2-docker で初期構築するときのデフォルト値は互換性のための仮の値であり、本番運用前に必ず変更してください。本章では、各構成での資格情報の所在、設定方法、変更手順、および本番運用前に確認すべきチェックリストを示します。

注: 本ページは現時点で single/basic / single/extdb / cluster/swarm および外部連携 (extra/jobmngrd, kompira_sendevt) 構成を対象としています。cloud/azureci 構成は別途の追加リリースで案内予定です。

1. 資格情報の所在マップ

ke2-docker で構成する KE2.0 が扱う主な資格情報と、構成パターンごとの所在を以下に示します。

2. 初期セットアップ時の指定方法

2.1 single/basic 構成

内部 postgres / rabbitmq コンテナを含むオールインワン構成です。DATABASE_USER / DATABASE_PASSWORD / DATABASE_NAME / AMQP_USER / AMQP_PASSWORD を環境変数で指定すると、ke2-docker の compose ファイルがそれらの値を:

• POSTGRES_USER / POSTGRES_PASSWORD / POSTGRES_DB （postgres コンテナの初期化）
• RABBITMQ_DEFAULT_USER / RABBITMQ_DEFAULT_PASS （rabbitmq コンテナの初期化）
• DATABASE_URL / AMQP_URL （kompira / kengine / jobmngrd の接続情報）

すべてに反映します。

$ cd ke2/single/basic
$ DATABASE_PASSWORD='<DB_PASSWORD>' AMQP_PASSWORD='<AMQP_PASSWORD>' docker compose up -d

注 (変更対象の範囲): 上記の起動例ではパスワードのみを差し替えていますが、DATABASE_USER / DATABASE_NAME / AMQP_USER の既定値 (kompira / kompira / guest) も同様に環境変数で変更できます。本番運用では §3 のとおり全項目を独自値に変更することを推奨しますが、パスワードのみの変更でも初期セットアップ要件は満たせるため、上記は最小ステップとして示しています。

注 (URL 安全でない文字の扱い): DATABASE_USER / DATABASE_PASSWORD / DATABASE_NAME / AMQP_USER / AMQP_PASSWORD を個別変数で直接指定する場合、いずれの値も RFC 3986 unreserved set (英数字と -_.~) のみ を使用してください (compose が組み立てる URL の userinfo / path に未エンコードのまま埋め込まれるため、パスワード以外の項目も対象)。URL 安全でない文字 (@ : / % や空白等) を含む値を使う場合は、パーセントエンコード済みの DATABASE_URL / AMQP_URL を直接指定してください。詳細は §5 URL 安全でない文字を含む資格情報の扱い を参照。

2.2 single/extdb 構成

外部の PostgreSQL を利用する構成です。DATABASE_URL の指定が必須となります。

$ cd ke2/single/extdb
$ DATABASE_URL='pgsql://<DB_USER>:<DB_PASSWORD>@<DB_HOST>:<DB_PORT>/<DB_NAME>' docker compose up -d

DATABASE_URL 未指定で起動すると docker compose config 段階で即エラー停止します。

DATABASE_URL を直接指定する場合は、URL 安全でない文字を含むユーザ名・パスワード・DB 名 (userinfo / path のいずれの部分) もあらかじめ URL エンコードして埋め込む必要があります（後述）。

2.3 cluster/swarm 構成

PostgreSQL/Pgpool-II クラスタを利用する Swarm 構成です。KE2.0 のコンテナ（kompira / kengine / jobmngrd）は Pgpool-II の仮想 IP (VIP) 経由でデータベースに接続します。setup_stack.sh の実行時に、この VIP を指す DATABASE_URL を環境変数で指定します。

注 (データベースクラスタの配置): PostgreSQL/Pgpool-II クラスタは、Swarm ホスト上に同居させる構成（各 Swarm ホストで setup_pgpool.sh を実行）と、Swarm とは別のホスト群に構築する構成（データベース専用ホストで setup_pgpool.sh を実行）のどちらでも構いません（システム設計次第）。いずれの場合も、KE2.0 コンテナから Pgpool VIP に到達できることが前提です。本章で「Pgpool-II ノード」と記す場合は、同居・別居のいずれかにかかわらず Pgpool-II を実行しているホストを指します（資格情報の変更作業はこのホスト上で行います）。

$ cd ke2/cluster/swarm
$ DATABASE_URL='pgsql://<DB_USER>:<DB_PASSWORD>@<PGPOOL_VIP>:9999/<DB_NAME>' SHARED_DIR=/mnt/gluster ./setup_stack.sh
$ docker stack deploy -c docker-swarm.yml ke2

この構成の PostgreSQL/Pgpool-II クラスタ側のユーザ（kompira / pgpool / postgres / repl）のパスワードは、クラスタ構築時に setup_pgpool.sh で設定します。本番運用では初期構築時に強いパスワードを指定してください（環境変数 PG_KOMPIRA_PASS などで指定します。手順は 構築ガイド > Pgpool-II の準備 を参照）。デフォルトのまま構築してしまった場合は、§4.3 の手順で変更してください。

2.4 外部連携構成（extra/jobmngrd / kompira_sendevt）

外部 jobmngrd や kompira_sendevt から KE2.0 本体に AMQPS 接続する場合、KE2.0 側で rabbitmqctl add_user により専用ユーザを事前に追加します。手順は 構築ガイド > 外部連携構成 を参照してください。

3. デフォルト値の一覧

ke2-docker で初期構築するときに環境変数を指定しなかった場合の デフォルト値（仮の値） を以下に示します。これらは互換性のために残されたもので、本番運用ではすべて変更してください（特にパスワード (<DB_PASSWORD> / <AMQP_PASSWORD>) は推測されにくい十分に強いパスワードを設定してください）。

加えて、cluster/swarm 構成の setup_pgpool.sh は以下のデフォルト値で各種 PostgreSQL ユーザを作成します。本番運用ではこれらも変更必須です。初期構築時に環境変数（PG_KOMPIRA_PASS など）で強いパスワードを指定するのが確実です（構築ガイド > Pgpool-II の準備 参照）。構築後に変更する場合は §4.3 を参照してください。

4. パスワードの変更手順

4.1 KE2.0 root アカウント

ブラウザでログイン後、画面右上のユーザメニューから「パスワード変更」を選択して変更します（または管理画面の「アカウント設定」から）。詳細は アカウント管理 を参照してください。

4.2 Kompira 接続ユーザ（single/basic・single/extdb）

対象構成: 本節は single/basic・single/extdb 構成向けです。cluster/swarm 構成は手順が異なります（Pgpool-II の pool_passwd 同期が必要）ので §4.3 を参照してください。

PostgreSQL 側で Kompira 接続ユーザ（既定 kompira）のパスワードを更新したあと、ke2-docker の接続情報を同期させて kompira / kengine / jobmngrd を再起動します。

注意: 実行中ジョブフローがある場合は kengine 再起動で異常終了するため、可能なら停止状態で実施してください。

# (1) PostgreSQL 側でパスワード変更
# - single/basic の場合: 内部 postgres コンテナに psql で接続して対話的に変更
#   <DB_USER> / <DB_NAME> は構成で実際に使っている値に置き換える。
$ docker exec -it $(docker ps -q -f name=postgres) \
    psql -U '<DB_USER>' -d '<DB_NAME>' -c '\password <DB_USER>'
# - psql プロンプトでパスワードを 2 回入力。`\password` は対話入力なので
#   SQL リテラルとしてのエスケープ (シングルクオート等) は不要。
# - 非対話で実行したい場合は `ALTER USER <DB_USER> WITH PASSWORD '...'` も使えるが、
#   新パスワードに `'` を含む場合は SQL リテラル内で `''` にエスケープする必要がある。

# - single/extdb の場合: 外部 PostgreSQL に直接接続して同様に変更 (\password または ALTER USER)

# (2) ke2-docker の接続情報を更新
# - .env を使っている場合: DATABASE_PASSWORD と DATABASE_URL を新パスワードで書き換え
# - 環境変数を使っている場合: 次回 docker compose up 時に新パスワードを指定

# (3) kompira / kengine / jobmngrd を再起動
$ docker compose up -d --force-recreate kompira kengine jobmngrd

4.3 Pgpool / レプリケーション系ユーザのパスワード変更（swarm 構成）

cluster/swarm 構成の PostgreSQL/Pgpool-II クラスタ側のユーザ（kompira / pgpool / postgres / repl）のパスワードを構築後に変更する手順です。

可能なら初期構築時に設定してください。 クラスタ構築時に setup_pgpool.sh の環境変数（PG_KOMPIRA_PASS など）で強いパスワードを指定すれば、以下の変更作業は不要になります（構築ガイド > Pgpool-II の準備 参照）。以下は、すでにデフォルト値で構築してしまった場合の変更手順です。

Pgpool-II は、クライアントおよびバックエンドの認証に認証情報ファイル pool_passwd（scram-sha-256 用に AES 暗号化） を使用します。そのため、PostgreSQL 側のパスワードを変更したら、同じ内容を全 Pgpool-II ノードの pool_passwd にも反映しなければなりません。

重要（この 2 つを守らないと認証不能になります）:

• PostgreSQL 側（ALTER USER）と Pgpool-II 側（pool_passwd）は必ずセットで更新する。 片方だけだと、新旧どちらのパスワードでも接続できなくなります。
• pool_passwd の更新は全ノードで行う。 1 台でも古いままだと、そのノードが担当したときに認証が失敗します。

ここでは例として kompira ユーザのパスワードを変更します（他のユーザも同様の手順です）。

(1) PostgreSQL 側のパスワードを変更する（Pgpool VIP 経由でプライマリに接続します。プライマリに反映すればレプリケーションでスタンバイにも伝播します）。新パスワードをコマンド履歴やプロセス一覧に残さないよう、\password で対話的に設定します（' を含むパスワードでも SQL エスケープが不要で安全です）。

$ psql -h <PGPOOL_VIP> -p 9999 -U postgres
postgres=# \password kompira
# プロンプトに従い新しいパスワードを 2 回入力する

(2) 全 Pgpool-II ノードで pool_passwd を更新する。 各ノードで postgres ユーザとして pg_enc を実行し、プロンプトに新パスワードを入力します（コマンド引数にパスワードを書かないため安全です）。

# 全 Pgpool-II ノードで実行する (同居構成なら各 Swarm ホスト、別居構成なら各 DB ホスト)
$ sudo -u postgres pg_enc -m -k /var/lib/pgsql/.pgpoolkey -u kompira -p
db password: <NEW_PASSWORD を入力>

(3) 全 Pgpool-II ノードで設定を再読み込みする（再起動は不要です）。

# 全 Pgpool-II ノードで実行する (同居構成なら各 Swarm ホスト、別居構成なら各 DB ホスト)
$ sudo systemctl reload pgpool

(4) 変更したユーザに応じた追加作業:

• kompira（KE2.0 の Kompira 接続ユーザ）: KE2.0 コンテナがこのユーザで DB に接続するため、新パスワードを反映した DATABASE_URL で setup_stack.sh を再実行し、docker stack deploy -c docker-swarm.yml ke2 でスタックを再デプロイします。パスワードに URL で安全でない文字を含む場合は §5 に従ってパーセントエンコードしてください。
• pgpool（Pgpool-II のヘルスチェック/レプリ遅延チェック用）: PCP コマンド用の認証ファイル pcp.conf も全ノードで更新が必要です。パスワードをコマンド引数に書くとシェル履歴・プロセス一覧に残る（pg_md5 自身も引数指定を非推奨としています）ため、pg_md5 -p（プロンプトで新パスワードを入力）の出力を /etc/pgpool-II/pcp.conf の pgpool:<md5> 行に反映します。
• repl（レプリケーション専用）: repl は pool_passwd には含まれません。スタンバイのレプリケーション接続情報（primary_conninfo / .pgpass）の更新が必要になるため、可能な限り初期構築時に設定しておくことを推奨します。

変更後は、§7 のチェックリストや show pool_nodes（全ノードが up）で正常性を確認してください。

4.4 RabbitMQ ユーザ

内部 RabbitMQ の接続ユーザ（既定 guest）のパスワードを変更する手順です。構成により手順が異なります。

single/basic・single/extdb 構成:

# (1) RabbitMQ 側でパスワードを変更
$ docker exec $(docker ps -q -f name=rabbitmq) rabbitmqctl change_password '<AMQP_USER>' '<NEW_PASSWORD>'

# (2) ke2-docker の AMQP_PASSWORD / AMQP_URL を新パスワードで更新したのち、接続側を再起動
$ docker compose up -d --force-recreate kompira kengine jobmngrd

cluster/swarm 構成: RabbitMQ は 3 ノードのクラスタとして動作しますが、ユーザ情報はクラスタ全体で共有されるため、いずれか 1 つの rabbitmq コンテナで変更すれば全ノードに反映されます。そのうえで、各サービスの AMQP_URL を更新するために setup_stack.sh を新パスワードで再実行し、スタックを再デプロイします。

# (1) いずれかの Swarm ホストで RabbitMQ のパスワードを変更 (クラスタ全体に伝播する)
$ docker exec $(docker ps -q -f name=rabbitmq) rabbitmqctl change_password '<AMQP_USER>' '<NEW_PASSWORD>'
# (任意) 各ホストで反映を確認する
$ docker exec $(docker ps -q -f name=rabbitmq) rabbitmqctl authenticate_user '<AMQP_USER>' '<NEW_PASSWORD>'

# (2) AMQP_PASSWORD を新パスワードにして docker-swarm.yml を再生成し、再デプロイする
#     (DATABASE_URL / SHARED_DIR などは初期構築時と同じ値を指定する)
$ cd ke2/cluster/swarm
$ AMQP_USER='<AMQP_USER>' AMQP_PASSWORD='<NEW_PASSWORD>' \
    DATABASE_URL='pgsql://<DB_USER>:<DB_PASSWORD>@<PGPOOL_VIP>:9999/<DB_NAME>' \
    SHARED_DIR=/mnt/gluster ./setup_stack.sh
$ docker stack deploy -c docker-swarm.yml ke2

注: 上記は新パスワードをシングルクオートで囲む形式のため、シェル特殊文字 (# / 空白 / $ 等) を含むパスワードでも安全にコピペできます。ただし新パスワード自体に ' (シングルクオート) を含む場合は閉じてしまうため、'\'' でエスケープするか、stdin 経由で渡すなど別の手段を使ってください。詳細は §5 シェル例で ' を含む値を扱う場合の対処 を参照。

外部接続用に追加したユーザの場合も同様に rabbitmqctl change_password で変更します（この場合 AMQP_URL の更新は不要で、外部接続クライアント側の設定を新パスワードに合わせます）。

5. URL 安全でない文字を含む資格情報の扱い

DATABASE_URL / AMQP_URL に埋め込むユーザ名・パスワード・DB 名 (パス部分) は、いずれも RFC 3986 (URI: Generic Syntax) に従う必要があります。RFC 3986 §2.3 で「unreserved」と定義された英数字および - _ . ~ 以外の文字を含む場合、%XX 形式でパーセントエンコードします。本節はパスワードに限らず、ユーザ名・DB 名にも同様に適用されます (DATABASE_URL / AMQP_URL の userinfo は RFC 3986 §3.2.1、path は §3.3 に従って解釈されます)。

主要文字のエンコード対応表:

実例: 実パスワード p@ss:w0rd を DATABASE_URL に埋め込む場合は、pgsql://user:p%40ss%3Aw0rd@host:5432/db のように p@ss:w0rd → p%40ss%3Aw0rd に変換します。

環境変数別の挙動

コンテナイメージのバージョン指定について: 上記表で AMQP_USER / AMQP_PASSWORD / AMQP_URL の URL 安全でない文字対応に コンテナイメージ v2.0.5.post2 以降が必要 と記載した制約は、デプロイ時に使用するイメージのバージョンが要件を満たしていない場合に発現します。利用イメージのタグ指定方法は KOMPIRA_IMAGE_NAME / KOMPIRA_IMAGE_TAG を参照してください (環境変数リファレンス側に記載されているデフォルトタグの例示値は更新時点で公開されていた値であり、URL 安全でない文字対応の要件を満たすには KOMPIRA_IMAGE_TAG=2.0.5.post2 以降を明示的に指定 する必要があります)。新しいタグに変更したあとは docker compose pull を再実行してから docker compose up -d で起動してください。

シェル例で ' を含む値を扱う場合の対処

本マニュアル全体のシェルコマンド例は、値全体をシングルクオートで囲む形 (KEY='<value>' / rabbitmqctl ... '<password>' 等) を採っています。これは # / 空白 / $ / ! 等のシェル特殊文字を含む強パスワードでも安全にコピペできるためですが、値自体に ' (シングルクオート) が含まれる場合は閉じてしまい破綻します。以下のいずれかを利用してください。

• '\'' でエスケープ: シングルクオートを 閉じる ' → \ でエスケープした ' → 開き直す ' の 3 文字 '\'' で逐次切替する。例: 実パスワード p'ss を埋め込む → 'p'\''ss' (シェルで解釈されると p'ss 1 つの文字列)。
• パスワード変更時の代替手段:
  • PostgreSQL: 上述の \password <DB_USER> で対話設定する (SQL リテラルとしてのエスケープも不要)
  • RabbitMQ: rabbitmqctl change_password に標準入力経由で渡すか、いったん別のパスワード (英数字のみ) に変更してから .env 経由で目的のパスワードに切り替えるなど

.env を source で読み込む場合の注意

.env ファイル内容は set -a; source .env; set +a で読み込むと シェルスクリプトとして評価される ため、内容に任意のシェルコマンドが含まれていれば実行されます。source での読み込みは、自分で作成した、または信頼できる内容の .env のみに対して実行してください。第三者から受け取った .env などは目視確認するか、シェル評価を伴わない読み込み手段 (例: grep '^DATABASE_USER=' .env | cut -d= -f2- などで個別変数を取り出して扱う) を利用してください。

6. PostgreSQL の初回限定挙動と対処（single/basic 構成）

対象構成: 本節は 内部 postgres コンテナを使う single/basic 構成のみに該当します。single/extdb・cluster/swarm 構成では PostgreSQL は ke2-docker の外部（別ホストまたは別途構築した DB クラスタ）にあり、この挙動は発生しません（これらの構成でのパスワード変更は §4.2 / §4.3 を参照）。

PostgreSQL 公式コンテナイメージの POSTGRES_USER / POSTGRES_PASSWORD / POSTGRES_DB 環境変数は initdb 時（データボリュームが空の状態での初回起動時）のみ参照 される仕様です。既存のデータボリュームを残したまま DATABASE_USER / DATABASE_PASSWORD / DATABASE_NAME を変更しても、DB 内のユーザ・パスワード・データベース名は更新されません。

症状

.env や環境変数のパスワードだけ変更してコンテナを再起動した場合、kompira / kengine / jobmngrd のコンテナログに以下のようなエラーが記録されます。

FATAL: password authentication failed for user "kompira"

kengine は再起動ループに入ります。

対処方法

方法 A（推奨・データ保持）: ALTER USER で DB 内パスワードを変更

§4.2 Kompira 接続ユーザ の手順に従って、DB 側のパスワードを ALTER USER で変更し、ke2-docker の env / .env を同期します。データはそのまま保持されます。

方法 B（破壊的・テスト環境向け）: ボリュームごと完全リセット

開発・テスト環境などデータを破棄してよい場合は、以下のように docker compose down -v で関連ボリュームを削除してから再起動します。

$ docker compose down -v   # PostgreSQL データを含むボリュームが削除される
$ docker compose up -d     # 新しい DATABASE_PASSWORD で initdb が実行される

警告: docker compose down -v はすべての関連ボリューム（PostgreSQL データ含む）を削除します。 バックアップなしの本番環境では絶対に実行しないでください。

7. 本番運用前のセキュリティチェックリスト

本番運用を開始する前に、以下の項目を必ず確認してください。

• KE2.0 の root アカウントのパスワードを変更したか
• PostgreSQL の Kompira 接続ユーザのパスワードを強化したか
  • 特に single/extdb・cluster/swarm 構成では必須。これらは PostgreSQL が ke2-docker の外（別ホストや Pgpool-II クラスタ経由）にあり、他システムからアクセスされうるため、弱いパスワードを残すと侵害リスクが高まる（swarm は DB を Swarm ホストに同居させる構成でも、コンテナ外からの到達性がある点は同様）
  • single/basic 構成では postgres コンテナがホスト外に公開されないため重要度は下がるが、コンテナ間通信に対する最低限の強化として推奨
• 自己署名 SSL 証明書を本番証明書に置き換えたか、または自己署名のリスクを受容したか（SSL 証明書の管理 を参照）
• 外部接続を行う場合は、rabbitmq の外部接続用ユーザを追加し、強いパスワードを設定したか
• （cluster/swarm のみ）Pgpool 系ユーザ（kompira / pgpool / postgres / repl）に強いパスワードを設定したか（デフォルトの弱いパスワードのままにしていないか。初期構築時の PG_*_PASS 指定、または §4.3 の変更手順で対応）
• .secret_key をバックアップしたか（暗号化秘密鍵の管理 を参照）

8. 関連項目

• 暗号化秘密鍵の管理 — .secret_key ファイルの管理とローテーション
• SSL 証明書の管理 — HTTPS / AMQPS 用の SSL 証明書管理
• 構築ガイド > 外部連携構成 — 外部 jobmngrd / kompira_sendevt の rabbitmq ユーザ追加手順
• 環境変数 — ke2-docker の環境変数リファレンス