Container Compute Service:クラスタ監査機能を使用してクラスタセキュリティO&Mを実施する

ステップ1：クラスタ監査を有効にする

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

1. ACKコンソールにログインします。左側のナビゲーションペインで、クラスタをクリックします。

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

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

ステップ2：監査ログレポートを表示する

ACKは、監査センターの概要、リソース操作の概要、リソース操作の詳細リスト、およびCommon Vulnerabilities and Exposures（CVE）脆弱性のリストを提供する4つの組み込み監査ログレポートを提供します。クラスタ監査ページで、名前空間またはRAMユーザーで監査イベントをフィルタリングし、レポートで次のコンテンツを表示できます。

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

概要

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

操作の概要

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

• コンピューティングリソース：Deployment、StatefulSet、CronJob、Job、およびPod。

• ネットワークリソース：ServiceおよびIngress。

• ストレージリソース：ConfigMap、Secret、およびPersistentVolumeClaim。

• アクセス制御リソース：Role、ClusterRole、RoleBinding、およびClusterRoleBinding。

操作の詳細

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

CVEの脆弱性

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

（オプション）ステップ3：詳細なログデータを表示する

1. ACKコンソールにログインします。左側のナビゲーションペインで、クラスタをクリックします。

2. クラスタページで、管理するクラスタを見つけ、その名前をクリックします。クラスタ詳細ページの左側のナビゲーションペインで、クラスタ情報をクリックします。

3. クラスタリソースタブで、ログサービスプロジェクトの横にあるプロジェクトIDをクリックします。ログストアリストで、audit-${clustered}という名前のログストアをクリックします。

   クラスタ作成プロセス中に、audit-${clustereid}という名前のログストアがプロジェクトに自動的に作成されます。

   重要

   デフォルトでは、インデックスはログストア用に構成されています。レポートが生成されない場合に備えて、インデックスは変更しないでください。

4. クエリステートメントを入力し、クエリする時間範囲（例：15分）を指定します。次に、検索と分析をクリックして、クエリ結果を表示します。

   監査ログは、次の方法でクエリできます。

   • RAMユーザーが実行した操作をクエリするには、RAMユーザーIDを入力し、検索と分析をクリックします。

   • リソースに対して実行された操作をクエリするには、コンピューティング、ネットワーク、ストレージ、またはアクセス制御リソースの名前を入力し、検索と分析をクリックします。

   • システムコンポーネントに関連する操作を除外するには、NOT user.username: node NOT user.username: serviceaccount NOT user.username: apiserver NOT user.username: kube-scheduler NOT user.username: kube-controller-managerを入力し、検索と分析をクリックします。

   ログデータのクエリ方法の詳細については、クエリメソッドをご参照ください。

（オプション）ステップ4：アラートを構成する

特定のリソースに対して操作が実行されたときに、リアルタイムでアラートを生成するようにログサービスを構成できます。サポートされているアラート通知方法には、DingTalkチャットボット、カスタムWebhook、およびAlibaba Cloudメッセージセンターが含まれます。詳細については、ログサービスでアラートルールを構成するをご参照ください。

例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\?.*', 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 "User account", 
  CASE WHEN json_array_length(sourceIPs) = 1 then json_format(json_array_get(sourceIPs, 0)) ELSE  sourceIPs END
  as "Source IP address" order by "Time" desc  limit 10000

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

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

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

• サンプルクエリステートメント：

  * | select ip as "Source IP address", total as "Number of times of Internet access", round(rate * 100, 2) as "Failure rate in percentage", failCount as "Number of times of illegal access", CASE when security_check_ip(ip) = 1 then 'yes' else 'no' end  as "Whether the IP address is risky",  ip_to_country(ip) as "Country", ip_to_province(ip) as "Province", ip_to_city(ip) as "City", ip_to_provider(ip) as "ISP" 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('7.0.07.0.X.Xip)) ORDER by "Number of times of Internet access" desc limit 10000

• 条件式はSource IP address =~ ".*"です。

次のステップ

ログサービスプロジェクトを変更する

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

1. ACKコンソールにログインします。左側のナビゲーションペインで、クラスタをクリックします。

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

3. クラスタ監査ページの右上隅にあるログサービスプロジェクトを変更をクリックして、監査ログを別のログサービスプロジェクトに移行します。

クラスタ監査を無効にする

次の手順を実行して、クラスタ監査を無効にできます。

1. ACKコンソールにログインします。左側のナビゲーションペインで、クラスタをクリックします。

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

3. クラスタ監査ページの右上隅にあるクラスタ監査を無効にするをクリックします。

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

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

ACKクラスタのクラスタ監査構成の概要

ACKクラスタのクラスタコンポーネントを構成する場合、コンソールはデフォルトでログサービスを有効にするを選択して、クラスタ監査を有効にします。イベントデータは監査ポリシーに基づいて収集され、バックエンドに書き込まれます。

監査ポリシー

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

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

apiVersion: audit.k8s.io/v1 # 必須。クラスタのKubernetesバージョンが1.24以降の場合はaudit.k8s.io/v1に設定し、Kubernetesバージョンが1.24より前の場合は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"]
  # 機密情報またはバイナリファイルを含む可能性のあるSecrets、ConfigMaps、およびTokenReview APIリクエストのルールを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名前空間のKubernetesコンポーネントによって実行されたエンドポイント操作、およびAPIサーバーから名前空間に送信されたGETリクエストを監査しません。

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

監査バックエンド

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