[第29回] ログは確認し、コンテナのシェル接続は制限する

障害時はまずログを見る。ただ、全員にコンテナ内の実行権限が必要なわけではなく、調査と対処を分担する場合も多い。

第26回は設定の参照と変更を分けた。今回は同じPodでログを読み続けながらコンテナへ入る要求だけを制限できるか試した。

診断ログ用Podを用意する

acp-kac-labのorders-labにorders-diagnostics-demoを作り、架空注文のログを入れた。実顧客サービスではない。

Orders Lab Diagnostics Viewerを作って開発者へ付与した。Web ClientでPodとdiagnosticsの正常稼働を確認した。

詳細のLogsには状態確認、DEMO-2901の再試行・完了が出た。シェルなしで何が起きたか見られた。

まず同じ画面でシェル接続を確認する

分離前は実習ロールで両方許可し、同じPodのシェルが正常に使えると確認した。

ShellでidとEP29_QUERYPIE_EXEC_BASELINE_OKを出力し、正常接続を確認してexitした。これから実行権限だけを制限して比較する。

ログ参照と実行を別々に設定する

Orders Lab Pod DiagnosticsでPod検索・詳細を維持し、pods/logのgetも許可した。

orders-labのpods/execはget・createをDenyにした。同じPodでもログと実行を別に定められた。

エラーなしを確認し理由を書いて保存した。v2として残り、診断ロールも新版につながった。

ログは見えるがシェルは制限された

開発者がWeb Clientを開き直して同じPodを見ると、状態と再試行ログは正常に出た。

ShellはプロンプトではなくSocket connection closedになった。以前は実行できた同じ画面でも、制限後は中へ入れなかった。

ログ確認は続け、直接作業権限は別管理できた。障害確認を任せるためにシェルまで付けず、開発・運用業務に合う範囲を決められた。

許可参照と拒否要求の両方が残る

Request Auditにpods/exec、create、DENYと「Denied by policy to access the resource.」があり、QueryPieポリシーによる拒否を確認した。

同じ利用者・役割のログはpods/log、get、ALLOWだった。対象も同じPodで、何を許可・制限したか並べて見られた。

ログ担当へシェルまで与える必要はなかった。同じPodの参照と実行を分け、人・ロール別に結果を確認でき、必要参照を開きながら直接作業を別管理できる点がよかった。

QueryPie Community 11.6.7のWeb Client（Beta）と別K3sを使用。注文とログはすべて実習用だ。

参考： Kubernetes Web Client · Kubernetesポリシー設定のヒント · Request Audit