クラスター監査機能を使用したクラスターセキュリティO&Mの実施 - Container Service for Kubernetes

APIサーバーは監査ログを生成し、Kubernetes APIのリクエストとレスポンスを記録します。 Container Service for Kubernetes (ACK) を使用すると、クラスター管理者はAPIサーバーの監査ログを分析して、さまざまなユーザーがリソースに対して実行した操作を監査できます。これにより、クラスター管理者はクラスター操作の履歴を追跡し、クラスター例外のトラブルシューティングを行うことができ、クラスターセキュリティのO&Mが大幅に簡素化されます。

使用上の注意

このトピックは、ACK管理クラスター、ACK専用クラスター、およびACKサーバーレスクラスターに適用されます。

登録済みクラスターでクラスター監査機能を使用する方法の詳細については、「クラスター監査の使用」をご参照ください。

課金

請求書の概要ページでは、監査ログデータに関する請求情報を表示できます。詳細については、「請求書の表示」をご参照ください。監査ログの課金方法の詳細については、「ペイバイ機能」をご参照ください。

手順1: クラスター監査の有効化

デフォルトでは、クラスターの作成時にLog Serviceの有効化が自動的に選択され、クラスター監査機能が有効になります。クラスター監査機能が無効になっている場合は、次の手順を実行して有効にします。

ACKコンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。左側のウィンドウで、[セキュリティ] > [クラスター監査] を選択します。

クラスターログまたはクラスター監査機能を有効にしていない場合は、画面上の指示に従って、Simple log Serviceプロジェクトを手動で選択し、機能を有効にします。

重要

Alibaba Cloudアカウント内の次のSimple Log Serviceクォータで十分であることを確認してください。そうしないと、クラスター監査機能の有効化に失敗します。

Simple Log Serviceプロジェクトのクォータ。
各Simple Log ServiceプロジェクトのLogstoreのクォータ。
各Simple Log Serviceプロジェクトのダッシュボードのクォータ。

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

ステップ2: 監査ログレポートの表示

重要

監査ログレポートは変更しないでください。監査ログレポートをカスタマイズする場合は、Simple log Serviceコンソールにログインして新しいレポートを作成します。

ACKには、監査センターの概要、リソース操作の概要、リソース操作の詳細なリスト、および共通の脆弱性と公開 (CVE) の脆弱性のリストを提供する4つの組み込み監査ログレポートがあります。 [クラスター監査] ページでは、監査イベントを名前空間またはRAMユーザーでフィルタリングし、次のコンテンツをレポートに表示できます。

チャートの右上にあるアイコンをクリックして、チャートをフルスクリーンモードで表示したり、クエリステートメントをプレビューしたりするなど、他の操作を実行することもできます。

概要

このレポートには、現在のACKクラスター内のすべてのイベントと、RAMユーザーの操作、インターネットアクセス、コマンドの実行、リソースの削除、シークレットアクセス、Kubernetes CVEの脆弱性などの重要なイベントに関する詳細情報が表示されます。

操作の概要

このレポートは、クラスター内のコンピューティングリソース、ネットワークリソース、およびストレージリソースに関連する一般的な操作に関する統計を提供します。操作には、リソースの作成、更新、削除、およびアクセスが含まれます。

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

资源操作概览

操作の詳細

このレポートは、リソースタイプに関する操作の詳細を提供します。リソースタイプを選択または入力して、操作の詳細をリアルタイムで照会できます。レポートには、操作の総数、名前空間の分布、操作の成功率、操作の経時的な傾向、およびその他の操作の詳細が表示されます。

资源操作详细列表

説明

Kubernetesに登録されているCustomResourceDefinition (CRD) リソースまたはレポートに記載されていないリソースに関連する操作をクエリするには、リソース名の複数形を入力します。たとえば、AliyunLogConfig CRDに関連する操作をクエリするには、AliyunLogConfigsと入力します。

CVEの脆弱性

