KubernetesポリシーYAML Code文法ガイド

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

QueryPieで定義するアクセス制御ポリシーはEABAC（Enhanced Attribute Based Access Control）に基づいて動作します。 EABACはQueryPieユーザーの役割（Role）と属性（Attribute）に基づき、QueryPieに登録されたリソースへのアクセスを制御し、権限管理を実行できるポリシーの統制方式を意味します。 RBAC（Role-Based Access Control）およびABAC（Attribute-Based Access Control）の機能を組み合わせて、より柔軟で精巧なアクセス制御を提供します。 すべてのポリシーはAll Denyを前提に動作します。

EABACはRole、Policyの2つで動作します。 Role設定はGUIで行い、Policy定義はコード（YAML）で管理します。

Kubernetesポリシーの場合、実際のKubernetesに存在するネームスペースに限定されるRoleとネームスペース範囲外のリソースをサポートするClusterRoleの両方を受容できる総合的なモデルとしてスペックが制作されました。

KubernetesポリシーYAML基本構造

一部の項目を除いた全般的なポリシーコードでワイルドカード（”*“）および正規表現（RE2形式 ：^$の明示が必須）パターンをサポートします。

Resourcesの指定方法

resourcesは Kubernetesのリソースではなく QueryPieに登録されたKubernetesクラスターに対するリソースを定義します。

1. 該当resourcesフィールドの定義は必須です。 required
2. Kubernetesクラスター名に基づいて入力します。
   • "cluster:{Kubernetes Cluster Name in QueryPie}"
3. Kubernetesクラスター名は以下の基準で定められます。
   • 文字長100文字制限
   • アルファベット大文字小文字（case-sensitive）、数字および以下の特殊記号のみ許可
     • underscore (_)
     • hyphen (-)
   • 名前の先頭と末尾はアルファベット大文字小文字または数字に制限
   • クラスター名の重複は制限
4. Kubernetesクラスターは単一ポリシーで複数指定が可能です。
   • - "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の指定方法

subjectsはKubernetesコマンドをimpersonateするKubernetes内のユーザー/グループを定義します。subjectsはspec:allowに限り適用が必要なフィールドであり、spec:denyでは文法的に許可されません。

1. kubernetesGroups: required
   • リソースに対するAPI実行のためにQueryPie Proxyがimpersonateするkubernetesグループアカウントを定義します。
     • 該当subjectsはPolicy-wideレベルで定義でき、最低1つが割り当てられるように定義する必要があります。
       • Impersonationのための該当subjectsは他のPolicyと1つのRole内で重複が可能です。
     • Resourcesに明示されたリソースに対する権限実行が可能なkubernetes側グループ（単一または複数）を定義します。

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

     • kubernetesGroupsにはQuerypie UserのGroupを予約語形式で入力できます。この場合、UserのGroupはダブルクォーテーション（“）なしで入力する必要があり、ユーザーがPolicyを閲覧する際は実際のuser Groupの値が表示されます。

       kubernetesGroups:
         - $user.groups

2. impersonation: OPTIONAL
   • ユーザーがクライアント側でkubernetes内の特定serviceaccountなどの権限でkubectlコマンドにimpersonation（—as、—as-group）を試みる場合、これに対する呼び出し許可リストを定義します。
     • users: Kubernetes内に存在するユーザー/サービスアカウントで「—as」パラメータに許可可能な値を列挙します。
     • groups: Kubernetes内に存在するグループアカウントで「—as-group」パラメータに許可可能な値を列挙します。

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

     • ワイルドカードを許可します。（"*"）

Actionsの指定方法

クラスターAPIサーバー内で許可するResource APIリストを明示します。 各actionにはapiGroups、resources、namespace、name、verbsの入力が必要です。

