(10.2.0-ja) クーバネティスポリシー YAML コード構文

QueryPie アクセス制御ポリシーの概要

QueryPie で定義されたアクセス制御ポリシーは、拡張属性ベースアクセス制御 (EABAC) に基づいて動作します。EABAC は、QueryPie ユーザーの役割と属性に基づいて、QueryPie に登録されたリソースへのアクセスを制御し、権限の包括的な管理を可能にします。役割ベースのアクセス制御 (RBAC) と属性ベースのアクセス制御 (ABAC) の機能を組み合わせ、柔軟で洗練されたアクセス制御を提供します。すべてのポリシーは、All Deny の原則の下で運用されます。

EABAC は 2つのコンポーネントを通じて機能します: ロールは GUI で設定され、ポリシーは YAML コードで定義・管理されます。

クーバネティスポリシーについては、クーバネティスに存在する Namespace に限定されたロールベースの制限と、Namespace のスコープを超えたリソースをサポートする ClusterRole の両方に対応する包括的なモデルが開発されています。

クーバネティスポリシーの YAML 基本構造

全体的なポリシーコード構造は、いくつかの例外を除いて、ほとんどのポリシー項目でワイルドカード（"*"）と正規表現 (RE2 形式: ^$を指定する必要があります) パターンをサポートしています。

リソースの仕様

resourcesフィールドは、クーバネティスリソースそのものではなく、QueryPieに登録されているクーバネティスクラスターを定義します。

1. resourcesフィールドの定義は必須です。 必須

2. クーバネティスクラスター名に基づく必要があります。

   • フォーマット"cluster:{QueryPieにおけるクーバネティスクラスタ名}"

3. クーバネティスクラスター名は以下のような構造になっています:

   • 最大100文字

   • 英数字 (大文字と小文字を区別) 、数字、および以下の特殊文字が使用できます:

     • アンダースコア (_)

     • ハイフン (-)

   • 名前は英数字または数字で始まり、数字で終わる必要があります。

   • クラスター名は一意でなければならない

4. 1つのポリシー内で複数のクーバネティスクラスターを指定できます。

   • - "cluster:kubepie-dev-1"
- "cluster:kubepie-dev-2"

   • ["cluster:kubepie-dev-1", "cluster:kubepie-dev-2"]

5. ワイルドカードでの書き込みが可能です。

   • "cluster:kubepie-dev-*"

6. 正規表現で記述可能です。

   • "cluster:^kubepie-dev-.*$"

サブジェクトの指定

subjectsは、クーバネティスコマンド内でなりすますためのクーバネティスユーザ/グループを定義します。spec:allowにのみ適用され、spec:denyでは構文的に許可されません。

1. kubernetesGroups： 必須

   • リソースに対して API アクションを実行するために QueryPie プロキシーがなりすますクーバネティスグループアカウントを定義します。

     • これらのサブジェクトはポリシー全体のレベルで定義する必要があり、少なくとも1つの割り当てが必要です。

       • これらのサブジェクトを使用したなりすましは、異なるポリシー間で単一のロール内に入れ子にすることができます。

     • Resourcesで指定したリソースに対してアクションを実行する権限を持つクーバネティスグループ (単一または複数) を指定します。

       kubernetesGroups: - system:masters - default-group-account

2. impersonation: オプション

   • クライアント側で--asおよび--as-groupパラメータを持つkubectlのようなクーバネティスコマンドで、なりすましを許可するユーザーまたはグループを指定します。

     • users: as パラメーターによるなりすましが許可される、クラスター内に存在するクーバネティスユーザーまたはサービスアカウントを一覧表示します。

     • groups: "--as-group " パラメータによるなりすましが許可される、クラスタ内に存在するクーバネティスグループをリストアップします。

       impersonation: users: - "system:serviceaccount:argocd" groups: - "system:admin"

     • ワイルドカードが許可されます（"*"）。

アクション指定

クーバネティスクラスター API サーバ内で許可または拒否するリソース APIリストを指定します。各アクションには、apiGroups、resources、namespace、name、verbsのエントリが必要です。

