EKS セキュリティ チェックリスト: 安全なクラスターのための 10 のベスト プラクティス

Kubernetes にはセキュリティ上の課題が山積しています。必然的に、Amazon Elastic Kubernetes Service (EKS) などのマネージド Kubernetes サービスでも同じことが当てはまります。クラスターのセキュリティを強化する最善の方法は、Kubernetes コミュニティによって推奨されている業界標準となっているプラ​​クティスを実装することです。ここでは、すべてのチームがクラスターを保護するために必要な EKS セキュリティ戦略のトップ 10 を紹介します。

Amazon EKS セキュリティとは一体何でしょうか?

Amazon EKS は現在最も人気のあるマネージド Kubernetes サービスの 1 つです。これにより、チームは Kubernetes コントロール プレーンや Kubernetes クラスターの実行に必要なインフラストラクチャをインストールして操作することなく、Kubernetes を介してコンテナをオーケストレーションできるようになります。

EKS は AWS が提供するサービスなので、共有責任モデルを通じてセキュリティについて議論を始めることができます。一般的に、AWS はクラウドサービスのセキュリティを管理し、顧客はワークロードのセキュリティを監視する責任を負います。

AWS は、クラウドプロバイダーが安全な Kubernetes 環境を提供するために使用するすべてのインフラストラクチャサービスを含め、EKS を通じて Kubernetes ダッシュボードとコントロールプレーンを管理します。

IAM、ポッド、ランタイム、ネットワーク セキュリティ、ワーカー ノードのスケーラビリティ、コンテナ イメージ コンポーネントなどのセルフマネージド ワーカーと EKS クラスター構成はすべてお客様の所有となります。

クライアント セキュリティには、データ セキュリティ、動作中のノードのアップグレードとパッチ、データ プレーンとノードからコンテナーとオペレーティング システムに至るまでのすべてのセキュリティ構成が含まれます。お客様は、EKS コントロール プレーンが仮想プライベート クラウド (VPC) と安全に通信できるように、セキュリティ グループを構成する必要もあります。

AWS ユーザーは、クラウドプロバイダーから次の形式で EKS セキュリティのサポートを受けます。

• 安全ユーザーガイド、
• EKS ベスト プラクティス ガイド。

AWS がマネージド Kubernetes サービスに EKS セキュリティ機能を組み込む

ここでは、このマネージド Kubernetes サービスを使用してクラスターを実行することを決定したすべての AWS ユーザーが利用できる、組み込みの EKS セキュリティ機能の一部を紹介します。

AWS シークレットマネージャー

Kubernetes では、キーと値のペアを作成し、それをポッド内で実行されているアプリケーションに持ち込むことができます。機密データが含まれている場合は、AWS Secrets Manager (および AWS パラメータストア) によって実装されたコンテナストレージインターフェイスドライバーである Secret Store を使用できます。

AWS Secrets Manager は、Kubernetes シークレットを保存および管理するための中心的な場所を提供します。 AWS Secrets and Configuration Provider (ASCP) プラグインを使用すると、ユーザーは etcd を通じてシークレットを受信するレガシー Kubernetes ワークロードを操作できます。 IAM ポリシーを適用して、どのポッドがシークレットにアクセスできるかを定義することもできます。

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

Identity and Access Management (IAM) は、AWS リソースへのアクセスを制御したいすべての管理者に役立ちます。 IAM 管理者は、特定のポリシーに基づいて、誰がログインして EKS リソースにアクセスできるかを設定できます。

ユーザーは、Kubernetes リソースの認証および承認資格情報を取得します。目的は、サービス ユーザーに、業務を遂行するために必要な機能のみへのアクセスを許可することです。

ログ記録と監視

AWS は、コントロールプレーンからの診断ログと監査ログを保存する CloudWatch へのアクセスを提供します。各 EKS コントロール プレーンには独自のログ グループがあります。これらのログを監視して、セキュリティと運用上の問題をタイムリーに検出することが重要です。また、すべての EKS アクティビティをログに記録し、ユーザー、ロール、AWS サービス、または EKS コンソールリクエストによって行われた API 呼び出しをキャプチャする AWS CloudTrail もあります。

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

1. Kubernetesノードを分離する

Kubernetes ノードをパブリック インターネットに直接公開することは避けてください。理想的には、このようなノードは、可能であれば、一般的な企業ネットワークに直接接続せずに、別のネットワーク上に配置する必要があります。

どうすれば機能するのでしょうか? Kubernetes の制御とデータ トラフィックを分離します。そうしないと、すべて同じパイプを通って流れることになります。データ プレーンへのオープン アクセスはコントロール プレーンへのオープン アクセスを意味し、これは EKS セキュリティにとって悪いニュースです。 Ingress コントローラーを使用してノードを構成し、ネットワーク アクセス制御リスト (ACL) 内の指定されたポート経由でのみマスター ノードからの接続を許可するように設定します。

2. 認証と承認を強化する

Kubernetes をサードパーティの認証プロバイダーと統合するのが賢明です。これにより、多要素認証などの追加のセキュリティ機能が得られます。

