Kubernetes を強化するための 6 つのヒント

クラウドネイティブ テクノロジーを採用する組織が増えるにつれ、Kubernetes はコンテナ オーケストレーションの業界標準になりました。 Kubernetes への移行により、コンテナ化されたアプリケーションの展開、スケーリング、管理が大幅に簡素化および自動化され、従来のモノリシック システムやレガシー管理プロトコルに比べて多くの利点がもたらされます。

ただし、Kubernetes を大規模に管理するには、クラスターの強化、サプライ チェーンの保護、実行時の脅威の検出など、独自の課題が伴います。この記事では、Cloud Native Computing Foundation (CNCF)、米国国家安全保障局 (NSA)、サイバーセキュリティおよびインフラストラクチャセキュリティ庁 (CISA) の多くのベストプラクティスを組み合わせて、組織のリスク軽減に役立つ Kubernetes セキュリティ強化に関する 6 つの推奨事項を整理します。

クラスターのセットアップと強化

Kubernetes 環境のセキュリティ保護は、クラスターの強化から始まります。 GKE、EKS、AKS などのマネージド Kubernetes サービスを使用しているユーザーの場合、それぞれのクラウド プロバイダーがマスター ノードのセキュリティを管理し、クラスターのさまざまなデフォルトのセキュリティ設定を実装します。 GKE Autopilot は、GKE 強化ガイドラインと GCP セキュリティのベスト プラクティスを適用するために追加の手順を実行します。ただし、GKE Standard または EKS/AKS ユーザーの場合でも、クラウド プロバイダーには、Kubernetes API サーバーへのユーザー アクセス、クラウド リソースへのコンテナ アクセス、Kubernetes のアップグレードを保護するための一連のガイドラインがあります。

ガイドラインは次のとおりです。

• GKE 強化ガイド
• EKS セキュリティベストプラクティスガイド
• AKS クラスターのセキュリティ

自己管理型 Kubernetes クラスター (kube-adm や kops など) の場合、kube-bench を使用して、クラスターが CIS Kubernetes ベンチマークで指定されたセキュリティ ガイドラインを満たしているかどうかをテストできます。主な推奨事項には、etcd に保存されている機密情報を暗号化すること、TLS 証明書を使用してコントロール プレーンの通信を保護すること、監査ログを有効にすることなどがあります。

ネットワークとリソースのポリシー

デフォルトでは、Kubernetes は任意のポッドから同じクラスター内の別のポッドへの通信を許可します。これはサービス検出には理想的ですが、ネットワーク分離が提供されず、悪意のある人物や侵害されたシステムがすべてのリソースに無制限にアクセスできるようになります。チームが Kubernetes 内でマルチテナントの主な手段として名前空間を使用している場合、これは非常に深刻な問題になります。

ポッド、名前空間、外部エンドポイント間のトラフィックを制御するには、ネットワーク分離のために NetworkPolicy API (Calico、Flannel、クラウド固有の CNI など) をサポートする CNI プラグインを使用する必要があります。ゼロ トラスト モデルに従うベスト プラクティスは、別のポリシーで明示的に許可されていない限り、すべての受信トラフィックと送信トラフィックをブロックする、デフォルトで拒否するポリシーを実装することです。

ネットワーク ポリシーに加えて、Kubernetes は LimitRange と ResourceQuotas という 2 つのリソース レベル ポリシーも提供します。 LimitRanges は個々のリソースの使用を制限するために使用できます (ポッドあたり最大 2 CPU など)。一方、ResourceQuota は集約リソースの使用を制御します (dev 名前空間内の合計 20 CPU など)。

RBAC とサービス アカウント

強力なネットワークおよびリソース ポリシーが導入されたら、次のステップは RBAC 認証を適用してアクセスを制限することです。 Kubernetes 管理者は、ユーザーおよびユーザー グループがクラスターにアクセスするための RBAC を適用できるほか、サービスがクラスター内外のリソース (クラウドでホストされているデータベースなど) にアクセスすることを制限できます。さらに、企業は、各ポッドの作成時にマウントされるデフォルトのサービス アカウントの使用に注意する必要があります。デフォルトのサービス アカウントに付与された権限によっては、ポッドに過剰な権限が付与される場合があります。 Kubernetes サービスとの特定の通信が必要ない場合は、automountServiceAccountToken を false に設定してマウントを防止します。

システムの強化

クラスターが安全になったので、次のステップはシステムの攻撃対象領域を最小限に抑えることです。これは、ノード上で実行されているオペレーティング システムとコンテナ上のカーネルの両方に適用されます。汎用 Linux ノードを選択する代わりに、AWS Bottlerocket や GKE COS など、コンテナの実行に最適化された専用のオペレーティングシステムを選択します。次に、SELinux、AppArmor (1.4 以降ベータ版)、seccomp (1.19 以降安定) などの Linux カーネルのセキュリティ機能を活用します。 AppArmor は、プログラムを限られたリソース セットに制限する Linux ユーザーまたはグループの権限を定義します。 AppArmor プロファイルが定義されると、AppArmor アノテーションを持つポッドによってそれらのルールが適用されます。

 APIバージョン: v1

 種類: ポッド

メタデータ:

 名前: アパマー

注釈:

 容器。 装甲。 安全。 ベータ。 Kubernetes 。 io / hello : localhost / k8s - apparmor - 例- 拒否- 書き込み

仕様:

 コンテナ:

 - 名前: こんにちは

