Kubernetes は、コンテナー化されたアプリケーションの管理方法において中心的な位置を占めています。そのため、YAML、JSON、INI など、Kubernetes アプリケーションを定義する多くの合意済みファイル形式があります。
これにより、アプリケーションに最適な戦略は何かを検討することになります。また、選択したファイル構造 (特にセキュリティ) パスに対してアプリケーション構成を検証する方法を検討する必要があります。
この記事では、YAML ファイルを使用して Kubernetes アプリケーションを定義する方法と、これらの構成定義を効果的に検証するために実行できるさまざまな手順について説明します。
Yaml は K8s 構成を定義します
JSON や INI と比較すると、YAML はコンパクトで読みやすいです。たとえば、ポート 80 で到達可能なポッドを定義する場合、YAML、JSON、および INI の構成は次の表のようになります。
YAML が Kubernetes アプリケーションの定義方法を簡素化することは明らかです。特に、一般的なアプリケーションに数十の構成ファイルが含まれる可能性があることを考えると。さらに、YAML のコンパクトな性質により、オブジェクトをグループ化して、必要なファイルの数を減らすことができます。
ただし、Kubernetes 構成ファイルを定義する際、特にマニフェスト ファイル間の制約と関係を埋め込む際には、大きな課題があります。たとえば、メモリ制限がベスト プラクティスに従って構成されていることを確認するにはどうすればよいでしょうか?
検証の欠如は、まれなケースが満たされたときにアプリケーションの予期しない動作につながるだけでなく、重大なセキュリティ ホールも露呈します。したがって、yaml 構成ファイルに基づいて検証戦略を検討する必要があります。これについては、次のセクションで詳しく説明します。
内容を確認する
YAML ファイルに対して 3 つのレベルの検証を実行する必要があります。これらのレベルにより、セキュリティ プラクティスが満たされるまで、YAML ファイルの実際の有効性に対して検証が実行されることが保証されます。
最初のレベルはファブリックの検証です。これは、Kubernetes 構成ファイルに対して実行される基本レベルの検証です。YAML ファイルを検証して、構文エラーがないことを確認するだけです。これは、構成ファイルの書き込み時に IDE で確認できます。
2 番目のレイヤーはセマンティック検証です。これにより、YAML ファイルの内容が必要な Kubernetes リソースに変換され、Kubernetes アプリケーション自体が認証されます。
最後に、検証の最も深い 3 番目のレイヤーは、定義された Kubernetes アプリケーションに脆弱性がないことを確認するためのセキュリティ検証です。YAML 構成が正常に作成され、必要な Kubernetes リソースと接続が正常に実装された可能性もありますが、これは、Kubernetes アプリケーションが安全であり、ベスト プラクティスに従っていることを保証するものではありません。最後の 2 つの検証は、どちらも Kubernetes 構成の検証であり、YAML 形式の検証だけではありません。アプリケーションに依存するため、特別な認証が必要です。このような検証を実行するには、Kubernetes ドメインの詳細で専門的な知識が必要です。ここでは、Kubernetes ドメインの専門家によって開発されたツールを使用して、それらを簡単に処理する方法について簡単に説明します。
たとえば、hostPath マウント権限をロックダウンすると、書き込み可能な hostPath ボリュームを持つクラスター内のコンテナーに、基盤となるホストで永続性を取得できる攻撃者がアクセスできなくなります。これはセキュリティのベスト プラクティスと一致していません。この問題を回避するには、hostPath プロパティの readOnly セクションが true に設定されていることを常に確認する必要があります。
もう 1 つの例は、必要な場合にのみ Pod にホスト ネットワーク アクセスを許可することです。権限を持つすべての Pod をホワイトリストに登録する必要があります。ホスト ネットワークへの不要なアクセスにより、潜在的な攻撃対象領域が増加します。
したがって、上記の 2 つの例からわかるように、構成ファイルが構造的およびセマンティックな検証に合格したとしても、Kubernetes リソースが正常にオーケストレーションされたとしても、セキュリティと機能の脆弱性が依然として存在する可能性があります。したがって、これらの脆弱性を見つけて、本番環境での結果を警告する最善の方法を検討する必要があります。セキュリティ検証は、これを行う方法です。
Yaml を検証するためのベスト プラクティス
構造検証が非常に簡単であることを考慮して、通常プログラミングに使用される IDE にはこの機能が組み込まれています。Kubernetes のセマンティクスとセキュリティ検証には、特にポリシーとツールに関して、特別な扱いが必要です。
YAML ファイルの包括的な検証を実現するために、いくつかのベスト プラクティスと戦略を検討します。
予行演習 ( kubectl apply -f - -dry-run='server " ) を実行してセマンティック構造を確認できますが、これは追加の手順であり、全体の速度が低下する可能性があります。ただし、予行演習では次のことを行う必要があります。 Kubernetes クラスターにアクセスできます。
このアプローチのもう 1 つのオプションは、構成ファイルのセマンティクスを検証して Kubernetes のオブジェクト定義要件を満たしていることを確認するために使用できるユーティリティである Kubeval です。これは CI プロセスの一部としてローカルでスキャンを実行することができ、本番環境に入る前に構成ファイルが意味的に検証されるようにします。
セキュリティ検証は、kuscape を使用して CI に実装することもできます。これは、Kubernetes アプリケーション定義が NSA-CISA や MITRE ATT&CK® などの複数のセキュリティ フレームワークに確実に準拠するようにするオープン ソース ツールです。kuscape CLI を使用すると、すべての YAML ファイルをスキャンしてセキュリティの脆弱性を検出し、リスク スコアとリスクの傾向を取得することもできます。これは、主な価値がセキュリティ検証である YAML バリデーターとして機能します。
DevOps から DevSecOps へ
構造、セマンティック、およびセキュリティの検証のために、CI パイプラインで既に説明したツールを組み合わせて実行できます。ただし、これらのツールと事前定義されたチェックを活用するだけでは十分ではありません。
DevOps から学べることの 1 つは、採用できる改善のサイクルが常にあるということです。そのため、アプリケーションが進化し、セキュリティ要件が変化するにつれて、セキュリティ コントロールを継続的に見直す必要があります。
新しいセキュリティ制御をセキュリティ検証手順に組み込む必要があります。kuscape は AMRO が開発したオープン ソース プラットフォームであり、独自の制御フレームワークを定義できます。すぐに使用できるフレームワークは堅牢ですが、ビジネスおよび Kubernetes リソースの特定のニーズに応じてポリシー制御を形成する必要があります。
このベスト プラクティスは、アプリケーションの構築にセキュリティ チェックを組み込むことによってのみ達成できます。Kubeval や kuscape などのオープン ソース ツールのおかげで、開発チームが検証、特にセキュリティ検証について考え続けるハードルが低くなりました。
要約する
YAML 構成ファイルを使用すると、Kubernetes アプリケーションの構築が非常に簡単になります。ただし、検証に関しては、YAML には制限があります。したがって、ビルドされた Kubernetes アプリケーションが正常で安全であることを確認するには、すべての検証戦略を理解する必要があります。
YAML ファイルの構造を検証することは、任意の IDE で YAML テストを使用して非常に簡単ですが、Kubernetes リソース オブジェクト定義とそれらを取り巻くセキュリティ対策の正確性を検証することは困難です。幸いなことに、kuscape のようなツールはこのギャップを埋め、アプリケーションのライフサイクル全体にわたってセキュリティを継続的に考慮します。
セキュリティはコンテナー アプリケーションを構築する際の主要な懸念事項の 1 つであるため、ここで説明する認証戦略は正しい方向への一歩です。
リンク: https://blog.csdn.net/weixin_44592002/article/details/127884503