1. apiGroups: クーバネティス API グループのリストを定義します。

   1. API グループを定義することで、API グループごとにきめ細かいアクセス制御が可能になる。

   2. カスタムリソースの制御が必要な場合は、apiGroupsで指定する。

   3. 参考文献

      1. APIの概要 - APIグループ

      2. クーバネティス API リファレンスドキュメント - API グループ

   4. ワイルドカード "*" を使用することで、API グループ全体を包括的に指定することができます。

      • apiGroups: ["*"]

2. resources: クーバネティスリソースのリストを定義します。

   1. よく使われるリソースは以下の通りです:

      • pods, pods/exec, pods/log, pods/portforward, services, ingresses, deployments, replicasets, statefulsets, daemonsets, configmaps, secrets, namespaces, nodes, persistentvolumes, persistentvolumeclaims, jobs, cronjobs, serviceaccounts, endpoints, roles, rolebindings, clusterroles, clusterrolebindings

   2. リストにないリソースもポリシーに含めることができます。

   3. Namespace 固有のリソースにのみ権限を付与する場合、Namespace への読み取り専用アクセスが自動的に含まれます。したがって、リソース API 呼び出しのたびに Namespace を指定する必要はありません。特定の Namespace へのアクセス許可を与えないようにするには、spec:deny でNamespace ・リソースに対するアクセス拒否を設定します。

   4. 1つのポリシーアクション内で複数のリソースを指定できます:

      resources: - "pods" - "deployments" - "configmaps"

   5. ワイルドカードを使用できます。("*")

3. namespace: 対象の名前空間を定義します。

   1. クラスタ内の指定された Namespace へのアクセスを制御するために、アクションで Namespace を指定します。

   2. ワイルドカードと正規表現の両方がサポートされます。

      • 名前空間を指定します："*"

   3. Namespace 以外の Namespace で永続化しないリソースの場合は、Namespace を指定する必要はありません。

      1. 例えば、persistentvolumes, persistentvolumeclaims, serviceaccounts, customresourcedefinitions, endpoints, node, clusterroles,clusterrolebindingsなどです。

4. name: クラスタ内のリソース命名規則に基づいて制御を有効にするターゲット・リソース名を定義します。

   1. ワイルドカードと正規表現の両方をサポートしています。

      • name: "pods-*"

5. verbs: 操作を許可または拒否するクーバネティス API パーミッションを指定します。

   • 一般的に使用される動詞は以下のとおりです：

     • get: リソース情報を取得する

     • list: リソースをリストアップする

     • watch:リソースの変更を監視する

     • create: 新しいリソースを作成する

     • update: 既存のリソースを更新する

     • patch: リソースを部分的に変更する

     • delete: リソースを削除する

     • deletecollection: 一度の操作で複数のリソースを削除する

   • リストにない特殊な動詞も、ポリシーで指定および適用できます。

   • サードパーティクライアントをサポートする場合、以下の動詞は必須であり、提供されるべきです:

     • 表示権限 :get, list, watch

     • 編集権限 :get, list, watch+create, update, patch, delete, deletecollection

   • pod execコマンドでコンテナシェルにアクセスするセッションを作成する場合は、通常、get, createverb を指定する必要があります。

   • ワイルドカードも使用できます。

     • verbs:["*"]

条件の指定

conditionsセクションで、resourceTags, userAttributes, ipAddressesを使って条件を定義することができます。 オプション

• resourceTags: リソースタグを使用して、キーと値のペアに基づいてリソースをフィルタリングします。

  resourceTags: "region": "ap-northeast-1" "Owner": "Brant"

• userAttributes: ユーザー属性を定義して、指定された条件に一致する属性を持つユーザーにポリシーの許可を制限します。

  userAttributes: "countryCode": "KR" "department": "Infra"

• ipAddresses: IP アドレスまたは CIDR ブロックを指定して、ソース IP に基づいてリソースへのアクセスを制御します。

  ipAddresses: ["10.10.0.0/24", "10.11.10.1"]

KACポリシーの例