第8章 ビルド時のネットワークポリシーツール


ビルド時のネットワークポリシーツールを使用すると、roxctl CLI を使用した開発および運用ワークフローでの Kubernetes ネットワークポリシーの作成と検証を自動化できます。これらのツールは、プロジェクトのワークロードおよびネットワークポリシーマニフェストなど、指定されたファイルディレクトリーで動作し、RHACS 認証を必要としません。

表8.1 ネットワークポリシーツール
コマンド説明

roxctl netpol generate

指定されたディレクトリー内のプロジェクトの YAML マニフェストを分析することにより、Kubernetes ネットワークポリシーを生成します。詳細は、ビルド時のネットワークポリシージェネレーターの使用 を参照してください。

roxctl netpol connectivity map

ワークロードと Kubernetes ネットワークポリシーマニフェストを調べて、プロジェクトディレクトリー内のワークロード間で許可されている接続をリスト表示します。出力は、さまざまなテキスト形式またはグラフィカルな .dot 形式で生成できます。詳細は、roxctl netpol connectivity map コマンドを使用した接続マッピング を参照してください。

roxctl netpol connectivity diff

2 つのプロジェクトバージョン間で許可される接続にバリエーションのリストを作成します。これは、ワークロードと各バージョンのディレクトリー内の Kubernetes ネットワークポリシーマニフェストによって決まります。この機能は、ソースコード (構文) に対して diff を実行した場合には特定できない、意味上の違いを示します。詳細は、プロジェクトバージョン間での許可される接続の違いの確認 を参照してください。

8.1. ビルド時のネットワークポリシージェネレーター

ビルド時のネットワークポリシージェネレーターは、アプリケーション YAML マニフェストに基づいて Kubernetes ネットワークポリシーを自動的に生成できます。これを使用して、クラスターにアプリケーションをデプロイする前に、継続的インテグレーション/継続的デプロイメント (CI/CD) パイプラインの一部としてネットワークポリシーを開発できます。

Red Hat は、NP-Guard プロジェクト の開発者と協力してこの機能を開発しました。まず、ビルド時のネットワークポリシージェネレーターは、ローカルフォルダー内の Kubernetes マニフェストを分析します。これには、サービスマニフェスト、config map、および PodDeploymentReplicaSetJobDaemonSetStatefulSet などのワークロードマニフェストが含まれます。次に、必要な接続を検出し、Pod の分離を実現するための Kubernetes ネットワークポリシーを作成します。これらのポリシーでは、必要なイングレスおよびエグレストラフィックをそれ以上も以下も許可しません。

8.1.1. ビルド時のネットワークポリシージェネレーターの使用

ビルド時のネットワークポリシージェネレーターは、roxctl CLI に含まれています。ビルド時のネットワークポリシー生成機能の場合、roxctl CLI は RHACS Central と通信する必要がないため、任意の開発環境で使用できます。

前提条件

  1. ビルド時のネットワークポリシージェネレーターは、コマンドの実行時に指定したディレクトリーを再帰的にスキャンします。したがって、コマンドを実行する前に、サービスマニフェスト、config map、ワークロードマニフェスト (PodDeploymentReplicaSetJobDaemonSetStatefulSet など) が、指定されたディレクトリーに YAML ファイルとしてすでに存在している必要があります。
  2. kubectl apply -f コマンドを使用して、これらの YAML ファイルを適用できることを確認します。ビルド時のネットワークポリシージェネレーターは、Helm スタイルのテンプレートを使用するファイルでは機能しません。
  3. サービスネットワークアドレスがハードコーディングされていないことを確認します。サービスに接続する必要があるすべてのワークロードは、サービスネットワークアドレスを変数として指定する必要があります。この変数は、ワークロードのリソース環境変数を使用するか、config map で指定できます。

  4. サービスネットワークアドレスは、次の公式の正規表現パターンに一致する必要があります。

    (http(s)?://)?<svc>(.<ns>(.svc.cluster.local)?)?(:<portNum>)? 1
    1
    このパターンでは、
    • <svc> はサービス名
    • <ns> はサービスを定義した namespace
    • <portNum> は公開されたサービスのポート番号

    以下は、パターンに一致するいくつかの例です。

    • wordpress-mysql:3306
    • redis-follower.redis.svc.cluster.local:6379
    • redis-leader.redis
    • http://rating-service.

手順

  1. help コマンドを実行して、ビルド時のネットワークポリシー生成機能が使用可能であることを確認します。

    $ roxctl netpol generate -h
  2. netpol generate コマンドを使用してポリシーを生成します。

    $ roxctl netpol generate <folder_path> [flags] 1
    1
    フォルダーへのパスを指定します。フォルダーには、分析用の YAML リソースを含むサブフォルダーを含めることができます。このコマンドは、サブフォルダーツリー全体をスキャンします。オプションで、パラメーターを指定してコマンドの動作を変更することもできます。

次のステップ

  • ポリシーを生成した後、関連するネットワークアドレスが YAML ファイルで期待どおりに指定されていない場合に備えて、ポリシーの完全性と正確性を検査する必要があります。
  • 最も重要なことは、必要な接続が分離ポリシーによってブロックされていないことを確認することです。この検査には、roxctl netpol 接続マップ ツールを使用できます。
注記

自動化を使用してワークロードデプロイメントの一部としてネットワークポリシーをクラスターに適用すると、時間を短縮し、正確さを確保できます。プルリクエストを使用して生成されたポリシーを送信すると、GitOps アプローチに使用でき、ポリシーをパイプラインの一部としてデプロイする前にチームはポリシーを確認する機会を得ることができます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.