このレポートには、現在のクラスターのKubernetes CVE脆弱性が表示されます。 RAMユーザーIDを選択または入力して、リアルタイムで情報を照会できます。指定したRAMユーザーに関連するKubernetes CVEの脆弱性がレポートに表示されます。 CVEの脆弱性とソリューションの詳細については、「 [CVE証券] CVE脆弱性の修正」をご参照ください。

(オプション) ステップ3: 詳細なログデータを表示する

クエリをカスタマイズしたり、監査ログデータを分析したりするには、Simple log Serviceコンソールにログインし、詳細なログデータを表示します。

説明

デフォルトでは、ACK管理クラスターのAPIサーバーの監査ログの保存期間は30日で、ACK専用クラスターのAPIサーバーの監査ログの保存期間は365日です。デフォルトの保持期間を変更する方法の詳細については、「Logstoreの管理」をご参照ください。

ACKコンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。左側のウィンドウで、[クラスター情報] をクリックします。
[クラスターリソース] タブで、[Log Serviceプロジェクト] の横にあるプロジェクトIDをクリックします。 Logstoresリストで、audit-${clustered} という名前のLogstoreをクリックします。
クラスターの作成プロセス中に、audit-${clustereid} という名前のLogstoreがプロジェクトに自動的に作成されます。
重要
デフォルトでは、インデックスはLogstoreに設定されます。レポートを生成できない場合は、インデックスを変更しないでください。
クエリステートメントを入力し、クエリする時間範囲 (15分など) を指定します。次に、[検索と分析] をクリックしてクエリ結果を表示します。
次の方法で監査ログを照会できます。
- RAMユーザーが実行した操作を照会するには、RAMユーザーIDを入力し、[検索と分析] をクリックします。
- リソースに対して実行された操作をクエリするには、コンピューティング、ネットワーク、ストレージ、またはアクセス制御リソースの名前を入力し、[検索と分析] をクリックします。
- システムコンポーネントに関連する操作を除外するには、NO T user.us ername: node NO T user.us ername: serviceaccount NO T user.us ername: apiserver NO T user.us ername: kube-scheduler NO T user.us ername: kube-controller-managerと入力し、[検索と分析] をクリックします。
ログデータのクエリ方法の詳細については、「クエリ方法」をご参照ください。

(オプション) 手順4: アラートの設定

特定のリソースで操作が実行されたときにリアルタイムでアラートを生成するようにSimple Log Serviceを設定できます。サポートされているアラート通知方法

DingTalkチャットボット, カスタムwebhook、およびAlibaba Cloud Message Center。詳細については、「Simple Log Serviceでのアラートルールの設定」をご参照ください。

例1: コンテナーでコマンドを実行したときにアラートを生成する

