EKS Protection の検出結果の修復

フォーカスモード

EKS Protection の検出結果の修復 - Amazon GuardDuty

潜在的な設定の問題侵害された可能性のある Kubernetes ユーザーの修復侵害された可能性のある Kubernetes ポッドの修復侵害された可能性のあるコンテナイメージの修復侵害された可能性のある Kubernetes ノードの修復

Amazon GuardDuty は、アカウント用に EKS Protection が有効になっている場合に、Kubernetes のセキュリティ問題の可能性を示す検出結果を生成します。詳細については、「EKS Protection」を参照してください。次のセクションでは、これらのシナリオにおいて推奨される修復ステップについて説明します。特定の修復アクションは、その特定の検出結果タイプのエントリで説明されています。検出結果タイプに関する完全な情報にアクセスするには、[Active findings types table] (アクティブな検出結果タイプテーブル) を選択します。

EKS Protection の検出結果タイプのいずれかが予想どおりに生成された場合は、今後アラートが発生しないように GuardDuty の抑制ルールを追加することを検討してください。

さまざまなタイプの攻撃と設定の問題によって、GuardDuty EKS Protection の検出結果がトリガーされる可能性があります。このガイドは、適切な修復ガイダンスを概説するものであり、クラスターに対する GuardDuty の検出結果の根本原因を特定するのに役立ちます。GuardDuty の Kubernetes の検出結果につながる主な根本原因は次のとおりです。

潜在的な設定の問題
侵害された可能性のある Kubernetes ユーザーの修復
侵害された可能性のある Kubernetes ポッドの修復
侵害された可能性のある Kubernetes ノードの修復
侵害された可能性のあるコンテナイメージの修復

注記

Kubernetes バージョン 1.14 より前では、system:unauthenticated グループは、デフォルトで system:discovery と system:basic-user ClusterRoles に関連付けられていました。これは、匿名ユーザーからの意図しないアクセスを許可する場合があります。クラスターの更新では、これらの許可は取り消されません。つまり、クラスターをバージョン 1.14 以降に更新した場合でも、これらの許可は引き続き有効である可能性があります。これらの許可の関連付けを system:unauthenticated グループから解除することをお勧めします。

これらのアクセス許可の削除の詳細については、「Amazon EKS ユーザーガイド」の「Amazon EKS のセキュリティベストプラクティス」を参照してください。

潜在的な設定の問題

検出結果で設定の問題が示されている場合、その特定の問題の解決に関するガイダンスについては、その検出結果の修復セクションを参照してください。詳細については、設定上の問題を示す次の検出結果タイプを参照してください。

Policy:Kubernetes/AnonymousAccessGranted
Policy:Kubernetes/ExposedDashboard
Policy:Kubernetes/AdminAccessToDefaultServiceAccount
Policy:Kubernetes/KubeflowDashboardExposed
SuccessfulAnonymousAccess で終わる検出結果。

侵害された可能性のある Kubernetes ユーザーの修復

GuardDuty の検出結果は、検出結果で特定されたユーザーが想定されていない API アクションを実行したときに、侵害された Kubernetes ユーザーを示している場合があります。ユーザーは、コンソールの検出結果の詳細の [Kubernetes user details] (Kubernetes ユーザー詳細) セクション、または検出結果の JSON の resource.kubernetesDetails.kubernetesUserDetails で識別できます。これらのユーザーの詳細には、user name、uid、およびユーザーが属する Kubernetes グループが含まれます。

ユーザーが IAM エンティティを使用してワークロードにアクセスしていた場合は、この Access Key details セクションを使用して、IAM ロールまたはユーザーの詳細を識別できます。次のユーザータイプとその修復ガイダンスを参照してください。

注記

Amazon Detective を使用して、検出結果で特定された IAM ロールまたはユーザーをさらに調査できます。GuardDuty コンソールで検出結果の詳細を表示しているときに、[Detective で調査] を選択します。次に、リストされた項目から AWS ユーザーまたはロールを選択して、Detective で調査します。

組み込みの Kubernetes 管理者 – クラスターを作成した IAM アイデンティティに Amazon EKS によって割り当てられたデフォルトのユーザー。このユーザータイプは、ユーザー名 kubernetes-admin で識別されます。

組み込みの Kubernetes 管理者のアクセスを取り消すには:

