[第46回] QueryPieでサーバーアカウントのパスワードを変更する
2026年11月13日
変更後の接続確認と利用者への案内も必要で、サーバーが増えるといつどのアカウントを変えたかの管理も大変だ。
Password Provisioningで変更後、利用者で接続してコマンドを実行した。更新と接続を同じ体系で扱えるのが便利だった。
変更対象を決める
別Ubuntuと rotateops を用意した。ServersのConfigurationsで有効にすると、変更ジョブとアカウント管理を使えた。

専用グループには今回の1台だけを入れ、アカウントを QueryPie - Provisioning として登録した。保存後の認証方式は Managed by Jobで、変更ジョブで管理するアカウントと明確に分かった。

1台・1アカウントのジョブを作る
Password Provisioningで EP46 Rotate Test Accountを作り専用グループを指定した。Target Server 1、rotateopsで範囲を実行前に確認できた。
変更実行者と接続者は別にし、隔離実習サーバーの管理者が変更、利用者はrotateopsを使った。周期は Manualとした。

アカウント単位で結果を見る
Run JobはCompletedで、History詳細のrotateopsは Successだった。サーバー側でも実変更を確認した。

Account Managementにはサーバー・アカウント・用途と Last Password Updated Atがあり、今回は13:16:04だった。最後の更新を個別に確認でき、別集計より管理しやすそうだ。

新パスワードを入力せず接続する
利用者の役割でrotateopsがActiveと表示され、Connectだけで新パスワードを探さず接続できた。

whoami・hostname・pwdはrotateops、acp-ep46-password-lab、/home/rotateopsだった。変更後も正常に作業できた。

管理者が変更し利用者は付与済み権限で作業を続ける。新パスワードの個別配布を減らせる点がよかった。
パスワード管理と接続履歴を併せて残す
Server Access Historyに13:17:24のDemo Developer、EP46 Rotation Operator、rotateops、Successがあった。

変更はProvisioningとAccount Management、使った人はAccess Historyで確認できた。共通アカウントでもQueryPie利用者単位で追える。
1件の変更と新接続で、更新業務・利用者権限・履歴をまとめて管理できると分かった。定期管理しながら接続手順を簡単に維持できた。
![[第45回] コンテナ内の作業も再生して確認する](/assets/content/acp-lab-notes/pod-session-recording/01.webp)
![[第47回] 遮断されたSQL実行を通知で受け取る](/assets/content/acp-lab-notes/blocked-sql-alerts/01.webp)