パスワード · APIキーの変更

データレイクのサービスアカウント（PostgreSQL · Aster TSDB · Valkey · RustFS · Kafka/MQTT …）とAPIキーは、すべてのインストール版が同じデフォルト値で始まります。コミッショニング時に必ず変更し、その後はポリシーに従ってローテーションします。

変更ツールは、ホストの**bin/passwd.sh**の1つです。

cd /opt/kopens/plantpulse-platform-docker

bin/passwd.sh --list                       # 바꿀 수 있는 키 + 계정명 + 현재값(마스킹) + 정본 위치
bin/passwd.sh PP_PG_PASSWORD               # 값을 생략하면 프롬프트 — 권장 (히스토리 · ps 에 안 남는다)
bin/passwd.sh PP_PG_PASSWORD=<새비밀번호>   # 인라인
bin/passwd.sh PP_CASSANDRA_PASSWORD PP_S3_PASSWORD   # 여러 개를 한 번에 — 재시작 1회
bin/passwd.sh --dry-run PP_MQ_PASSWORD     # 계획만 — 아무것도 바꾸지 않는다

ファイルを開いてパスワード行を修正しないでください

パスワードは2箇所に分かれています — サーバーが受け入れる値（PostgreSQLアカウント、Aster TSDB role …）と、クライアントが提示する値（設定ファイル約20個）。両者は自動的には一致しません。サイドカーだけを修正すると、次の再起動ですべてのクライアントが認証に失敗し、サーバーだけを変更すると、即座に失敗します。

passwd.shは、①サーバー側アカウント変更 → ②サイドカー更新 → ③設定再レンダリング → ④再起動を1コマンド内で順番に実行します。

変更可能なキー

キーは環境変数名そのままです。postgres · mqのような別名はありません — どのキーがどのコンポーネントに属するかは--listが教えてくれます。

キー	コンポーネント	アカウント	値の原本はどこか
`PP_PG_PASSWORD`	PostgreSQL	`plantpulse`	コマンド — `ALTER ROLE` (psql)
`PP_TEMPORAL_PASSWORD`	TemporalのバックエンドPostgreSQLアカウント	`temporal`	コマンド — `ALTER ROLE` (psql)
`PP_HIVE_PASSWORD`	HiveメタストアのPostgreSQLアカウント + Kyuubiインバウンド認証	`hive`	コマンド — `ALTER ROLE` (psql) + 再レンダリング
`PP_CASSANDRA_PASSWORD`	Aster TSDB	`cassandra`	コマンド — `ALTER ROLE` (cqlsh)
`PP_REDIS_PASSWORD`	Valkey	—	ファイル — `plantpulse-storage/cache/valkey/conf/valkey.conf`
`PP_S3_PASSWORD`	RustFS	`rustfs`	起動env — `RUSTFS_SECRET_KEY`
`PP_MQ_PASSWORD`	Kafka + HiveMQ — 1つの値を共有	`mq`	ファイル — `kafka/config/jaas.conf` + `mqtt/conf/auth.properties`
`PP_CEP_API_KEY`	CEP APIキー (`X-API-Key`)	—	ファイル — `plantpulse-cep/config/plantpulse-cep.properties`
`PP_DATA_GATEWAY_API_KEY`	データゲートウェイAPIキー	—	ファイル — `plantpulse-data-gateway/config/plantpulse-jdbc.properties`
`PP_DATALAKE_ADMIN_PASSWORD`	管理コンソールログイン	`admin`	起動env — admin-apiが自分の環境変数から読み取る
`PP_DATALAKE_ADMIN_API_KEY`	管理コンソールログエンドポイント `X-API-Key`	—	起動env

3つの意味:

コマンド — サーバーアカウントが原本です。SQL/CQLで変更し、設定ファイルは接続用のコピーにすぎません。
ファイル — レンダリングされたそのファイルが原本です。再レンダリング + 再起動でのみ変更されます。
起動env — プロセス起動時に注入されます。ランタイム変更APIがなく、再起動が唯一の反映手段です。

アカウント名（PP_*_USER）は変更しません。 --listに表示されるだけです。アカウント名の変更は、サーバー側のrole作成と権限移譲が伴う別の作業です。

--listに管理コンソールキー2つが見えない場合

PP_DATALAKE_ADMIN_PASSWORD · PP_DATALAKE_ADMIN_API_KEYは2026-09-05に追加されました。それ以前のインストールパッケージにはキーが9つしかありません。その場合、コンソールパスワードはサーバー側アカウントがないため、サイドカーを直接修正して再起動すればOKです → ウェブ画面ログインアカウント

手順 — 最初の1回

コミッショニング時には、登録されたキーすべてをランダム値に変更します。--allはpasswd.shではなく、ローテーションエンジンrotate-secret.shのオプションです。

cd /opt/kopens/plantpulse-platform-docker

bin/rotate-secret.sh --dry-run --all --generate   # 어떤 키가 걸리는지 확인 — 아무것도 안 바꾼다
bin/rotate-secret.sh --all --generate             # 실행. 키마다 20자 무작위 값
bin/passwd.sh --list --show                       # 결과 확인 — 값이 그대로 찍히니 화면 공유 중에는 치지 마세요

必ず点検ウィンドウで行ってください。ローテーション中に再起動が1回あり、Kafka/MQTT経路はその間切断されます。
作業前にバックアップを確保してください。
変更した値はサイドカー/etc/kopens/plantpulse-platform.envにのみあります。**引き継ぎ書類には値ではなく«誰が保管するか»**を記述してください。

手順 — 運用中に1つずつ

