プラットフォームのセキュリティ保護は、Kubernetes 環境の全体的なセキュリティを向上させる上で基礎となります。 この記事では、Kubernetes クラスター、その基になるオペレーティング システム、およびハードウェア インフラストラクチャをより安全に動作するように構成することに重点を置いています。 組み込みの機能と次のベスト プラクティスを活用することで、プラットフォームの脅威に対する回復性が高くなり、ワークロードと運用の基盤が強化されます。
最新のセキュリティ パッチを最新の状態に保つ
クラスターとノード OS は、公開時に最新のセキュリティ パッチを使用してアップグレードすることをお勧めします。 つまり、パッチがリリースされる Kubernetes のサポートされているバージョンを使用して、クラスターを最新の状態に保つことが重要です。 同様に、サポートされているバージョンの OS でノードを最新の状態に保つことも重要です。
Azure Arc on Azure Local で有効になっている AKS を使用している場合は、そのようなアップグレードを簡単に 適用できます。 また、Azure Local 自体を簡単にアップグレードすることもできます。
Arc 対応 Kubernetes 経由で独自のクラスターを接続する場合は、ベンダーのガイダンスに従って最新の状態に保ち、クラスターの Azure への接続を維持する Arc 対応 Kubernetes エージェントの 自動アップグレードを構成 します。
クラスターに 拡張機能 をデプロイすることもできます。このセキュリティブックの他のセクションでは、セキュリティ上の利点のために、これらの拡張機能の多くをお勧めします。 その場合は、これらの拡張機能の自動アップグレードも構成します。
リファレンス
- NSA Kubernetes セキュリティ強化ガイダンス – "アップグレードとアプリケーションセキュリティパッチ"
- Kubernetes Security - OWASP チート シート シリーズ – "Kubernetes ホストのセキュリティ保護"
コントロール プレーンとワーカー ノードでセキュリティ保護を構成する
Azure Arc on Azure Local によって有効になっている AKS は、コントロール プレーンとワーカー ノードをより安全な既定値で自動的に構成します。 基になるハードウェア、Windows ホスト OS、Linux VM ノードとファイルシステムの適切なセキュリティ機能がアクティブ化されます。 このプラットフォームをセキュリティで保護する方法の詳細については、 Azure ローカル セキュリティブック を参照してください。 Azure Arc で有効になっている AKS がコンテナー ホストとして使用する Azure Linux OS の利点を確認することもできます。
Arc 対応 Kubernetes 経由で独自のクラスターを接続する場合は、ベンダーがハードウェア、OS、および Kubernetes スタック全体でセキュリティで保護された既定値を自動的に構成するのにも同様に役立つ可能性があることを確認します。 ハードウェアの信頼の根源、セキュアブート、ドライブの暗号化などの妥当な機能が備わっているかどうかを評価します。 また、 Microsoft Defender for Endpoint がクラスター ノードの保護に役立つかどうかも検討してください。
さらに、クラスターが完全に Microsoft で管理されているか、独自のクラスターに接続しているかに関係なく、Microsoft Defender for Containers を使用できます。 これは、Kubernetes ノードの正常性を評価し、問題を通知するのに役立ちます。 どのクラスターの種類がどのレベル (プレビューまたは一般提供) でサポートされている機能のサポート マトリックス を参照してください。
リファレンス
Kubernetes コントロール プレーン コンポーネント間の通信を保護する
Azure Arc on Azure Local で AKS を有効にしている場合は、トランスポート層セキュリティ (TLS) を使用して、API サーバーや etcd などのコントロール プレーン コンポーネント間のすべてのクロスノード通信を保護します。 TLS 証明書は定期的にローテーションされます。
Arc 対応 Kubernetes 経由で独自のクラスターを接続する場合は、ノード間のトラフィックが同様に保護されているかどうかを判断します。 ベンダーのガイダンスに従って、この保護を有効にするために必要な手順 (証明書の作成や更新など) があるかどうかを評価します。
リファレンス
- NIST アプリケーション コンテナー セキュリティ ガイド - セクション 4.3.5
- NSA Kubernetes のセキュリティ強化ガイダンス - "暗号化"
- Kubernetes Security - OWASP チート シート シリーズ – "etcd へのアクセスの制限"
ノードへの直接アクセスを保護する
一般に、クラスターのノードに直接アクセスすることはお勧めしません。 API サーバーを介してクラスターを管理することをお勧めします。Role-Based アクセス制御 (RBAC) を使用すると、どのユーザーがどの操作を実行できるかを制御できます。 このトピックの 詳細なガイダンス を参照してください。
そのため、ワーカー ノードへの SSH アクセスは既定で無効にする必要があります。 ただし、このアクセスが必要であることが証明され、Azure Arc on Azure Local で AKS が有効になっている場合は、慎重に管理することが重要です。 クラスターの作成時に SSH キーを安全に格納 し、 SSH アクセスを想定されるネットワーク アドレスのみに制限します。 この限られた例外を超えて、コントロール プレーン ノードと kubernetes インフラストラクチャ コンポーネント (kube-scheduler、etcd、kubelet など) に到達する他の方法はありません。
最後に、エッジ クラスターはセキュリティで保護されていない場所に存在することが多いため、適切な物理的な保護 (ロックされたアクセス、改ざんの明らかな対策など) を検討してください。