[第44回] kubectlを使い続けながらアクセス範囲を分ける

Kubernetesを扱うならkubectlをよく使う。確認のたびWebへ移らず慣れたコマンドで見たい。

今回は Multi Agentとkubectlで実習クラスターへ接続することを試し、同じConfigMapへ参照と変更を送り、参照許可・変更禁止の制御を確認した。

設定は読み変更しない役割を選ぶ

既存の Orders Lab Viewer を使った。acp-kac-labのorders-labでConfigMap参照を許可し、 kac-fixtureのpatch・updateは明示的に禁止している。

管理者で見直すと、許可・拒否の対象と操作を分けて記述でき、設定確認担当向けの範囲だった。

Agent認証でkubectlを接続する

MacのMulti Agentで Kubernetes タブのOrders Lab Viewerを選ぶとManual Clustersにacp-kac-labが見え、役割と対象を確認できた。

Agentの Setting → Kubernetesにはkubeconfigの場所と設定案内がある。これはkubectlの接続先と認証方式を指定するファイルだ。

Agent生成の認証設定を基に、別の 実習用client.kubeconfigを用意し、ローカルProxyとqpctl認証を指定した。各コマンドで--kubeconfigを使った。

localhost:16444はこのMacのQueryPie Proxyで、APIサーバーとは区別した。準備後は通常kubectlで作業した。

ConfigMapは普段どおり参照できる

まず kubectl get configmapでkac-fixtureを参照し、名前とデータ数、statusの READYを確認した。

出力形式オプションも通常どおりで、新コマンド体系を覚えず認証・ポリシーを適用できた。

同じ設定への変更には制限が働く

実習値statusをEP44_CHANGEへ変えるため、 kubectl patch を送った。本番ではなく実習専用の設定値だ。

ターミナルに Forbiddenとともに “QueryPie - Denied by policy to access the resource.”と出た。読める設定でも制限された変更は通らなかった。

getで再確認すると値は READY、版は実習前と同じ 559で、変更されず参照を続けられた。

点検用の参照を開き、同じリソースの変更を役割で別管理できる点がよかった。

kubectl要求も監査で確認する

最後に管理者の Audit → Request Auditを開くと変更要求には Event Type DENYとVerb patchがあり、人・ロール・クラスター・名前空間・対象名も確認した。

Client Nameは kubectl/v1.36.1、Request Sourceは Third-Party Toolで、Request BodyにはEP44_CHANGEも残った。

同じ人・ロール・ConfigMapの再参照は、 get要求がSuccess・ALLOWとなり、端末結果と監査が一致した。

便利だったのは、 kubectlを維持しながら範囲を分け履歴を残せる点だ。運用者はCLIを続け、管理者は誰がどの役割でどの設定を扱ったか確認できた。

QueryPie Community 11.6.7、Multi Agent、kubectl 1.36.1、K3s 1.36.6で、人とConfigMapは実習用だ。

参考： QueryPie Multi Agentユーザー案内 · KubernetesポリシーYAML構文案内