EKS セキュリティベストプラクティスチェックリスト

By 清水 孝郎 - APRIL 18, 2022
Topics: コンテナ、Kubernetes、ホストのセキュリティ

SHARE:

本文の内容は、2022年4月19日現在における、Sysdig Cloud Native Learning Hub上のEKS Security Best Practices Checklist
(https://sysdig.com/learn-cloud-native/kubernetes-security/eks-security-best-practices-checklist/
) を元に日本語に翻訳・再構成した内容となっております。

Amazon Elastic Kubernetes Serviceの紹介

Amazon Elastic Kubernetes Service（Amazon EKS）は、コントロールプレーンやノードのインストール、管理、保守を行うことなく、AWS上でKubernetesを実行できるマネージドサービスです。Kubernetesは、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するためのオープンソースのプラットフォームです。アプリケーション開発にコンテナを使用することで、開発者は、実行するオペレーティングシステムに関係なく、コードの動作が予測可能な、効率的で環境に依存しないアプリケーションを手に入れることができます。そのため、Kubernetesはコンテナを使用して、アプリケーションのコードの依存関係、設定、およびライブラリをパッケージ化して管理します。Kubernetesの台頭とともに、クラウド開発者がKubernetesを使いやすくすることを目的としたAmazon EKSなどの補完的なクラウドサービスが人気を集めています。

Amazon EKSは、Kubernetesのユーザーがデプロイ、スケーラビリティ、管理に関する技術的なエラーに対処する手間を省くことができるようにします。バッチ処理、アプリケーションの移行、マイクロサービスの利用を支援し、コンテナアプリケーションの主要な機能に集中できるようにします。また、1台のコンピュータ上で動作するすべての集合プロセスのクラスターであるKubernetesコントロールパネルも自動的に制御します。Amazon EKSを使用するもう一つの利点は、サーバーレスアーキテクチャーを使用できることで、開発者は基盤となる複雑なサーバーインフラのスケーラビリティや管理について心配することなく、コードファンクションを書くことができるようになることです。

Amazon EKSの利点と用途は、特に、EKSワーカーノードとクラスターを使用して組織のVPCネットワーク資産とシームレスに統合することができるため、継続的に使用することができます。EKSはKubernetesに準拠しているため、Kubernetesを実行・管理するためのツールやプラグインを簡単に実装することができます。AWSでのクラウドネイティブアーキテクチャーの構築において、Kubernetesの安全性確保、拡張、デプロイ、管理といった困難な作業を簡素化することができます。 開発者やクラウドコンピューティングの利用者がクラウドサービスを利用する際に懸念することの1つに、セキュリティがあります。Amazon EKSのセキュリティは、その採用に関しても大きな懸念事項です。したがって、Amazon EKSが提供するリソースを十分に活用するために、すべてのユーザーがAmazon EKSを使用するベストプラクティスを徹底的に学習する必要があります。

Amazon EKS Overview
Amazon EKSの概要（出典：Amazon）

Amazon EKSのセキュリティ

AWSのクラウドサービスのセキュリティは、まず共有責任モデルへの適合性を理解する必要があります。AWSはクラウドのセキュリティを監督し、顧客はクラウド内のセキュリティに責任を持つ。AWSはEKSを通じてKubernetesダッシュボードとコントロールプレーンを管理し、ETCDデータベース、Kubernetesクラスター、そして安全で信頼できるKubernetesを提供するためにAWSが使用するその他のインフラサービスを含んでいます。IAM、Podセキュリティ、ランタイムセキュリティ、ネットワークセキュリティ、ワーカーノードのスケーラビリティ、コンテナイメージのコンポーネントなどの自己管理ワーカーとEKSクラスタの構成は、顧客の責任となります。

Amazon EKS Shared Responsibility Model
Amazon EKS Shared Responsibility Model（出典：aws.amazon.com）

Amazon EKSのセキュリティベストプラクティス

システムを開発する前に、サービス提供者と顧客の義務の境界線をどこに引くべきかを理解することが重要である。その際、システムのセキュリティ上の意味合いと、そのコンポーネントをどのように扱うかに注意を払う必要があります。そうすれば、不正アクセス、データの機密保持違反、認証の破損、システムの誤設定、その他のシステム詐欺などの不正なインシデントに関連する潜在的なリスクを特定することができます。システム設計・開発時にベストプラクティスを導入することで、セキュリティインシデントに迅速に対応できるような明確な手順を設定し、組織全体のセキュリティ態勢を向上させることができます。AWS EKSはAWSによって高度にサポートされており、お客様とそのユーザーは、規制とセキュリティのコンプライアンスを達成するための基盤となるツールとテクニックを確実に得ることができます。