Access Key details セクションから userType を識別します。
- userType が [Role] (ロール) であり、ロールが EC2 インスタンスロールに属している場合:
  - そのインスタンスを特定し、「侵害された可能性のある Amazon EC2 インスタンスの修復」の手順に従います。
- userType が [User] (ユーザー) の場合、またはユーザーが引き受けた [Role] (ロール) の場合:
  1. そのユーザーのアクセスキーをローテーションします。
  2. ユーザーがアクセス権を有していたシークレットをローテーションします。
  3. 詳細については、「My AWS アカウント may be compromised」の情報を確認してください。

OIDC 認証済みユーザー – OIDC プロバイダーを通じてアクセス権を付与されたユーザー。通常、OIDC ユーザーは、ユーザー名としてメールアドレスを持っています。次のコマンドを使用して、クラスターが OIDC を使用しているかどうかを確認できます: aws eks list-identity-provider-configs --cluster-name your-cluster-name。

OIDC 認証済みユーザーのアクセスを取り消すには:

OIDC プロバイダーでそのユーザーの認証情報をローテーションします。
ユーザーがアクセス権を有していたシークレットをローテーションします。

AWS-Auth ConfigMap 定義ユーザー – an AWS-auth ConfigMap を通じてアクセス権が付与された IAM ユーザー。詳細については、「&EKS; ユーザーガイド」の「クラスターのユーザーまたは IAM ロールの管理」を参照してください。次のコマンドを使用して、許可を確認できます: kubectl edit configmaps aws-auth --namespace kube-system。

AWS ConfigMap ユーザーのアクセスを取り消すには：

次のコマンドを使用して、ConfigMap を開きます。
```
kubectl edit configmaps aws-auth --namespace kube-system
```

GuardDuty の検出結果の [Kubernetes user details] (Kubernetes ユーザー詳細) セクションで報告されたものと同じユーザー名で、mapRoles または mapUsers セクションの下のロールまたはユーザーエントリを特定します。次の例を参照してください。ここでは、管理者ユーザーが検出結果で特定されています。


apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::444455556666:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
      user name: system:node:EC2_PrivateDNSName
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
    - userarn: arn:aws:iam::123456789012:user/admin
      username: admin
      groups:
        - system:masters
    - userarn: arn:aws:iam::111122223333:user/ops-user
      username: ops-user
      groups:
        - system:masters

そのユーザーを ConfigMap から削除します。管理者ユーザーが削除された次の例を参照してください。


apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
    - userarn: arn:aws:iam::111122223333:user/ops-user
      username: ops-user
      groups:
        - system:masters

userType が [User] (ユーザー) の場合、またはユーザーが引き受けた [Role] (ロール) の場合:
1. そのユーザーのアクセスキーをローテーションします。
2. ユーザーがアクセス権を有していたシークレットをローテーションします。
3. 詳細については、AWS 「アカウントが侵害されている可能性がある」の情報を確認してください。

検出結果に resource.accessKeyDetails セクションがない場合、ユーザーは Kubernetes サービスアカウントです。

サービスアカウント – サービスアカウントはポッドのアイデンティティを提供し、次の形式のユーザー名で識別できます: system:serviceaccount:namespace:service_account_name。

サービスアカウントへのアクセス権を取り消すには:

サービスアカウントの認証情報をローテーションします。
次のセクションでポッドの侵害に関するガイダンスを確認します。

侵害された可能性のある Kubernetes ポッドの修復

GuardDuty が resource.kubernetesDetails.kubernetesWorkloadDetails セクション内のポッドまたはワークロードリソースの詳細を指定する場合、そのポッドまたはワークロードリソースが侵害されている可能性があります。GuardDuty の検出結果は、単一のポッドが侵害されたか、または上位レベルのリソースを介して複数のポッドが侵害されたことを示している場合があります。侵害されたポッドを特定する方法のガイダンスについては、次の侵害シナリオを参照してください。

単一のポッドの侵害

resource.kubernetesDetails.kubernetesWorkloadDetails セクション内の type フィールドが [Pod] (ポッド) である場合、検出結果は単一のポッドを特定します。名前フィールドはポッドの name であり、namespace フィールドはその名前空間です。

ポッドを実行しているワーカーノードの特定の詳細については、「Identify the offending pods and worker node」を参照してください。

ワークロードリソースを通じて侵害されたポッド

