クラスター API サーバー監査機能の使用 - Container Compute Service

監査は、Kubernetes API サーバーへのリクエスト (リクエストとその結果を含む) を記録します。Container Service for Kubernetes (ACK) は、クラスター管理者が誰が、いつ、どのリソースに対して何を行ったかを判断するのに役立つ API サーバー監査ログを提供します。これらのログを使用して、クラスターの運用履歴の追跡、問題のトラブルシューティング、セキュリティオペレーションの効率化が可能です。

ステップ 1：API サーバー監査の有効化

ACK クラスターを作成する際、デフォルトで Log Service の使用 オプションが選択されており、API サーバー監査機能が有効になります。クラスター作成時にこの機能を有効にしなかった場合は、次の手順に従って有効にしてください。

ACS コンソールにログインします。左側のナビゲーションペインで、クラスター をクリックします。
クラスター ページで、管理するクラスターを見つけ、その ID をクリックします。クラスター詳細ページの左側のナビゲーションペインで、セキュリティ > クラスター監査 を選択します。

クラスターのロギングまたは監査が無効になっている場合は、画面の指示に従って手動で SLS プロジェクトを選択し、機能を有効にしてください。

重要

アカウントに十分な Log Service (SLS) のリソースクォータがあることを確認してください。クォータを超えると、クラスター監査機能を有効にできません。

作成できる SLS プロジェクト数のクォータ。
1 つの SLS プロジェクトで作成できる Logstore 数のクォータ。
1 つの SLS プロジェクトで作成できるダッシュボード数のクォータ。

SLS のクォータとその調整方法の詳細については、「リソースクォータの調整」をご参照ください。

ステップ 2：監査レポートの表示

重要

組み込みの監査レポートは変更しないでください。カスタムレポートを作成する必要がある場合は、Log Service (SLS) コンソールを使用してください。

ACK は、クラスター監査概要、操作一覧、操作詳細リスト、および Kubernetes CVE セキュリティリスクの 4 つの組み込み監査ログレポートを提供します。クラスター監査 ページでは、名前空間や RAM ユーザーなどのディメンションで監査イベントをフィルタリングし、レポートを使用して次の情報を取得できます。

結果を取得した後、チャートの右上隅にあるアイコンをクリックすると、チャートの全画面表示や対応するクエリ・分析文のプレビューなど、追加のアクションを実行できます。

[クラスター監査概要]

クラスター監査概要 レポートには、ACK クラスター内のイベントの全般的なサマリーと、RAM ユーザーの操作、パブリックネットワークアクセス、コマンド実行、リソース削除、Secret へのアクセス、Kubernetes CVE セキュリティリスクなどの重要なイベントに関する詳細が表示されます。

[操作一覧]

操作一覧 レポートには、一般的な ACK クラスターのコンピューティング、ネットワーク、ストレージリソースに対する作成、更新、削除、アクセスなどの操作の統計が表示されます。これには以下が含まれます：

コンピューティングリソース：Deployment、StatefulSet、Job、CronJob、Pod、DaemonSet。
ネットワークリソース：Service、Ingress。
ストレージリソース：ConfigMap、Secret、PersistentVolumeClaim。
アクセス制御リソース：Role、ClusterRole、RoleBinding、ClusterRoleBinding。

[操作詳細リスト]

このレポートには、ACK クラスター内の特定のリソースタイプの操作の詳細リストが表示されます。リソースタイプを選択または入力して、リアルタイムクエリを実行します。レポートには、各操作タイプのイベント総数、名前空間全体の分布、成功率、時系列トレンド、および操作の詳細リストが表示されます。

説明

Kubernetes に登録されている CustomResourceDefinition (CRD) リソースや、リストにない他のリソースを表示するには、リソース名の複数形を手動で入力します。たとえば、AliyunLogConfig という名前の CRD リソースの場合、AliyunLogConfigs と入力します。

Kubernetes CVE セキュリティリスク

このレポートには、現在のクラスターにおける潜在的な Kubernetes CVE セキュリティリスクが表示されます。RAM ユーザー ID を選択または入力して、リアルタイムクエリを実行します。レポートには、指定されたアカウントに関連する Kubernetes CVE セキュリティリスクが表示されます。CVE の詳細と解決策については、「[CVE セキュリティ] 脆弱性修正のお知らせ」をご参照ください。

(任意) ステップ 3：詳細なログレコードの表示

カスタムクエリの実行や監査ログの分析が必要な場合は、Log Service (SLS) コンソールで詳細なログレコードを表示できます。

説明

