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

EKS Protection の検出結果の修正

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

EKS Protection の検出結果タイプのいずれかが予期して生成された場合は、を追加して今後のアラートの抑制ルール GuardDutyを防ぐことを検討できます。

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

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

注記

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

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

潜在的な設定の問題

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

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

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

GuardDuty 検出結果で識別されたユーザーが予期しないAPIアクションを実行した場合、検出結果は侵害された Kubernetes ユーザーを示している可能性があります。ユーザーは、コンソールまたはの結果ので、検出結果の詳細の Kubernetes ユーザーの詳細セクションで識別できますresource.kubernetesDetails.kubernetesUserDetailsJSON。これらのユーザーの詳細には、user name、uid、およびユーザーが属する Kubernetes グループが含まれます。

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

注記

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

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

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

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

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

OIDC認証されたユーザーのアクセスを取り消すには：

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

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

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

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

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


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 ポッドの修復

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

単一のポッドの侵害

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 検出結果で識別されたユーザーがノード ID を表す場合、または検出結果が特権コンテナの使用を示している場合、検出結果はノードの侵害を示している可能性があります。

[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 検出結果の修正