[第26回] Kubernetes設定は読み、変更は止める — QueryPieのロールとアクセスポリシー

Kubernetesの設定確認に変更権限まで必要とは限らない。障害調査や配備状況の確認は現状を読むだけで足りることも多い。

開発者へConfigMap参照を付与し、変更を禁止した。ブラウザ参照はでき、変更Applyはポリシーで拒否され、管理者は両方を監査で見られた。

実習Kubernetesクラスターを登録する

Macに別途作ったacp-kac-labを登録し、orders-labにkac-fixtureを作った。注文サービス設定の想定だ。ConfigMapはアプリ設定値を持つリソースである。

APIアドレスと接続情報を入れ、Verify CredentialのVerifiedを確認して保存した。Request Auditも有効にした。

設定参照用のロールを作る

Orders Lab ConfigMap Read Onlyでorders-labのConfigMapにget・list・watchを許可し、kac-fixtureのpatch・updateは拒否した。クラスター・種類・操作を分けて定義できた。

Orders Lab Viewerに接続してDemo Developerへ付与した。有効期限も確認でき、必要権限を一つの役割にまとめられて便利だった。

開発者で設定を開く

開発者がKubernetesでOrders Lab Viewerを選びConnectすると、ブラウザのWeb Clientが開いた。

Config & StorageのConfigMapでorders-labを選ぶとkac-fixtureがあり、YAMLのstatusはREADYだった。

クラスター全体の管理権限なしに必要設定を読めた。運用側が範囲を決め、利用者は役割を選んで確認する方式だ。

同じ設定の変更にはポリシーが働く

EditでREADYをQUERYPIE_CHANGE_TESTに変え、View Diffで一行を左右比較した。反映前の内容を確認しやすかった。

Applyで「QueryPie - Denied by policy to access the resource.」と出た。読むことはできても変更はQueryPieのポリシーで拒否された。

閉じて再読込するとREADYとリソースバージョンは不変だった。参照を続けられても、許可していない変更は反映されなかった。

実習ではKubernetes自体の権限は変更可能にしていた。その上のQueryPie参照ポリシーで拒否され、既存権限に業務別基準を追加管理できると分かった。

誰が何を変えようとしたかを監査する

Audit → Kubernetes → Request Auditに参照と変更が並び、詳細に利用者、ロール、クラスター、orders-lab/kac-fixtureが正確に残った。

Verbはupdate、Event TypeはDENY。理由とRequest BodyのQUERYPIE_CHANGE_TESTも確認できた。

遮断された事実だけでなく試行内容まで見られ、利用者へ聞く前に把握できる情報が多かった。

参照と変更を分けて運用する

変更後のgetはSuccess・ALLOW、Request Source Web Clientで、Kubernetesグループqp-kac-demoも確認できた。

「確認はするが変更は任せない」という業務をポリシーとロールで表せた。利用者はブラウザで確認し、管理者は変更と履歴を管理できた。

DBとサーバーに続き、Kubernetesでも同じ流れを経験した。複数資産の利用者権限と操作記録をまとめて扱える点は導入担当に有用だ。

QueryPie Community 11.6.7のWeb Client（Beta）、別実習クラスター、テスト値だけのConfigMapで行った。

参考： Kubernetesポリシー構文 · Web Client利用案内 · Request Audit