デフォルトでは、ACK クラスターからの API サーバー監査ログは、Log Service (SLS) 内の対応する Logstore に 30 日間保存されます。データ保持期間を変更するには、「Logstore の管理」をご参照ください。

ACS コンソールにログインします。左側のナビゲーションペインで、クラスター をクリックします。
クラスター ページで、管理するクラスターを見つけ、その名前をクリックします。クラスター詳細ページの左側のナビゲーションペインで、クラスター情報 をクリックします。
[Basic Information] タブをクリックします。クラスターリソース セクションで、Log Service プロジェクト の横にあるプロジェクト ID をクリックします。プロジェクトリストで、[audit-${clusterid}] という名前の Logstore をクリックします。

クラスター作成時に、audit-${clusterid} という名前の Logstore が指定された SLS プロジェクトに自動的に追加されます。

重要
監査ログ用の Logstore には、事前設定されたインデックスがあります。インデックスを変更しないでください。変更すると、レポートが無効になる可能性があります。
検索ボックスにクエリ・分析文を入力し、過去 15 分などの時間範囲を指定してから、[Search & Analyze] をクリックして結果を表示します。

以下に、監査ログの一般的な検索方法を説明します：
- 特定の RAM ユーザーの操作記録を照会するには、RAM ユーザー ID を入力して [Search & Analyze] をクリックします。
- 特定のリソースに対する操作を照会するには、コンピューティング、ネットワーク、ストレージ、またはアクセス制御リソースの名前を入力して [Search & Analyze] をクリックします。
- システムコンポーネントからの操作を除外するには、NOT user.username: node NOT user.username: serviceaccount NOT user.username: apiserver NOT user.username: kube-scheduler NOT user.username: kube-controller-manager と入力し、[Search & Analyze] をクリックします。
クエリと分析の方法に関する詳細については、「Log Service のクエリと分析」をご参照ください。

(任意) ステップ 4：アラートの設定

特定のリソースに対する操作についてリアルタイムでアラートを受信する必要がある場合は、Log Service (SLS) のアラート機能を使用できます。サポートされている通知方法には、DingTalk チャットボット、カスタム Webhook、通知センターなどがあります。詳細については、「Log Service のアラート作成」をご参照ください。

例 1：コンテナ内でのコマンド実行に関するアラート

ある企業では、厳格な Kubernetes クラスターの使用ポリシーがあり、ユーザーがコンテナにログインしたり、コンテナ内でコマンドを実行したりすることは許可されていません。ユーザーがコマンドを実行した場合、直ちにアラートが送信されます。アラート通知には、アクセスされた特定のコンテナ、実行されたコマンド、オペレーター、イベント ID、タイムスタンプ、ソース IP アドレスなどの情報を含める必要があります。

クエリ・分析文：

verb : create and objectRef.subresource:exec and stage:  ResponseStarted | SELECT auditID as "Event ID", date_format(from_unixtime(__time__), '%Y-%m-%d %T' ) as "Operation Time",  regexp_extract("requestURI", '([^\?]*)/exec\?.*', 1)as "Resource",  regexp_extract("requestURI", '\?(.*)', 1)as "Command" ,"responseStatus.code" as "Status Code",
 CASE 
 WHEN "user.username" != 'kubernetes-admin' then "user.username"
 WHEN "user.username" = 'kubernetes-admin' and regexp_like("annotations.authorization.k8s.io/reason", 'RoleBinding') then regexp_extract("annotations.authorization.k8s.io/reason", ' to User "(\w+)"', 1)
 ELSE 'kubernetes-admin' END  
 as "Operator Account", 
CASE WHEN json_array_length(sourceIPs) = 1 then json_format(json_array_get(sourceIPs, 0)) ELSE  sourceIPs END
as "Source Address" order by "Operation Time" desc  limit 10000

トリガー条件："Event ID" =~ ".*"。

例 2：パブリック API サーバーへのアクセス失敗に関するアラート

あるクラスターでは、パブリックアクセスが有効になっています。悪意のある攻撃を防ぐために、パブリックアクセスの試行回数と失敗率を監視する必要があります。アクセス試行回数が指定されたしきい値 (例：10) に達し、失敗率が指定されたしきい値 (例：50%) を超えると、直ちにアラートが送信されます。アラート通知には、ユーザーの IP アドレスの地域、ソース IP アドレス、それが高リスク IP アドレスであるかどうかなどの情報を含める必要があります。

クエリ・分析文：