画像: ビジーボックス

コマンド: [ "sh" 、 "-c" 、 "echo 'Hello AppArmor!' && 1時間睡眠" ]

一方、Seccomp はコンテナによるシステムコールを制限します。基盤となる Kubernetes ノードで seccomp プロファイルが使用可能である限り、seccomp プロファイルは securityContext セクションで定義できます。

 APIバージョン: v1

 種類: ポッド

メタデータ:

 名前: 監査- ポッド

ラベル:

 アプリ: 監査- ポッド

仕様:

 セキュリティコンテキスト:

 seccompプロフィール:

 タイプ: ローカルホスト

localhostProfile : プロファイル/audit.json ​

 コンテナ:

 - 名前: テスト- コンテナ

イメージ: hashicorp / http - echo : 0.2.3

 引数:

 - "-text=いくつかのシステムコールを実行しました!"

seccomp プロファイルがなくても、ユーザーはさまざまな権限昇格攻撃からコンテナを制限できます。セキュリティの観点から、Kubernetes では、コンテナを特権またはルートとして実行できるかどうか、または権限をルートに昇格できるかどうかを構成できます。ユーザーは、hostPID、hostIPC、hostNetwork、および hostPaths を制限することもできます。これらの設定はすべて、Pod セキュリティ ポリシー (v1.21 では非推奨) または K-Rail、Kyverno、OPA/Gatekeeper などの他のオープン ソース ツールを使用して適用できます。

最後に、追加の安全性保証が必要な場合は、ハードウェア仮想化 (gVisor や Kata など) を活用するようにカスタム RuntimeClass を構成できます。ノード レベルで RuntimeClass を定義し、ポッド定義で指定します。

 apiバージョン: ノード。 k8s 。 io / v1 # RuntimeClass はノード内で定義されます。 k8s 。 io API グループ

種類: ランタイムクラス

メタデータ:

 name : myclass # RuntimeClass が参照される名前

 # RuntimeClass は名前空間のないリソースです

handler : myconfiguration # 対応するCRI 設定の名前

-- -

 APIバージョン: v1

 種類: ポッド

メタデータ:

 名前: マイポッド

仕様:

 ランタイムクラス名: myclass

サプライチェーンのセキュリティ

クラスターとシステムが安全であっても、アプリケーション全体のエンドツーエンドのセキュリティを確保するには、サプライ チェーンを考慮する必要があります。社内でアプリケーションを開発する場合は、最小限のベースイメージを使用して攻撃対象領域を減らす、パッケージのバージョンを固定する、マルチステージビルドを使用して小さなイメージを作成するなど、コンテナを作成するためのベストプラクティスに従ってください。さらに、コンテナを実行するために必要な非 root ユーザーを定義するか、podman を使用して rootless コンテナを構築し、root アクセスを制限します。

次に、Trivy、Clair、Anchore などのオープンソース ツールまたは商用ツールを使用して、すべてのイメージの脆弱性をスキャンします。一部のツールでは、イメージに署名し、署名を検証して、ビルドおよびアップロードのプロセス中にコンテナーが改ざんされていないことを確認することもできます。最後に、ImagePolicyWebhook または上記のポリシー適用ツールのいずれかを使用して、Kubernetes がイメージをプルできるホワイトリスト レジストリを定義します。

監視、ログ記録、ランタイムセキュリティ

この時点で、厳重に保護されたサプライ チェーンを備えた安全なクラスターが完成し、アクセスが制限されたクリーンで検証済みのイメージを生成できるようになりました。ただし、環境は動的であり、セキュリティ チームは運用環境内のイベントに対応できる必要があります。まず、readOnlyRootFilesystem を true に設定し、tmp ログ ファイルを emptyDir に保存して、コンテナーの実行中に変更されないようにします。一般的なアプリケーション監視 (Prometheus/Grafana など) やログ (EFK など) ストレージに加えて、Falco または Sysdig を使用してシステム コール プロセスや Kubernetes API ログを分析することもできます。

どちらのツールも、実行時にカーネルからの Linux システム コールを解析し、ルールに違反した場合にアラートをトリガーできます。ルールの例としては、権限昇格が発生したときに警告する、既知のディレクトリで読み取り/書き込みイベントが検出されたときに警告する、シェルが呼び出されたときに警告するなどがあります。最後に、Kubernetes API 監査ログを既存のログ集約およびアラート ツールと統合して、クラスター内のすべてのアクティビティを監視します。これには、API リクエスト履歴、パフォーマンス メトリック、デプロイメント、リソース消費、オペレーティング システム呼び出し、ネットワーク トラフィックが含まれます。

結論

クラウドネイティブ システムは複雑であるため、Kubernetes 環境を保護するには多層アプローチが必要です。 Kubernetes では、クラウド ネイティブ セキュリティの 4C (クラウド、クラスター、コンテナ、コード) を実装することが推奨されます。まず、クラスターを強化し、クラウド セキュリティのベスト プラクティスに従います。次に、コンテナを保護し、攻撃対象領域を減らし、アクセスを制限し、実行時の不変性を確保します。 3 番目に、サプライ チェーンを保護し、コードとコンテナーの脆弱性を分析します。最後に、実行時にすべてのアクティビティを監視し、Kubernetes 内で実行されているソフトウェアのすべてのレイヤーに防御を構築します。

参考リンク: https://dzone.com/articles/kubernetes-security-guide-high-level-k8s-hardening