企業は、ユーザーがコンテナにログオンしたり、コンテナでコマンドを実行したりすることを禁止します。ユーザーがコンテナーでコマンドを実行すると、すぐにアラートが生成されます。アラートメッセージには、コンテナー、コマンド、ユーザー、イベント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 "Time", regexp_extract("requestURI", '([^\?]*)/exec \exec?) * ', 1)as "Resource", regexp_extract("requestURI", '\?(.*)', 1) を "Command" 、"responseStatus.code" を "Status code" 、
 ケース 
 「user.usの名前」のとき! ='kubernetes-admin' 、"user.us ername"
 WHEN "user.us ername" = 'kubernetes-admin' とregexp_like("annotations.authorization.k8s.io/reason" 、'RoleBinding') 、regexp_extract("annotations.authorization.k8s.io/reason" 、'to User "(\w +)" 、1)
 ELSE 'kubernetes-admin' END  
 「ユーザーアカウント」として、CASE WHEN json_array_length(sourceIPs) = 1 then json_format(json_array_get(sourceIPs, 0)) ELSE sourceIPs END
"Time" desc limit 10000

による "Source IP address" orderとして

条件式はEvent =~ ".*" です。

例2: APIサーバーがインターネットにアクセスできないときにアラートを生成する

クラスターでインターネットアクセスが有効になっています。攻撃を防ぐために、企業はインターネットアクセスの回数と失敗率を監視する必要があります。インターネットアクセス回数が閾値 (10) に達し、失敗率が閾値 (50%) を超えると、直ちにアラートが生成される。アラートメッセージには、送信元IPアドレスのリージョン、送信元IPアドレス、およびIPアドレスが危険かどうかに関する情報が含まれています。

サンプルクエリ文:

* | ipを「送信元IPアドレス」として選択し、合計を「インターネットアクセス回数」、ラウンド (レート * 100、2) を「失敗率 (パーセンテージ) 」、failCountを「違法アクセス回数」として選択します。ip_to_country(ip) を "Country" 、ip_to_province(ip) を "Province" 、ip_to_city(ip) を "City" 、ip_to_provider(ip) を "ISP" from (select CASE WHEN json_array_length(sourceIPs) = 1、次にjson_format (json_arraray_get (source0), IPSE))
ipとして、合計としてカウント (1) 、sum(CASE WHEN "responseStatus.code" < 400 then 0
ELSE 1 END) * レートとして1.0 /カウント (1) 、count_if("responseStatus.code" = 403) をfailCountとして
ip制限10000によるロググループからip_to_domain(ip) ! ='intranet' and ip not LIKE '%,%' and not try(is_subnet_of('7.0.0.0/8 ', ip)) 「インターネットアクセスの回数」による注文制限10000

条件式はソースIPアドレス=~ ".*" です。

次に何をすべきか

Simple Log Serviceプロジェクトの変更

監査ログを別のSimple Log Serviceプロジェクトに移行する場合は、クラスター監査でLog Serviceプロジェクトの変更機能を使用できます。

ACKコンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。左側のウィンドウで、[セキュリティ] > [クラスター監査] を選択します。
クラスター監査ページの右上隅にある [Log Serviceプロジェクトの変更] をクリックして、監査ログを別のSimple Log Serviceプロジェクトに移行します。

クラスター監査の無効化

クラスター監査を無効にするには、次の手順を実行します。

ACKコンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。左側のウィンドウで、[セキュリティ] > [クラスター監査] を選択します。
[クラスター監査] ページの右上隅で、[クラスター監査の無効化] をクリックします。

ACK専用クラスターでサードパーティのログサービスを使用する

監査ログの保存にはSimple Log Serviceを使用することを推奨します。サードパーティのログサービスを使用するには、クラスターの作成時にSimple log serviceを使用しないことを選択し、サードパーティのログサービスを統合して監査ログを収集および取得します。マスターノードの監査ログソースファイルは、/var/log/kubernetes/kubernetes.auditパスで取得できます。ファイルはJSON形式です。

ACK専用クラスターのクラスター監査設定の概要

ACK専用クラスターのクラスターコンポーネントを設定すると、コンソールはデフォルトでLog Serviceの有効化を選択してクラスター監査を有効にします。イベントデータは、監査ポリシーに基づいて収集され、バックエンドに書き込まれます。

監査ポリシー

監査ポリシーは、監査設定とログ収集ルールを定義します。異なる監査レベルのイベントログは、異なるログ収集ルールに基づいて収集されます。次の表に、監査レベルを示します。

監査レベル	ログ収集ルール
なし	ルールに一致するイベントは収集されません。
メタデータ	ユーザー情報やタイムスタンプなどのリクエストメタデータを収集します。リクエスト本文とレスポンス本文は収集されません。
リクエスト	リクエストメタデータとリクエスト本文を収集します。レスポンス本文は収集されません。このルールは、リソース以外のリクエストには適用されません。
RequestResponse	リクエストメタデータ、リクエスト本文、レスポンス本文を収集します。このルールは、リソース以外のリクエストには適用されません。

-- audit-policy-fileフラグを設定すると、次のYAMLファイルをAPIサーバーのブート構成として保存できます。マスターノードにログインした後、/etc/kubernetes/audit-policy.ymlディレクトリにある監査ポリシーファイルを表示できます。次のYAMLファイルは、監査ポリシーのサンプルです。

YAMLファイルの内容を表示する

apiVersion: audit.k8s.io/v1# 必須です。 Kubernetesバージョンのクラスターが1.24以降の場合はaudit.k8s.io/v1に設定し、Kubernetesバージョンのクラスターが1.24より前の場合はaudit.k8s.io/v1beta1に設定します。
kind: ポリシー
# RequestReceivedステージで監査イベントを生成する必要はありません。 
omitStages:
  -"RequestReceived"
ルール:
  # 次のタイプのリクエストは頻繁であり、これらのリクエストのリスクは低いです。 これらのリクエストをスキップするには、ルールを [なし] に設定することを推奨します。 
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # コア
        resources: ["endpoints", "services"]
  - level: None
    users: ["system:unsecured"]
    namespaces: ["kube-system"]
    verbs: ["get"]
    resources:
      - group: "" # コア
        resources: ["configmaps"]
  - level: None
    users: ["kubelet"] # legacy kubelet identity
    verbs: ["get"]
    resources:
      - group: "" # コア
        resources: ["nodes"]
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: "" # コア
        resources: ["nodes"]
  - level: None
    ユーザー：
      - system:kube-controller-manager
      - system:kube-scheduler
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: "" # コア
        resources: ["endpoints"]
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: "" # コア
        resources: ["namespaces"]
  # /healthz * 、/version * 、/swagger * などの読み取り専用URLの場合、ルールをNoneに設定します。 
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # イベントのルールをNoneに設定します。 
  - level: None
    resources: 
      - group: "" # コア
        resources: ["events"]
  # 機密情報またはバイナリファイルを含む可能性のあるSecrets、ConfigMaps、およびTokenReview APIリクエストのルールをメタデータに設定します。 
  - level: Metadata
    resources:
      - group: "" # コア
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # 応答には大量のデータが含まれる場合があります。 レスポンス本文が収集されないように、ルールをRequestに設定します。 
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: "" # コア
      - 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: "" # コア
      - 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"
  # ルールは、他のリクエストに対してデフォルトでメタデータに設定されます。 
  -level: メタデータ

説明

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

システムは、kube-proxy watchリクエスト、kubeletおよびsystem:nodesからノードに送信されるGETリクエスト、kube-system名前空間内のKubernetesコンポーネントによって実行されるエンドポイント操作、およびAPIサーバーから名前空間に送信されるGETリクエストを監査しません。

システムは、authentication、rbac、certificates、autocaling、およびstorage APIの読み取りと書き込みに基づいて、リクエストボディとレスポンスボディを記録します。

監査バックエンド

収集された監査イベントは、JSON形式のログファイルとしてバックエンドログファイルシステムに保存されます。 APIサーバーのブート設定として、次のフラグを設定できます。

説明

マスターノードにログインした後、/etc/kubernetes/manifests/kube-apiserver.yamlディレクトリにあるAPIサーバーの設定ファイルを表示できます。

フラグ	説明
`-- audit-log-maxbackup`	保存できる監査ログのシャードの最大数。デフォルト値は 10 です。
`-- audit-log-maxsize`	個々の監査ログの最大メモリストレージ。デフォルト値: 100 MB。
`-- audit-log-path`	監査ログの出力パス。デフォルト値: `/var/log/kubernetes/kubernetes.audit`
`-- audit-log-maxage`	監査ログの保持期間 (日数) 。デフォルト値 : 7
`-- audit-policy-file`	監査ポリシーファイルのパス。デフォルト値: `/etc/kubernetes/audit-policy.yml`

Container Service for Kubernetes:クラスター監査機能を使用したクラスターセキュリティO&Mの実施