* | select ip as "Source Address", total as "Access Count", round(rate * 100, 2) as "Failure Rate %", failCount as "Illegal Access Count", CASE when security_check_ip(ip) = 1 then 'yes' else 'no' end  as "Is High-Risk IP",  ip_to_country(ip) as "Country", ip_to_province(ip) as "Province", ip_to_city(ip) as "City", ip_to_provider(ip) as "Carrier" from (select CASE WHEN json_array_length(sourceIPs) = 1 then json_format(json_array_get(sourceIPs, 0)) ELSE  sourceIPs END
as ip, count(1) as total,
sum(CASE WHEN "responseStatus.code" < 400 then 0 
ELSE 1 END) * 1.0 / count(1) as rate,
count_if("responseStatus.code" = 403) as failCount
from log  group by ip limit 10000) where ip_to_domain(ip) != 'intranet' and ip not LIKE '%,%' and not try(is_subnet_of('<your_subnet_ip_address>')) ORDER by "Access Count" desc limit 10000

トリガー条件："Source Address" =~ ".*"。

参考：API サーバーの監査設定

ACK クラスターの作成中にクラスターコンポーネントを設定する際、デフォルトで Log Service の使用 が選択されています。これにより、API サーバー監査機能が有効になり、監査ポリシーに基づいてイベントデータを収集してバックエンドに書き込みます。

監査ポリシー

イベントログの収集ルールは、監査レベルによって異なります。

監査レベル	ログ収集ルール
None	ルールに一致するイベントは収集されません。
Metadata	リクエストメタデータ (ユーザー情報やタイムスタンプなど) は収集しますが、リクエストまたはレスポンスのボディは収集しません。
Request	リクエストメタデータとリクエストボディを収集しますが、レスポンスボディは収集しません。これは、非リソースリクエストには適用されません。
RequestResponse	リクエストメタデータ、リクエストボディ、およびレスポンスボディを収集します。これは、非リソースリクエストには適用されません。

次の監査ポリシーを YAML ファイルとして保存し、--audit-policy-file 起動フラグを使用して API サーバーに適用してください。

YAML ファイルのサンプル

apiVersion: audit.k8s.io/v1 # 必須。Kubernetes v1.24 以降を実行するクラスターには audit.k8s.io/v1 を、それ以前のバージョンを実行するクラスターには audit.k8s.io/v1beta1 を使用します。
kind: Policy
# RequestReceived ステージのリクエストに対しては監査イベントを生成しません。
omitStages:
  - "RequestReceived"
rules:
  # 次のタイプのリクエストは頻繁に発生し、潜在的なリスクが低いです。監査をスキップするために、レベルを None に設定することを推奨します。
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # core
        resources: ["endpoints", "services"]
  - level: None
    users: ["system:unsecured"]
    namespaces: ["kube-system"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["configmaps"]
  - level: None
    users: ["kubelet"] # レガシー kubelet ID
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    users:
      - system:kube-controller-manager
      - system:kube-scheduler
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: "" # core
        resources: ["endpoints"]
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["namespaces"]
  # /healthz*、/version*、/swagger* などの読み取り専用 URL については、監査をスキップするためにレベルを None に設定します。
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # イベントの監査をスキップするには、レベルを None に設定します。
  - level: None
    resources: 
      - group: "" # core
        resources: ["events"]
  # Secret、ConfigMap、TokenReview など、機密情報やバイナリファイルを含む可能性のあるインターフェイスについては、レベルを Metadata に設定します。
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # リクエストは大量のデータを返す可能性があります。レスポンスボディを収集しないように、レベルを Request に設定します。
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # 既知の Kubernetes API の場合、リクエストとレスポンスのボディを返すように、レベルはデフォルトで RequestResponse に設定されます。
  - level: RequestResponse
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # 他のすべてのリクエストについては、レベルはデフォルトで Metadata に設定されます。
  - level: Metadata

説明

リクエストが受信された後、ロギングはすぐには開始されません。レスポンスヘッダーが送信された後に開始されます。

システムは、kube-proxy の watch リクエスト、kubelet および system:nodes からのノードに対する GET リクエスト、kube-system コンポーネントによるエンドポイントに対する操作、API サーバーからの名前空間に対する GET リクエストなど、多数の冗長なリクエストを監査しません。

authentication、rbac、certificates、autoscaling、storage などの機密性の高いインターフェイスの読み取りおよび書き込み操作については、システムは対応するリクエストとレスポンスのボディを記録します。

監査バックエンド

監査バックエンドは、収集されたイベントを標準の JSON 形式のログファイルとして保存します。

Container Compute Service:クラスター API サーバー監査機能の使用