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

Amazon Elastic Kubernetesサービスの紹介

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

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

Amazon EKS 概要 (出典: Amazon)

Amazon EKSセキュリティ

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

Amazon EKS 責任共有モデル (出典: aws.amazon.com)

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

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

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

Identity and Access Management (IAM)は、AWSリソースの認可と認証を管理するために使用されるAWSサービスです。これは、様々なAWSリソースを使用する際の権限とアクションを管理するために、異なるユーザーにロールを割り当てるための権限とポリシーを使用します。EKSを使用する場合、セキュリティのベストプラクティスの1つは、'Least Privilege Principle'に従うことです。これにより、タスクの実行に必要な権限のみが付与されます。

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

AWS IAMとKubernetesが統合してIRSAを形成する仕組み（出典：AWS Blog）

KubernetesとEKSでIRSA機能を実際に使用する例としては、ロールベースのアクセス制御を適用してクラスタ権限を区別することが挙げられます。Kubernetesで直面する重要な課題の1つは、同じノード上で動作するポッドが同じ権限セットを共有することです。これは最小特権原則に違反する可能性があります。この課題を解決し、特定のノードへのアクセスを許可するには、IRSAを使用してインスタンスメタデータへのアクセスをブロックし、他のポッドが特定のワーカーノードに割り当てられたロールを継承できないようにします。

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つは、さまざまなネットワークセキュリティ要件を持つアプリケーションを実行する共通の方法がないことです。共有されたコンピュートリソース上で実行されるPodでは、AWSはAWS Security Groups for Podsを使用して、クラスタインスタンスレベル内のインバウンドとアウトバウンドのネットワークトラフィックを制御します。このように、ポッド用のセキュリティグループは、単一のEC2セキュリティインスタンスで定義された、Pod内とAWSサービストラフィックの外部にまたがるネットワークセキュリティルールを設定し、KubernetesネイティブAPIを持つアプリケーションに適用するために使用できます。したがって、セキュリティグループは、VPC内のサブネット内のインスタンスの仮想ファイアウォールとして機能するように、Kubernetesクラスタ内で実行されているPodに接続されます。

Pods にセキュリティグループを実装する場合、重要な考慮事項の 1 つは、通常ルート Linux ホストから継承されるコンテナ機能を制限し、特権として実行できないようにすることです。これは、コンテナが適切に機能するためにこれらの特権を必要とせず、ポッドの変異を妨害してしまう可能性があるためです。AWSはまた、ポッドが作成され、サービスロールやアカウントにバインドされる前に、必要なセキュリティ要件を満たしていることを保証するためのポッドセキュリティポリシーを定義しています。ポッドの特権を制限する1つの重要な方法は、PodSecurityPolicy割り当てRoleのKubernetes ClusterRoleBindingで定義されたeks-vpc-resource-controllerとvpc-resource-controller Kubernetesサービスアカウントを設定することです。ベストプラクティスとして、サービスアカウントは特定の名前空間内でスコープされ、特権ポッドにバインドされます。このようなポリシーの例を以下に示します：

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 種類のポリシーがあります：

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

EKSセキュリティのチェックリスト

上述したように、Amazon EKSで作業する場合、セキュリティ監視について多くの責任は顧客の手にあります。したがって、Kubernetesクラスタの健全性をエンドツーエンドで可視化し、Pod内の不正な活動を検知するために、優れた監視ツールに投資することが重要です。セキュリティ指標を満たすためのチェックリストには、主に3つの項目があります：

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

結 論

クラウドコンピューティングでのデジタル化が進む中、クラウドサービスを利用する上で、オブザーバビリティとモニタリングは重要なベストプラクティスの1つです。Amazon EKSはKubernetesコンテナ・アプリケーションを実行する際に重要なツールであり、そのためEKSクラスタを確実に監視することが重視されています。ユーザーとしては、EKSクラスタを監視するために何から始めればいいのか悩むかもしれません。

ここで提案したいのが、Sysdigの提供する Sysdig MonitorとSysdig Secureです。これらはSysdig Secure DevOps Platformのコンポーネントで、単一のエージェントと統一されたプラットフォームを使用してAmazon EKSを監視し、保護するために使用できます。Sysdigは、AWSのお客様がクラウドアプリを迅速に出荷できるよう、より多くのオブザーバビリティ、より多くの保護、およびデプロイされたマイクロサービスのトラブルシューティングを短時間で行えるようにします。Sysdig DevOps Platformを使い始めるには、このガイドに従ってください。