安全なコントロールプレーンアクセスを実現するには、API サーバー レベルでユーザーを管理する代わりに、AWS Identity and Access Management (IAM) ソリューションを使用します。 CSP IAM を取得できない場合は、OpenID Connect (OIDC) と優先 SSO プロバイダーを選択してください。 1

3. Kubernetes のロールベース アクセス制御 (RBAC) を活用する

EKS セキュリティのアクセス関連のベスト プラクティスのもう 1 つは、RBAC を使用して、Kubernetes API にアクセスできるユーザーとその権限を定義することです。 Kubernetes 1.6 以降では、RBAC は通常デフォルトで有効になっています。 Kubernetes には認証コントローラが組み込まれているため、RBAC を有効にすると従来の属性ベースのアクセス制御 (ABAC) は無効になります。

クラスター全体の権限ではなく、名前空間固有の権限を選択することをお勧めします。デバッグ時であっても、クラスター管理者権限を付与しないでください。そうしないと、コンテナのセキュリティが侵害される可能性があります。

4. 環境変数に秘密を保存しない

環境変数はシステムの他の部分から簡単にアクセスできるため、オブジェクトが環境変数でシークレットを使用していることを確認してください。潜在的な脅威を最小限に抑えるには、シークレットをファイルとして使用するか、secretKeyRef を活用します。

5. コンテナを特権モードで実行しない

デプロイメントに特権 (ルート) モードで実行されているコンテナがある場合、コンテナは重要なホスト リソースにアクセスできるようになります。セキュリティ上の問題が発生する可能性があります。コンテナを特権モードで実行しないようにするか、podSecurityPolicy を開いて privileged パラメータを false に設定します。これにより、コンテナはホスト上でルート権限を必要とするプロセスを実行できなくなります。

6. ホストのIPCまたはネットワーク名前空間を共有しない

ポッドを確認し、ホストの IPC またはネットワーク名前空間を共有しているかどうかを確認します。ポッドとホストのプロセス間通信用の名前空間を共有すると、共有情報へのアクセスが可能になる可能性があるため危険です。このため、ポッドがホスト名前空間にアクセスできないようにする必要があります。

ポッドとホスト ネットワークの名前空間を共有すると、ポッドからホスト ネットワークへのネットワーク アクセスが可能になります。これにより、ネットワークの分離が解除されます。 PodSecurityPolicy で hostNetwork パラメータを false に設定し、クラスターが保護されていることを知って安心して眠ることができます。

7. NET_RAWを無効にする

Kubernetes コンテナが NET_RAW 機能を削除しない場合、クラスター内で広範囲にわたるネットワーク攻撃が発生する可能性があります。 EKS のセキュリティを確保するには、Open Policy Agents、Kyverno、Kubernetes Pod Security アドミッション コントローラーなどのポリシー適用ソリューションを使用して、業界のベスト プラクティスに従ってください。

NET_RAW 機能が無効になっていることを確認するには、ポッドの securityContext 定義で ALL または NET_RAW 機能の drop を設定します。 [23]

8. 安全でない /Proc マウントを確認する

安全でない /proc マウント (procMount=Unmasked) を使用したデプロイメントでは、他のユーザーがコンテナ ランタイムのデフォルトのマスキング動作をバイパスできるようになります。コンテナがマスクされていない /procs マウント タイプに設定されている場合、ホスト情報がコンテナに公開され、データ漏洩やコンテナ エスケープが発生する可能性があります。コンテナーが /proc のどの部分も公開しないようにするには、procMount=Default を設定します。

9. コンテナのセキュリティにルートファイルシステムを使用しない

コンテナが読み取り専用のルートファイルシステムなしで実行される場合は、トラブルに備えてください。読み取り専用ファイルシステムを使用すると、さまざまな悪意のあるバイナリがシステムに書き込まれたり、攻撃者に乗っ取られたりすることを防ぐことができます。コンテナが読み取り専用ファイルシステムのみを使用していることを確認し、Pod の securityContext 定義で readOnlyRootFilesystem を true に設定します。

10. ローリングアップデート戦略を確立する

最後に、EKS のセキュリティを確保するために、ローリング アップデート戦略を策定します。ローリング アップデートでは、ポッド インスタンスを新しいインスタンスで段階的に更新することで、アプリケーションのダウンタイムを最小限に抑えてデプロイメントを更新できます。詳細については、Kubernetes ドキュメントのこのページをご覧ください。

もう 1 つのポイントは、サプライ チェーン攻撃があるため、実行時に脆弱性スキャンを実行することです。そのため、CI/CD フェーズ中にデプロイメント成果物をスキャンする場合でも、クラスターが実際に何を取得しているかを確認する必要があります。一般的に言えば、エージェントベースのセキュリティ ソリューションは、「エージェントレス」ソリューションと同等かそれ以上に優れています。

Kubernetes エコシステムは絶えず進化しており、セキュリティも例外ではありません。新たな脅威が出現し、問題が明らかになるにつれて、エンジニアは多くのことに対処しなければならなくなり、それには多くの時間と労力が必要になります。

EKS セキュリティで直面したもう 1 つの課題は、セキュリティ問題の優先順位付けでした。これは、アプリケーションのサイズによっては時間がかかる可能性があります。自動化によりこのプロセスが高速化され、エンジニアは他のタスクに時間を割くことができます。