1. apiGroups : Kubernetes APIグループリストを定義します。
   1. APIグループを定義することで、より詳細な権限制御がAPIグループごとに可能になります。
   2. カスタムリソースに対する制御が必要な場合、apiGroupsに明示してカスタムリソースに限定した制御も可能です。
   3. 参考：
      1. API Groupsガイド  
      2. API Groupリスト 
   4. ワイルドカードを許可してAPIグループ全体を包括的に指定することが可能です。
      • apiGroups: ["*"]
2. resources : Kubernetesリソースリストを定義します。
   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に対するReadOnly権限が併せて付与されます。そのため、リソース呼び出し時に毎回ネームスペースを明示する必要がある事例は発生しません。特定のネームスペースに対する権限付与を防止したい場合、spec:denyでネームスペースリソースに対するアクセス拒否を設定できます。
   4. 単一ポリシーアクションで複数のリソース指定が可能です。

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

   5. ワイルドカードを許可します。（"*"）
3. namespace : 対象ネームスペースを定義します。
   1. ネームスペースをアクションで定義することで、クラスター内の許可対象ネームスペースをリソースごとに制御できます。
   2. ワイルドカードと正規表現の両方を許可します。
      • namespace: "*"
   3. namespaces以外のネームスペースに属さないリソースの場合、該当namespaceを記述しなくても構いません。
      1. 対象例）persistentvolumes、persistentvolumeclaims、serviceaccounts、customresourcedefinitions、endpoints、nodes、clusterroles、clusterrolebindingsなど
4. name : 対象リソース名を定義して、クラスター内の許可リソースの中からネーミングに基づいて制御が可能です。
   1. ワイルドカードと正規表現の両方を許可します。
      • name: "pods-*"
5. verbs : 操作を許可または拒否するkubernetes内のAPI権限を明示します。
   • 一般的に呼び出されるverbは以下のとおりです：
     • get: リソース情報の検索
     • list: リソースリストの列挙
     • watch: リソース変更の監視
     • create: 新しいリソースの作成
     • update: 既存リソースの更新
     • patch: リソースの部分修正
     • delete: リソースの削除
     • deletecollection: 単一操作での複数リソースの削除
   • 上記に記載されていない特殊なverbがあっても、ポリシーに明示して適用が可能です。
   • 3rd-Partyクライアントサポート時に以下のverbが必須で要求されます：
     • View権限 : get, list, watch
     • Edit権限 : get, list, watch + create, update, patch, delete, deletecollection
   • pod execコマンドによるコンテナシェルアクセスセッションの作成には、一般的にcreate verbの明示が必要です。
   • ワイルドカードを許可します。
     • verbs: ["*"]

Conditionsの指定方法

conditions項目にはresourceTags、userAttributes、ipAddressesを条件として定義できます。 OPTIONAL

• resourceTags : タグ項目ではリソースタグのキーと値でフィルタリングできます。

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

• userAttributes : ユーザーの属性（attribute）を条件として指定し、値がマッチするユーザーに限り該当ポリシーで定義された権限の使用を制限します。

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

• ipAddresses : リソースに対するIPアクセス制御条件リストを単一IP、CIDR形式で定義します。

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

KAC Policyの例

apiVersion: kubernetes.rbac.querypie.com/v1
kind: KacPolicy

spec:
  allow:
    resources:
      - "cluster:*"
    subjects:
      kubernetesGroups:
        - "system:masters"
      impersonation:
        users: ["system:serviceaccount:argocd"]
        groups: ["system:admin"]
    actions:
      - apiGroups: ["*"]
        resources:
          - "pods"
        namespace: "*"
        name: "*"
        verbs: ["get", "list", "watch"]
    conditions:
      resourceTags:
        "Owner": ["Kenny", "Brant"]
        "Team": "DevSecOps"
      userAttributes:
        "countryCode": "KR"
        "department": "Infra"
      ipAddresses: ["10.10.0.0/24", "10.11.10.1"]
  deny:
    resources:
      - "cluster:kubepie-*"
    actions:
      - apiGroups: ["*"]
        resources:
          - "*"
        namespace: "production"
        name: "*"
        verbs: ["*"]
    conditions:
      resourceTags:
        "Owner": "Brant"