アイデンティティとアクセス管理

アイデンティティとアクセス管理（IAM）は、他のAWSリソース上の承認と認証を管理するために使用されるAWSのサービスです。IAMは、権限とポリシーを使用して、さまざまなユーザーにロールを割り当て、さまざまなAWSリソースを使用する際の権限とアクションを管理するものです。EKSを使用する場合、セキュリティのベストプラクティスの1つは、ユーザーが必要以上の権限を割り当ててはいけないとする「最小特権原則」に従うことです。この方法では、タスクの実行に必要な権限のみが付与されます。

IAM Roles for Service Accounts（IRSA）は、Kubernetesのサービスアカウントにロールを割り当てるためにIAM内で使用される機能です。IRSAは、Kubernetes内でワークロード固有のロールを作成し、ポッドおよびノードレベルで最小セキュリティ原則が適用されるようにするために使用されます。これは、OpenID Connect（OIDC）IDプロバイダーとKubernetesサービスアカウントのアノテーションを統合し、最小限の特権が割り当てられるようにすることで実現されます。


How AWS IAM and Kubernetes Integrate to form IRSA
AWS IAMとKubernetesが統合してIRSAを形成する方法（出典：AWSブログ）

KubernetesとEKSでIRSAの機能を活用する例としては、ロールベースのアクセス制御を適用してクラスターの権限を差別化することが考えられます。Kubernetesで直面する重要な課題の1つは、同じノード上で動作するポッドが同じ権限セットを共有することです。これは最小特権の原則に違反する可能性があります。この課題を解決し、特定のノードへのアクセスを許可するには、IRSAを使用してインスタンスのメタデータへのアクセスをブロックし、他のPodが特定のワーカーノードに割り当てられたロールを継承できないようにします。
Code: block pods
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: deny-metadata-access
 namespace: example
spec:
 podSelector: {}
 policy types:
 - Egress
 egress:
 - to:
  - ipBlock:
    cidr: 0.0.0.0/0
    except:
    - 169.254.169.254/32
Modify security access
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: allow-metadata-access
 namespace: example
spec:
 podSelector:
  matchLabels:
   app: myapp 
 policyTypes:
 - Egress
 egress:
 - to:
  - ipBlock:
    cidr: 169.254.169.254/32

一般的に、IAMはEKSを使用する際に、リソースを使用する際の全レベルの特権アクセスの全体的な可視性と制御を確保するための重要なサービスです。IAMがEKSのセキュリティベストプラクティスを満たすためのその他の方法としては、ワークフローアクセスを制御するための強力なパスワードポリシーの実装、多要素認証（MFA）の使用、トークン化アクセスキーの使用、セッション管理、およびアプリケーションへの不要な匿名アクセスの確認と取り消しなどがあります。

Pod用セキュリティグループ

Kubernetesでは、Podとは、ストレージやネットワークリソースを共有し、コンテナの実行方法を指定する、最小のデプロイ可能なコンピューティングユニットのグループです。Kubernetesでのコンテナ化で直面する主な問題の1つは、さまざまなネットワークセキュリティ要件を持つアプリケーションを実行するための共通の方法がないことです。共有の計算リソース上で実行されるポッドでは、AWSはAWS Security Groups for Podsを使用して、クラスターインスタンスレベル内でインバウンドおよびアウトバウンドのネットワークトラフィックを制御します。このように、Pod用のセキュリティグループを使用すると、Pod内とAWSサービストラフィックの外にまたがるネットワークセキュリティルールを設定し、単一のEC2セキュリティインスタンスで定義し、KubernetesネイティブAPIを持つアプリケーションに適用することができます。そのため、セキュリティグループはKubernetesクラスター内で動作するPodにアタッチされ、VPC内のサブネット内のインスタンスに対して仮想ファイアウォールとして機能します。

Podにセキュリティグループを実装する際、重要な考慮点の1つは、通常ルートLinuxホストから継承されるコンテナ機能を制限し、特権権限で実行できないようにすることです。これは、コンテナが適切に機能するためにこれらの特権を必要とせず、Podの変異を妨害することになる可能性があるためです。また、AWSでは、Podが作成され、サービスロールやアカウントにバインドされる前に、必要なセキュリティ要件を満たしていることを確認するためのPodセキュリティポリシーが定義されています。Podの権限を制限する重要な方法の1つは、PodSecurityPolicyが割り当てられたRoleのKubernetes ClusterRoleBindingで定義されたeks-vpc-resource-controllerおよびvpc-resource-controller Kubernetesサービスアカウントを設定することです。ベストプラクティスとして、サービスアカウントは特定のネームスペース内でスコープされ、特権Podにバインドされ、その外側ではネームスペースにアクセスすることができません。そのようなポリシーの例を以下に示します。
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default'
    apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
    seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default'
    apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default'