type セクション内の resource.kubernetesDetails.kubernetesWorkloadDetails フィールドが、Deployment などの [Workload Resource] (ワークロードリソース) を識別している場合、そのワークロードリソース内のすべてのポッドが侵害されている可能性があります。

ワークロードリソースのすべてのポッドとそれらが実行されているノードの特定の詳細については、「Identify the offending pods and worker nodes using workload name」を参照してください。

サービスアカウントを通じて侵害されたポッド

GuardDuty の検出結果が resource.kubernetesDetails.kubernetesUserDetails セクションでサービスアカウントを識別した場合、識別されたサービスアカウントを使用しているポッドが侵害されている可能性があります。検出結果によって報告されたユーザー名は、次の形式の場合はサービスアカウントです: system:serviceaccount:namespace:service_account_name。

サービスアカウントを使用しているすべてのポッドとそれらが実行されているノードの特定の詳細については、「Identify the offending pods and worker nodes using service account name」を参照してください。

侵害されたすべてのポッドとそれらが実行されているノードを特定したら、「Amazon EKS ベストプラクティスガイド」を参照して、ポッドを分離し、その認証情報をローテーションして、フォレンジック分析のためにデータを収集します。

侵害されている可能性のあるポッドを修復するには:

ポッドを侵害した脆弱性を特定します。
その脆弱性の修復を実装し、新しい代替ポッドを起動します。
脆弱なポッドを削除します。

詳細については、「Redeploy compromised pod or workload resource」を参照してください。

ワーカーノードに、ポッドが他の AWS リソースにアクセスできるようにする IAM ロールが割り当てられている場合は、攻撃によるさらなる損害を防ぐために、インスタンスからそれらのロールを削除します。同様に、ポッドに IAM ロールが割り当てられている場合は、他のワークロードに影響を与えることなく、ロールから IAM ポリシーを安全に削除できるかどうかを評価します。

侵害された可能性のあるコンテナイメージの修復

GuardDuty の検出結果でポッドの侵害が示されている場合、ポッドの起動に使用されたイメージが潜在的に悪意があるものであるか、または侵害されている可能性があります。GuardDuty の検出結果では、resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image フィールド内のコンテナイメージが識別されます。マルウェアがないかを調べるためにスキャンして、イメージが悪意のあるものであるかどうかを判断できます。

侵害されたコンテナイメージを修復するには:

直ちにイメージの使用を停止し、イメージリポジトリから削除します。
侵害された可能性のあるイメージを使用しているすべてのポッドを特定します。

詳細については、「Identify pods with potentially vulnerable or compromised container images and worker nodes」を参照してください。
侵害された可能性のあるポッドを分離し、認証情報をローテーションして、分析のためにデータを収集します。詳細については、「Amazon EKS ベストプラクティスガイド」を参照してください。
侵害された可能性のあるイメージを使用しているすべてのポッドを削除します。

侵害された可能性のある Kubernetes ノードの修復

GuardDuty の検出結果は、検出結果で識別されたユーザーがノードアイデンティティを表す場合、または検出結果が特権コンテナの使用を示している場合、ノードの侵害を示している場合があります。

[username] (ユーザーネーム) フィールドの形式が次の場合、ユーザーアイデンティティはワーカーノードです: system:node:node name。例えば、system:node:ip-192-168-3-201.ec2.internal と指定します。これは、攻撃者がノードへのアクセスを取得し、ノードの認証情報を使用して Kubernetes API エンドポイントと通信していることを示すものです。

検出結果では、検出結果にリストされている 1 つ以上のコンテナの resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged 検出結果フィールドが True に設定されている場合に、特権コンテナの使用を示します。

侵害されている可能性のあるノードを修復するには:

ポッドを分離し、認証情報をローテーションして、フォレンジック分析のためにデータを収集します。

詳細については、「Amazon EKS ベストプラクティスガイド」を参照してください。
侵害されている可能性のあるノードで実行されているすべてのポッドが使用するサービスアカウントを特定します。許可を確認し、必要に応じてサービスアカウントをローテーションします。
侵害されている可能性のあるノードを終了します。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

侵害された可能性のあるスタンドアロンコンテナの修復

Runtime Monitoring 検出結果の修正

このページの内容

Cookie の設定を選択する

Cookie の設定をカスタマイズする

Essential

Performance

Functional

Advertising

Cookie の設定を保存できません