cd /opt/kopens/plantpulse-platform-docker
bin/passwd.sh --dry-run PP_PG_PASSWORD    # 계획 확인
bin/passwd.sh PP_PG_PASSWORD              # 프롬프트에 새 값 입력

終わったら確認します。

bin/status.sh                                                           # 0 = 정상
docker exec plantpulse-datalake pd node psql -c "SELECT 1;"             # 새 비밀번호로 실제 접속되나
docker exec plantpulse-datalake pd node cql -e "SELECT now() FROM system.local;"
curl -kfsS https://<server-ip>:4950/api/health | jq .status               # OK 또는 WARN

失敗した場合 — 同じコマンドを再実行

ローテーションはロールバックしません。 失敗時点ではどの値が有効か不確実で、戻そうとすると状態がさらに壊れます。代わりに前進復旧します。

ホストの/etc/kopens/rotation.journal(0600)に新・旧の値が先行記録されています。同じコマンドをそのまま再実行すると、各コンポーネントが現在どの値を受け入れるか判定（probe）して続行します。すでに変更されたものはスキップされます。

メッセージ	意味	対処
`probe=NEITHER`	新・旧どちらの値でも接続不可	自動化が判断する根拠がありません。人がそのコンポーネントに直接接続して状態を確認してください
`apply` 失敗	サーバー側変更失敗、即時停止	原因を修正して同じコマンドを再実行
`verify` 失敗	サーバーは変更されたが、新値で接続不可	最も危険です。ジャーナルが`APPLIED`として残ります — 人が確認する必要があります
`configure` 失敗	再起動せずに停止	意図された動作です（旧設定で起動するとすべて認証失敗）。原因を修正して再実行
`variable not in the registry`	登録されていないキー	下記ローテーションされない値

ワーカーノードがあると拒否します

クラスターワーカーが設定されている場合、ローテーションツールは拒否して停止します。ワーカーごとにサイドカーが別々にあり、マスターだけをローテーションするとワーカーが旧値のまま残り、クラスターが半分になります。ワーカーがある環境は手動手順に従い、ワーカーごとにサイドカー更新と再起動を繰り返してください。

`PP_MQ_PASSWORD` — KafkaとHiveMQは一緒に変わります

1つの値が2つのブローカーのサーバー側資格情報ストアであり、かつ全クライアントの接続パスワードです。個別には変更できず、ローテーションツールの検証は両方が新値で接続できて初めて成功とみなされます。

静的JAASは新・旧値を同時に受け入れられないため、ブローカーとコンシューマーが順次再起動される間、MQ経路が切断されます。 無停止ローテーションはサポート範囲外です。

`PP_HIVE_PASSWORD` — 1つの値が双方向で使われます

HiveメタストアがPostgreSQLに接続する際に提示する値であり、同時にクライアントがKyuubiに接続してくる際に検証する値です。そのため、ローテーションツールがPostgreSQLアカウント変更と設定再レンダリングの両方を行います。手動で片方だけ行うと、メタストアかKyuubiのどちらかが壊れます。

ローテーションされない値 — 手動で

レジストリにないキーを指定すると、静かにスキップせず拒否します。以下はまだ登録されていないもので、手動手順で変更します。

変数	何か	手動変更の要点
`PP_SPARK_PASSWORD`	Spark/Kyuubiクライアントアカウント	サーバーアカウントがありません。`hive-auth.properties`がこの値でアカウントを作成します — サイドカー更新 + 再起動
`PP_TSE_PASSWORD`	時系列エンジンアカウント	サイドカー更新 + 再起動
`PP_GRAVITINO_PASSWORD` · `PP_KESTRA_DB_PASSWORD`	それぞれのバックエンドPostgreSQLアカウント	データレイクが起動ごとにPostgreSQLロールパスワードをサイドカー値に合わせます — サイドカー更新 + 再起動
`PP_KESTRA_ADMIN_PASSWORD`	Kestra管理者	ウェブ画面ログインアカウント
`PP_TLS_KEYSTORE_PASSWORD` (+ truststore派生セット)	証明書一式	証明書再発行と絡んでいます → セキュリティ設定
`PP_OPCUA_PASSWORD`	OPC-UAサーバー (アプリコンテナ)	データレイク外
`PP_API_KEY` · `PP_FLOW_WEBHOOK_API_KEY`	外部呼び出し元用 (アプリコンテナ)	データレイク外
`PP_DATA_GATEWAY_WEB_PASSWORD` · `PP_CEP_WEB_PASSWORD`	クエリコンソールブラウザログイン	ローテーション対象外という決定です(2026-09-07)。サイドカー更新 + 再起動 → ウェブ画面ログインアカウント

してはいけないこと

コンテナ内でpd secret rotateを直接実行しないでください。 ローテーションジャーナルとサイドカーはホストに置かないと、コンテナ再作成に耐えられません。ホストのpasswd.shがそれを呼び出します。
bin/env.shのパスワードデフォルト値を修正して反映されることを期待しないでください。 サイドカーが勝ちます。
--list --showの出力をチケット・チャットに貼り付けないでください。
ローテーション中にCtrl+Cで切断し、別の値で再開しないでください。 ジャーナルが最初の値を覚えています。同じ値で再実行して終えてから、再度変更してください。

変更可能なキー​

手順 — 最初の1回​

手順 — 運用中に1つずつ​

失敗した場合 — 同じコマンドを再実行​

PP_MQ_PASSWORD — KafkaとHiveMQは一緒に変わります​

PP_HIVE_PASSWORD — 1つの値が双方向で使われます​

ローテーションされない値 — 手動で​

してはいけないこと​

関連ドキュメント​