spec:
  privileged: false
  # Required to prevent escalations to root.
  allowPrivilegeEscalation: false
  # This is redundant with non-root + disallow privilege escalation,
  # but we can provide it for defense in depth.
  requiredDropCapabilities:
  - ALL
  # Allow core volume types.
  volumes:
  - 'configMap'
  - 'emptyDir'
  - 'projected'
  - 'secret'
  - 'downwardAPI'
  # Assume that persistentVolumes set up by the cluster-admin are safe to use.
  - 'persistentVolumeClaim'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    # Require the container to run without root privileges.
    rule: 'MustRunAsNonRoot'
  seLinux:
    # This policy assumes the nodes are using AppArmor rather than SELinux.
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
    # Forbid adding the root group.
    - min: 1
      max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
    # Forbid adding the root group.
    - min: 1
      max: 65535
  readOnlyRootFilesystem: false

Podセキュリティ標準

Podのセキュリティグループを扱う場合、Podのセキュリティの標準を設定するためのメカニズムをエンフォースする必要があります。Podセキュリティグループには3種類のポリシーがあります。

  • 制限(Restrictions)：このポリシーは、主に全体の機能に影響を与える可能性のある、セキュリティ上重要なアプリケーションの実行を対象とするために使用されます。たとえば、アプリケーションがルートまたはルートグループとして実行されないようにする制約などです。
  • 特権ポリシー：ロギングエージェント、ストレージドライバ、CNI、および許可されたアクセスを必要とする他のシステム全体のアプリケーションなどの許可レベルのポリシーは、これを使用して作成されます。
  • ベースラインポリシー：これは、hostNetwork、hostPID、hostIPC、hostPath、およびhostPortの使用を禁止し、Linuxの機能を追加できないようにして、特権の昇格を防止する基本的な制約のセットです。

EKSセキュリティにおけるチェックリスト

以上のように、Amazon EKSを使用する場合、セキュリティ監視の責任の大部分はお客様にあります。したがって、Kubernetesクラスターの健全性にエンドツーエンドの可視性を提供し、Pod内のあらゆる形態の不正な活動を検出するために、優れた監視ツールに投資することが重要です。セキュリティメトリクスを満たすためのチェックリストには、主に3つの項目があります。

  • リソースメトリクス – これは、ワークロードと比較してリソースの使用率を監視するために使用されます。Pod、基盤となるEC2インスタンス、およびコンテナの使用量と容量をチェックし、ノードとその上で動作するPodを含むクラスターのさまざまな層が、ワークロードを実行したり、新しいワークロードに対応したりできることを確認します。
  • Kubernetesオブジェクトの状態 – これは、クラスターのコントロールプレーン内のノードやPodなどの現在のオブジェクトの健康状態や可用性をチェックします。コントロールプレーンでは、クラスター内で行われるリクエストのパフォーマンスとスループットの全体像を把握することができます。このメトリクスは、API サーバーによってもたらされるクラスター関連の問題を特定するのに役立ちます。
  • AWSサービスメトリクス – EKSクラスターで作業する場合、AWSはEKSインフラストラクチャー全体を支援するためにリソースを自動的にプロビジョニングします。したがって、Kubernetesコンテナの実行に不可欠なそのようなサービスを監視し、EKSインフラストラクチャー全体の全体像を把握することが重要です。EKSクラスターで使用されるAWSサービスには、ロードバランシング用のElastic Load Balancer（ELB）、ワーカーノードの動的スケーリング用のAuto Scaling、ワーカーノードのプロビジョニング用のElastic Compute Cloud（EC2）、および永続ストレージボリューム用のEBSなどが含まれます。

まとめ

デジタル化に伴うクラウドコンピューティングの普及に伴い、クラウドサービスを利用する際には、観測と監視が重要なベストプラクティスの一つであることは言うまでもありません。Amazon EKSは、Kubernetesコンテナアプリケーションを実行する際に重要なツールであり、それゆえEKSクラスターを確実に監視することに重点を置く必要があります。ユーザーとしては、EKSクラスターを監視するために何から始めればいいのか悩むかもしれません。

ここでは、その提案をします。Sysdig MonitorとSysdig Secureです。これらは、Sysdig Secure DevOps Platformのコンポーネントで、単一のエージェントと統一されたプラットフォームを使用してAmazon EKSを監視し、セキュリティを確保するために使用されます。Sysdigは、AWSのお客様が、より多くの監視、保護、および配備されたマイクロサービスのトラブルシューティングを短時間で行えるようにすることで、クラウドアプリをより早く提供できるように支援します。