JP2024508473A - コンテナフレームワークのネットワークポリシーを検証するための技術 - Google Patents

Abstract

コンテナ対の間の接続を各々示すコンテナ化環境の一組の接続経路を取得することができるネットワークポリシー検証システムのための技術が開示される。接続経路に少なくとも部分的に基づいて、一対のコンテナの第１のコンテナと第２のコンテナとを特定する。接続経路に対応しており、特定の接続の予想結果を示すネットワークポリシーを決定する。２つのコンテナの間の接続を開始することができる。結果が接続経路に対応するネットワークポリシーによって示された予想結果とは異なるという判断に少なくとも部分的に基づいて、結果をユーザ装置に提示することができる。

Description

関連出願の相互参照
このＰＣＴ出願は、２０２１年２月２６日に出願され、「コンテナフレームワークのネットワークポリシーを検証するための技術」）と題された米国特許出願第１７／１８７６３１号の優先権を主張している。当該出願の全ての内容は、あらゆる目的で参照により本開示に組み込まれる。

背景
コンテナオーケストレーションツール（container orchestration tool）は、コンピューティング環境内のコンピューティングノードの全てのクラスタのコンテナ化アプリケーションを管理および展開するためのロバストなフレームワークを提供する。これらのツールは、例示として、Kubemetes、Open Shift、Docker Swarmなどを含む。近年、クラウドベースのサービスが普及し、サービス／アプリケーションの設計が大規模なモノリシックシステムから高度に分散されたマイクロサービスベースのシステムまで変化することによって、これらのツールの使用が劇的に増加している。マイクロサービスベースのモデルにおいて、アプリケーションが、ネットワークを介して通信する多数の小さなコンポーネントを用いて構築されている。各コンポーネントは、独立して展開され、アップグレードされ、本番環境（production environment）に拡張され得る。ソフトウェア定義ネットワークは、マイクロサービスベースのモデルの不可欠な要素であり、個々のコンポーネントを中断することなくシームレスに変更することができる。システム内のコンポーネントの配置が変化するたびに、基礎的なネットワークが自動的に再構成される。このようなネットワーク内のコンポーネントは、通常、動的に割り当てられ、特定種類のコンポーネントに対して安定していないインターネットプロトコル（ＩＰ）アドレスを持っている。

これらのシステムは、しばしば、許可されたコンポーネント間のトラフィックフローを定義するネットワークポリシーの多くの宣言型構成を使用しているため、これらのシステムのネットワークポリシー（例えば、ネットワークセキュリティポリシー）を管理することは、困難である。これらのポリシーは、多くの異なるエンティティによって様々な方法で定義される可能性があるため、ユーザは、知らずに、互いに競合するポリシーまたは互いに見劣りさせるポリシーを指定することがよくある。これは、作業負荷の一部を担当する複数のグループを含む大規模システムにおいて特に問題となる。さらに、コンポーネントのラベル割り当てがネットワークポリシーとは無関係に変更されることがあり、分析をより複雑化する。このようなシステムの構成の複雑さを考えると、単一のエンティティがこれらのポリシーを管理する可能性が低い。このようなポリシーを手動で検証および／または分析するための既存の技術は、面倒であり、専門の人員を必要とし、これらのシステムの規模および複雑性に対応できない。したがって、これらのネットワークポリシーの手動処理は、殆ど実現できない。

概要
コンテナフレームワークのネットワークセキュリティルール／ポリシーを検証するための技術（例えば、方法、システム、および１つ以上のプロセッサによって実行可能なコードまたは命令を記憶する非一時的なコンピュータ可読媒体）が提供される。本明細書は、方法、システム、および１つ以上のプロセッサによって実行可能なプログラム、コードまたは命令を記憶する非一時的なコンピュータ可読記憶媒体などを含む様々な実施形態を記載している。

一実施形態は、少なくとも１つの実施形態に従って、１つ以上のネットワークセキュリティルールを検証するための方法に関する。この方法は、コンピューティング装置が、コンテナ化環境の一組の接続経路を取得することを含み得る。いくつかの実施形態において、一組の接続経路は、コンテナ化環境内のコンテナ対の間の接続を各々示す。この方法は、コンピューティング装置が、一組の接続経路のうち、１つの接続経路に少なくとも部分的に基づいて、一対のコンテナの第１のコンテナと第２のコンテナとを特定するさらに含み得る。この方法は、コンピューティング装置が、接続経路に対応するネットワークセキュリティポリシーを決定することをさらに含み得る。いくつかの実施形態において、ネットワークセキュリティポリシーは、第１のコンテナと第２のコンテナとの間の特定の接続の予想結果を示す。この方法は、コンピューティング装置が、第１のコンテナから第２のコンテナへの接続を初期化することをさらに含み得る。この方法は、コンピューティング装置が、接続の結果を判断することをさらに含み得る。この方法は、結果が接続経路に対応するネットワークポリシーによって示された予想結果とは異なるという判断に少なくとも部分的に基づいて、結果をユーザ装置に提示することをさらに含み得る。

いくつかの実施形態において、結果は、接続が確立されたことまたは接続の確立が失敗したことを示す。この方法は、一組の接続経路のうち、第１サブセットの接続経路中の各接続経路に各々対応する１つ以上のネットワークポリシーに少なくとも部分的に基づいて、第１サブセットの接続経路を正の経路（positive path）として特定することをさらに含み得る。いくつかの実施形態において、特定の接続経路を正の経路として特定することは、対応するネットワークポリシーに少なくとも部分的に基づいて、接続経路の２つのコンテナ間の接続が許可されることを決定することを含む。この方法は、一組の接続経路のうち、第２サブセットの接続経路を生成することをさらに含み得る。第２サブセットの接続経路は、負の経路（negative path）に対応する。第２サブセットの接続経路は、第１サブセットの接続経路の特定に少なくとも部分的に基づいて生成され得る。

いくつかの実施形態において、一組の接続経路を取得することは、一組の接続経路のうちの少なくとも１つの接続経路のために、実行時に、コンテナ化環境の２つのコンテナ間のネットワークトラフィックを監視することと、監視に少なくとも部分的に基づいて、対応する接続経路を生成することとをさらに含む。

いくつかの実施形態において、一組の接続経路を取得することは、一組の接続経路のうちの少なくとも１つの接続経路のために、特定のコンテナ対の間の特定の接続が許可されているかまたは許可されていないかを示す所定の接続経路を取得することをさらに含む。

この方法は、第１のコンテナが第１のラベルに関連付けられ、第２のコンテナが第２のラベルに関連付けられているという判断に少なくとも部分的に基づいて、第１のコンテナと第２のコンテナとを特定することをさらに含み得る。

いくつかの実施形態において、第１のコンテナは、第１のラベルに関連付けられた複数のコンテナのうちの１つであり、方法は、ｉ）複数のコンテナのうちの少なくとも１つの他のコンテナと第２のコンテナとの間の追加の接続を開始することと、ｉｉ）コンピューティング装置が、追加の接続の追加の結果を判断することと、ｉｉｉ）追加の結果が、接続経路に対応するネットワークポリシーによって示された予想結果とは異なるという判断に少なくとも部分的に基づいて、追加の結果を提示することとをさらに含む。

別の実施形態は、１つ以上のプロセッサと、１つ以上のプロセッサによって実行されると、コンピューティング装置に上述した方法を実行させるおよび／または構成させるコンピュータ実行可能な命令を記憶する１つ以上のメモリとを備えるコンピューティング装置に関する。

別の実施形態は、コンピューティング装置の１つ以上のプロセッサによって実行されると、コンピューティング装置に上述した方法を実行させるコンピュータ実行可能な命令を記憶する非一時的なコンピュータ可読媒体に関する。

本明細書は、方法、システム、および１つ以上のプロセッサによって実行可能なプログラム、コードまたは命令を記憶する非一時的なコンピュータ可読記憶媒体などを含む様々な実施形態を記載している。これらの例示的な実施形態は、本開示を限定または定義するためではなく、その理解を助けるための例を提供するために記載される。詳細な説明は、さらに他の実施形態を検討し、さらに他の説明を提供する。

図面を参照して、本開示の様々な実施形態を説明する。

少なくとも１つの実施形態に従って、コンピューティング環境に展開されたアプリケーションのコンポーネントのネットワークセキュリティポリシーを利用するためのコンピューティング環境１００の一例を示す図である。 少なくとも１つの実施形態に従って、図１に示されたコンピューティング環境のコンテナ化環境に展開されたアプリケーションの一例を示す図である。 少なくとも１つの実施形態に従って、コンテナベースのフレームワーク内の一群のノード上の、図２に示されるアプリケーションのコンポーネントの例示的な構成を示す図である。 少なくとも１つの実施形態に従って、コンテナベースのフレームワーク内の一群のノード上に展開されたコンテナ化アプリケーションのために、コンテナベースのフレームワークによって定義されたネットワークポリシーの様々な例を示す図である。 少なくとも１つの実施形態に従って、ネットワークトラフィックポリシーの例示的なライフサイクルを示すブロック図である。 少なくとも１つの実施形態に従って、１つ以上のネットワークセキュリティルールを静的に検証するために、検証システムによって実行された例示的な動作を示すブロック図である。 少なくとも１つの実施形態に従って、１つ以上のネットワークセキュリティルールを動的に検証するために、検証システムによって実行された例示的な動作を示すブロック図である。 少なくとも１つの実施形態に従って、１つ以上のネットワークセキュリティルールを検証するための例示的な方法を示す図である。 少なくとも１つの実施形態に従って、クラウドインフラストラクチャをサービスシステムとして実装するための１つのパターンを示すブロック図である。 少なくとも１つの実施形態に従って、サービスシステムとしてクラウドインフラストラクチャを実装するための別のパターンを示すブロック図である。 少なくとも１つの実施形態に従って、クラウドインフラストラクチャをサービスシステムとして実装するための別のパターンを示すブロック図である。 少なくとも１つの実施形態に従って、クラウドインフラストラクチャをサービスシステムとして実装するための別のパターンを示すブロック図である。 少なくとも１つの実施形態に従って、例示的なコンピュータシステムを示すブロック図である。

詳細な説明
以下の説明において、説明の目的で、特定の詳細がいくつかの実施形態の完全な理解を提供するために記載される。しかしながら、様々な実施形態がこれらの具体的な詳細なしに実施され得ることは明らかであろう。図面および説明は、限定的であることを意図しない。「例示的」という用語は、本開示において、「例示、事例または図示として機能する」ことを意味するために使用される。本開示において「例示的」として記載された任意の実施形態または設計は、必ずしも他の実施形態または設計よりも好ましいまたは有利であると解釈されるべきではない。

いくつかの手法において、しばしばデフォルトでコンテナオーケストレーションツールとして使用されているソフトウェア定義ネットワークは、システム内の全てのコンポーネント間の通信を可能にする。例えば、Kubernetsにおいて、インターネットプロトコル（ＩＰ）アドレスをアプリケーション内の全てのコンポーネント（またはポッド）に割り当てるために、共通ネットワークインターフェイスプラグインが必要とされ、これらのプラグインは、使用されている基礎ネットワークに関係なく、全てのポッド間のトラフィックを許可する。１つの手法は、仮想拡張ローカルエリアネットワーク（ＶＸＬＡＮ）などのソフトウェアベースのトンネリングプロトコルを用いて、コンピューティングインスタンスをクラスタに提供するホスト（物理マシンまたは仮想マシン）内およびホスト（物理マシンまたは仮想マシン）間で、トラフィックをシームレスに転送するフラットネットワークを提供することを含む。このようなネットワークの主な目的は、継続的に変化するワークロードに接続を提供することであるが、コンポーネント間のネットワークトラフィックのセキュリティまたは分離を提供するものではない。

従来のネットワーク制御を用いてコンテナ化アプリケーションのコンポーネント間の通信のネットワークセキュリティポリシー（簡潔にするために「ポリシー」と呼ばれる）を指定するコンテナオーケストレーションツールが直面する課題を補うために、コンテナオーケストレーションフレームワークは、アプリケーション全体のネットワークポリシー構成を指定し、それをクラスタの制御プレーンに提供することによって、クラスタ内のトラフィックを制限するためのメカニズムを提供することができる。このポリシーは、これらのコンポーネントに関連付けられたメタデータを介して、コンポーネントを間接的に指定する。例えば、Kubernetsにおいて、ポリシーの指定は、ポッドの識別子を使用せず、複数のポッドがラベルと名前空間とを共有できるポッドラベルと名前空間とを使用することができる。本明細書に使用された場合、「ポッド」とは、オーケストレーションツールによって一度に処理され得るアプリケーションの１つ以上のコンポーネントのセットを指してもよい。いくつかの実施形態において、ポッドは、コンテナオーケストレータシステムがポリシーを適用する最小の構成単位であってもよい。

いくつかの手法において、KubernetsおよびOpenShiftなどのコンテナベースのフレームワークでは、ネットワークセキュリティポリシーは、独立したオブジェクトの集合として配布される。これらのオブジェクトは、独自のライフサイクルを持ち、独立して変更され得るが、互いに影響すると共に、システム（すなわち、コンテナ化アプリケーション）の全体に影響を与える。例えば、１つのオブジェクトのポリシーは、別のオブジェクトに対して定義された別のポリシーを誤って見劣りさせる可能性がある。さらに、コンポーネントラベルなどのポリシーを指定するために使用されている要素は、ポリシー自体とは無関係に変更される可能性がある。コンポーネントの日常的な再構成は、ネットワークセキュリティポリシーに誤って影響を与える可能性がある。さらに、コンポーネントおよびネットワークセキュリティポリシーの管理が組織内の異なるチーム間に分かれている場合、コンテナベースのフレームワークが各コンポーネントのネットワークポリシー（例えば、ネットワークトラフィックポリシー）を定義するプロセスは、より難しくなる。

ネットワークポリシーの管理は、本当に連続的な配信モデルでは特に困難である。この場合、個々のコンポーネントは、独立して配信され、通常、一度にシステムに１回の変更を加える。新しいコンポーネントは、非常に頻繁に、例えば、１日に複数回に配信される可能性があり、毎回に潜在的に異なるネットワークポリシー構成を必要とする可能性がある。さらに、アップグレード時に無停止で移行できるためにまたは段階的に変更する配信モデルを提供するために、同じコンポーネントの古いバージョンと新しいバージョンは、並行して実行されていることが多い。このモデルにおいて、（処理の一部、ユーザグループまたは他の手段によって定義された）システム処理は、徐々に新しいコンポーネントに移される。変更を徐々に導入することによって、システムの完全な中断のリスクを冒すことなく、実際の環境の変更と、増加した負荷下の運用を監視することができる。さらに、コンポーネントの配置は、異なる環境、異なる機能セット、規制遵守要件、または顧客のニーズによって異なる場合がある。

ネットワークポリシーを検証するためのいくつかの手法は、意図した通りに定義され、テスト環境（test environment）に有効化されたポリシーを用いて、ワークフローを検証することを含む。しかしながら、ユーザは、ルールを適用する前に、常に完全な統合テストを実行することができない場合、利用可能な環境を有しない場合、および／または高価すぎる場合がある。時には、例えば脆弱性を排除するために、変更を緊急に展開しなければならない。さらに、統合テストは、（接続の欠如が機能退化として現れるため）必要とされる接続が許可されていることをテストするのには適しているが、陰性テストには特に適していない。ユーザは、確実にブロックしたい特定のセットの接続ケースを有し得る。このことは、拒否されると予想される合成トラフィックを開発することによって、潜在的に検証することができる。しかしながら、この手法は、リソースを不必要に利用し、実装に時間がかかる。

ネットワークポリシーの管理の複雑さから生じるさらに他の実際の問題もある。システムが成長するにつれて、ポリシーを再編成し、その構造を変更し、いくつかのルールを集約または分割することが有益な場合がある。上記のような問題があるため、これは、エラーを起こしやすい困難なタスクである。さらに、クラスタ内の特定の接続がブロックされる（許可されると予想される）または許可される（ブロックされると予想される）場合、どのルールまたはルールのセットがその問題につながるかを特定することは、自明ではないことがある。

このような環境において、ネットワークポリシーの管理／検証は、困難なタスクである。ポリシーおよび接続経路の要件は、日々変化する可能性があり、このようなネットワークポリシーの手動検証は、その速度、スピード、および自動化程度によって実行不可能である。本開示は、コンテナ化アプリケーションのネットワークポリシーを検証するための改良技術を記載する。

記載された技術によって、ユーザは、ポリシー展開サイクルの複数の時点で、予め規定されたベースライン（baseline）に対してネットワークセキュリティポリシーを包括的に検証することができる。開示されたシステムは、ポリシーの有効性に関する早期フィードバックと、意図された動作のエンドツーエンド検証との両方を提供する。このシステムは、本番環境もしくはテスト環境における検証または機能退化の観察ではなく、ポリシーが開発された初期段階で、当該ポリシーを検証することができる効率的な連続配信システムを構築することができる。また、これらの技術によって、ユーザは、クラスタエントリポイントでポリシーを検証することによって、オペレータによって手動で構成されたポリシーの有効性を保証することができる。また、ベースラインに対してクラスタ制御をテストすることによって、展開時およびランタイム時にポリシーの有効性を検証することができる。

次に図面を参照して、図１は、少なくとも１つの実施形態に従って、コンピューティング環境に展開されたアプリケーション（例えば、コンテナ化アプリケーション）のコンポーネントのネットワークポリシーを利用するためのコンピューティング環境１００（例えば、コンテナ化環境）の一例を示している。コンピューティング環境１００は、テスト環境（test environment）１１２と、本番環境（production environment）１２２とを含んでもよい。テスト環境１１２および本番環境１２２は、テスト環境１１２および本番環境１２２を実装するために、コンピュータ可読命令（例えば、コード、プログラム）を実行する１つ以上のコンピューティングシステムを備えてもよい。図１に示すように、テスト環境１１２は、テストシステム１０８を含み、本番環境１２２は、展開オーケストレータシステム１１６を含む。テスト環境１１２および本番環境１００によって処理の一部として使用されるまたは生成されるデータまたは情報の一部は、ネットワークセキュリティポリシーデータストア１２０などの永続メモリに記憶され得る。図１に示されたシステムは、コンピューティングシステムの１つ以上の処理ユニット（例えば、プロセッサ、コア）、ハードウェア、またはそれらの組み合わせによって実行されるソフトウェア（例えば、コード、命令、プログラム）を用いて実装され得る。ソフトウェアは、非一時的な記憶媒体（例えば、メモリ装置）上に記憶され得る。

図１に示されたコンピューティング環境１００は、単なる例示であり、特許請求される実施形態の範囲を不当に限定することを意図していない。当業者は、多くの可能な変形例、代替例、および修正例を認識するであろう。例えば、いくつかの実装形態において、コンピューティング環境１００は、図１に示されたものより多いまたは少ないシステムを用いて実装されてもよく、２つ以上のシステムを組み合わせてもよく、または異なるシステムおよびサブシステムの構成または配置を有してもよい。

コンピューティング環境１００は、様々な異なる構成で実装され得る。いくつかの実施形態において、テストシステム１０８および展開オーケストレータシステム１１６を含むコンピューティング環境１００は、サービスを企業のユーザに提供する企業において実装され得る。他の実施形態において、コンピューティング環境１００内のシステムは、クラウドプロバイダの１つ以上のサーバ上で実装されてもよく、システムのネットワークセキュリティポリシー作成サービスは、申し込みに基づいてクラウドサービスの申し込み者に提供され得る。

いくつかの実施形態において、ユーザは、場合によっては１つ以上の通信ネットワークを介してテストシステム１０８に通信可能に接続されているユーザ装置１０２を用いて、テストシステム１０８と対話することができる。ユーザ装置１０２は、携帯電話、タブレット、デスクトップコンピュータなどを含むがこれらに限定されない様々な種類のものであってよい。ユーザは、コンピューティング環境に展開されたアプリケーションのコンポーネントのネットワークポリシーを自動的に生成および／または検証するために、コンピューティング環境１００のシステムによって提供されたサービスに申し込む企業のユーザを表すことができる。ユーザは、ユーザ装置１０２によって実行されるブラウザを用いて、テストシステム１０８と対話することができる。例えば、ユーザは、ユーザ装置１０２によって実行されるブラウザのユーザインターフェイス（ＵＩ）（例えば、グラフィカルユーザインターフェイス（ＧＵＩ））を用いて、テストシステム１０８と対話することができる。

テストシステム１０８は、任意の適切な時点で、ネットワークセキュリティポリシーのベースラインセット（例えば、このような情報を記憶するように構成された記憶場所であるネットワークセキュリティポリシーデータストア１２０から）を取得するように構成され得る。いくつかの実施形態において、ベースラインは、正の経路（positive path）および／または負の経路（negative path）の任意の好適な組み合わせを含んでもよい。「正の経路」は、クラスタにおいて接続を有すると予想される経路を含む。これらの経路は、予想される接続が適所にあることを確立し、ポリシーの誤設定による機能退化を回避するために使用され得る。「負の経路」は、接続が遮断されると予想される経路である。負の経路をテストすることは、システムが、ポリシーまたはクラスタの誤設定によって、拒否されると意図した接続を誤って開放されないことをテストすることを可能にする。

いくつかの実施形態において、許可および／または制限された接続および／またはトラフィックフローを特定するためのネットワークセキュリティポリシーのベースラインセットは、ユーザによってまたはシステムによって定義され得る。非限定的な例として、テストシステム１０８は、１つ以上のネットワークセキュリティポリシーを、ユーザ入力として受信するように構成され得る。ユーザは、いくつかの経路が許可され、他のいくつかの経路が許可されていないことを知っているか、または確実にしたい場合がある。例えば、フロントエンドソースからバックエンドデータベースへの直接接続は、開発者が通常許可したくない経路である。この種類の経路は、システムが遮断されていると確認することができる負の経路の例である。逆に、データベースへのバックエンドソース接続が許可されるべきであり、システムは、同様にこれを確認することができる。

いくつかの実施形態において、テストシステム１０８は、ネットワークセキュリティポリシーを自動的に生成するように構成され得る。このような技術の例は、「コンピューティング環境に配置されたアプリケーションコンポーネントのネットワークセキュリティポリシーを生成する技術」と題された米国特許出願第１７／１２４１６２号に記載され、その出願の全ての内容は、あらゆる目的で参照により本開示に組み込まれる。

さらに別の例として、テストシステム１０８は、システムのトラフィックを監視することに少なくとも部分的に基づいて、ネットワークセキュリティポリシーのベースラインセットを生成するように構成され得る。システムは、クラスタ内のトラフィック経路を記録することによって経路のリストを生成し、システムが新しいトラフィックを観測するときにリストを監視し続けることができる。システムは、観測されたネットワークトラフィックから経路を特定し、これらの観測された経路を正の経路として特定することができる。正の経路のセットが確立されると、システムは、正の経路のセットに含まれていない経路を特定することによって、負の経路を生成することもできる。

１０４において、ユーザは、コンピューティング環境に展開されるアプリケーションを提供することができる。このアプリケーションは、本番環境１２２に展開され得るマイクロサービスベースのコンテナ化アプリケーションを表すことができる。いくつかの例において、アプリケーション１０４は、複数のコンポーネントを含んでもよい。各コンポーネントの複数のインスタンスは、本番環境１２２のコンテナ化環境内の一群のノードの各ノード上のコンテナとして実行され得る。いくつかの例において、コンテナ化環境は、Kubernets、OpenShift、Docker Swarmなどのコンテナオーケストレーションプラットフォームによって提供され得る。本番環境１２２に展開されたアプリケーションの例は、図２に示されている。

いくつかの例において、（１つ以上のコンポーネントを含む）アプリケーションは、コンテナ化環境に展開される前に、テストシステム１０８に提供され得る。１０５において、ユーザは、ＵＩを介して、アプリケーションのコンポーネントおよび／または本番環境１２２の他のコンポーネント間のトラフィックを許可するおよび／または拒否するための１つ以上のルールを特定する１つ以上のネットワークポリシーを提供することができる。いくつかの実施形態において、アプリケーションのネットワークポリシーは、１０４において、アプリケーションと共に提供され得る。少なくとも１つの実施形態において、ネットワークポリシーの少なくとも１つは、テストシステム１０８によって生成され得る。

いくつかの実施形態において、テストシステム１０８は、ネットワークセキュリティルールの静的検証の実行に関連する動作を実行するように構成され得る。静的検証は、設定されたポリシーに関連するネットワーク経路の接続性をテストし、アクションの実際の結果がベースラインの予想結果に一致することを検証することによって実行され得る。ベースラインネットワークセキュリティルールは、ネットワークの送着信ルールおよび接続経路としてモデル化され得る。一例として、接続経路は、接続の一端に対応するラベル、接続の他端に対応するラベル、および（任意選択で）ポートを示す経路データ構造に保存され得る。接続経路は、経路＝（ラベル）セット_１×（ラベル）セット_２×Ｐとして定義され得る。式中、（ラベル）セット_１は、１セットのコンポーネント（例えば、トラフィックが通過するコンポーネント）を特定するラベルセットであり、（ラベル）セット_１は、別のセットのコンポーネント（例えば、トラフィックが通過するコンポーネント）を特定するラベルセットであり、Ｐは、ポート番号を示し、×は、デカルト積演算を示す。着信ルールは、１つ以上のコンポーネントを選択するラベル、トラフィックの方向（例えば、着信トラフィックを示す「from」）を特定する別のラベル、および（任意選択で）トラフィックが予想されるポートを特定する異なるデータ構造（例えば、通信ポリシーデータ構造）に記憶され得る。同様に、送信ルールは、１つ以上のコンポーネントを選択するラベル、トラフィックの方向（例えば、発信トラフィックを示す「to」）を特定する別のラベル、および（任意選択で）トラフィックが予想されるポートを特定する通信ポリシーデータ構造に記憶され得る。いくつかの実施形態において、システムは、ネットワークセキュリティポリシーを生成するために、（一種のネットワークセキュリティルールである着信ポリシーとも呼ばれる）着信ルールおよび（一種のネットワークセキュリティルールである送信ポリシーとも呼ばれる）送信ルールをグループ化することができる。

いくつかの実施形態において、テストシステム１０８は、予め定義された多くの動作（例えば、設定動作、関係）を利用することができる。一例として、いくつかの動作は、様々なオブジェクトのラベルを介して様々なオブジェクトを関連付けること（ラベルの適用範囲（coverage）を決定することとも呼ばれる）に少なくとも部分的に基づいて、実行され得る。ユーザは、所定の接続経路のクエリを提出することができる。テストシステム１０８は、接続経路のデータ構造および通信ポリシーのデータ構造を利用して、ルールの「適用範囲」を特定するように、すなわち、（経路データ構造に指定された）接続経路を着信ルールまたは送信ルールにマッピングすることによって結果を生成するように構成され得る。「結果」は、ルールと経路との間の関係を指定することができる。一例として、いくつかの実施形態において、結果は、３つの値、すなわち、「なし」、「許可」および「拒否」のうちの１つであってもよい（必要であれば、より多くの値を利用してもよい）。なお、これらの値は、任意の適切な方法で示され得る（例えば、整数０を用いて「なし」を示すことができ、整数１を用いて「許可」を示すことができ、および整数２を用いて「拒否」を示すことができる）。「なし」の結果は、ルールが経路によって指定されたコンポーネントを選択しないことを示す。「許可」の結果は、ルールが経路によって指定されたコンポーネントを選択し、経路の他端へのトラフィック／からのトラフィックを許可することを示す。「拒否」の結果は、ルールが経路によって指定されたコンポーネントを選択するが、経路の他端へのトラフィック／からのトラフィックを許可しないことを示す。したがって、ユーザは、クエリを送信して、ネットワークセキュリティポリシーの結果が予期される挙動に一致する結果をもたらすか否かを静的にテストすることができる。結果が予想される挙動と一致しない場合、ユーザが通知され得る。なお、上記で説明されたネットワークポリシーを静的に検証するための技術は、任意の適切な時間（例えば、展開の前または後）に実行され得る。

いくつかの実施形態において、テストシステム１０８は、展開されるアプリケーション１０４のコンポーネントおよびそれに関連するネットワークポリシーを含む展開パッケージ１１４を生成する。本番環境１２２内の展開オーケストレータシステム１１６は、展開パッケージ１１４を受信し、この展開パッケージを用いて、アプリケーションのコンポーネントおよびそれに関連するネットワークポリシーをコンテナ化環境内の一群のノード中の異なるノードに展開する。いくつかの例において、展開オーケストレータシステム１１６は、異なるコンポーネントに関連するネットワークポリシーを特定する情報を、ネットワークセキュリティポリシーデータストア１２０に記憶する。

いくつかの状況において、アップグレード中に非停止的な移行を容易にするために、またはアプリケーション開発プロセス中に漸進的な変更配信モデルを提供するために、以前のバージョンのコンポーネントと更新された（または新しい）バージョンのコンポーネントとの両方が、しばらくの間に、コンテナ化環境に共存し、並行して動作する必要がある。いくつかの実施形態において、テストシステム１０８および展開オーケストレータシステム１１６は、コンテナ化アプリケーションの異なるバージョンのコンポーネントを、コンテナ化環境の一群のノード中の異なるコンピューティングノード上で同時に共存させるための能力を含む。さらに、システムは、異なるバージョンのコンポーネントのために異なるネットワークポリシーを生成し、生成した異なるネットワークポリシーを異なるバージョンのコンポーネントに適用するための能力を含み、各コンポーネントは、潜在的に異なるネットワーク要件を有する。

いくつかの実施形態において、テストシステム１０８は、ネットワークセキュリティルールの動的検証を実行するように構成され得る。一例として、テストシステム１０８（またはテスト環境１１２および／または本番環境１２２の別のコンポーネント）は、ネットワークセキュリティポリシーが動作可能であること（例えば、許可されるべき接続が成功し、許可されるべきではない接続が失敗すること）を検証するために、クラスタ内のコンテナ間の接続を初期化することを含むことができる。

図２は、いくつかの実施形態に従って、図１に示されたコンピューティング環境１００のコンテナ化環境に展開されたアプリケーション（例えば、コンテナ化アプリケーション）の一例を示している。コンテナ化アプリケーションは、各アプリケーションのために仮想マシン（ＶＭ）全体を起動することなく、分散型アプリケーションを展開および実行するために使用されるオペレーティングシステムレベルの方法を指す。複数の隔離されたアプリケーションまたはサービスは、単一のホスト上で動作し、同じＯＳカーネルにアクセスすることができる。図示された例において、アプリケーションは、コンピューティング環境１００の本番環境１２２内のコンテナベースのフレームワークに展開された注文処理アプリケーション２００を含む。各コンポーネントの複数のインスタンスは、コンテナベースのフレームワーク内の一群のノードの各ノード上のコンテナとして実行される。一例として、コンテナベースのフレームワークは、Kubernets、OpenShift、Docker Swarmなどのコンテナオーケストレーションツールを用いて実装され得る。

いくつかの例において、注文処理アプリケーション２００は、一組のコンポーネントを含んでもよい。これらのコンポーネントは、以下を含み得るが、これらに限定されない：
１）ウェブブラウザにおいてユーザ体験を提供する静的ウェブアプリケーションフロントエンドコンポーネント２０２、
２）ウェブアプリケーションコンポーネント（例えば、ウェブアプリケーションフロントエンドコンポーネント２０２）からのＡＰＩコールを処理し、ビジネスロジックを実装する各サービスに転送することを担当する、アプリケーションへのアプリケーションプログラミングインターフェイス（ＡＰＩ）ゲートウェイコンポーネント２０４、
３）注文、請求書およびユーザ管理などのアプリケーションの異なる機能を提供する一群のサービスコンポーネント（一例として、一群のサービスコンポーネントは、注文サービスコンポーネント２０６、ユーザサービスコンポーネント２０８、および請求書サービスコンポーネント２１０を含み得るが、これらに限定されない）、
４）データベースコンポーネント２１２およびメッセージキューコンポーネント２１４を含み、データを記憶および処理するためのデータミドルウェアコンポーネント。

いくつかの例において、説明のために、コンポーネント２０２～２１４が互いに直接通信することができると仮定する。特定の実装形態において、各コンポーネントは、その名前および対応するゾーンラベルによって示されている。一例として、ウェブアプリケーションフロントエンドコンポーネント２０２は、アプリラベル「ウェブアプリ」および対応するゾーンラベル「ウェブ」によって示され得る。さらに、図示された例において、ウェブアプリケーションフロントエンドコンポーネント２０２は、注文処理アプリケーション２００を構成する他のコンポーネントと通信しないが、ＡＰＩゲートウェイコンポーネント２０４は、サービス２０６、２０８および２１０と通信する。さらに、この例において、全てのサービスコンポーネント２０６、２０８および２１０は、互いに通信し（ただし、各サービスが各々の他のサービスと通信するとは限らない）、サービスは、データベースコンポーネント２１２と通信し、注文サービスコンポーネント２０６および請求サービスコンポーネント２１０は、メッセージキューコンポーネント２１４にアクセスする。

図２に示された注文処理アプリケーション２００の異なるコンポーネントは、単なる例示であり、特許請求される実施形態の範囲を限定することを意図していない。当業者は、多くの可能な変形例、代替例、および修正例を認識するであろう。例えば、いくつかの実装形態において、注文処理アプリケーション２００は、図１に示されたコンポーネントよりも多いまたは少ないコンポーネントを備えてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有してもよい。なお、図２に示されたコンポーネントは、２つのラベル（アプリ名を示すラベル、ゾーンを示すラベル）で示されているが、任意の適切な数のラベルは、１つ以上のコンポーネントの任意の適切な組み合わせに割り当てられてもよい。

図３は、少なくとも１つの実施形態に従って、コンテナベースのフレームワーク内の一群のノード３００上のアプリケーションのコンポーネント（図２に示す）の例示的な構成を示している。一群のノードの各ノードには、インターネットプロトコル（ＩＰ）アドレスが割り当てられる。図示された例において、一群のノード３００は、４つのノード（ノード１、ノード２、ノード３およびノード４）からなり、各ノードは、クラウド仮想クラウドネットワーク（ＶＣＮ）または物理ネットワークなどのネットワークの範囲内のＩＰアドレスを有する。一群のノードの各ノードに常駐するコンテナは、異なるＩＰアドレス範囲を使用する。異なるノード上のコンポーネント間のトラフィックは、通常トンネル化され、コンテナ間のパッケージは、ノード間のパッケージとしてカプセル化される。図示された例は、コンテナベースのフレームワークのタイムスナップショットのある時点のコンポーネントの具体的な配置を示している。フレームワークは、コンポーネントを再配置することによって、またはコンポーネントをノード間に移動することによって、負荷を分散することができる。さらに、特定のコンテナに障害が発生する可能性があり、新しいインスタンスが作成される可能性があり、ノードが追加または削除される可能性がある。このような場合において、コンテナが変更するとそのＩＰアドレスも変更する可能性が高いため、コンテナベースのフレームワークは、そのＩＰアドレスを用いてコンポーネントを特定することに基づいて任意のネットワークフィルタリング制御（例えば、ネットワークポリシー）を実装することが、非実用的であり、または実行不可能である。

前述したように、これらの課題を償うために、コンテナオーケストレーションフレームワークは、予め定義された（粗粒化された）１つ以上のネットワークポリシーを使用することによって、アプリケーションのコンポーネント間の通信（すなわち、ネットワークセキュリティ）を制御するための能力を含むことができる。例えば、KubemetesまたはOpenShiftなどのコンテナベースのフレームワークにおいて、ネットワークセキュリティポリシーは、図４に示すように、ラベル（例えば、ゾーン）などの特定のコンポーネントのメタデータに基づいて定義され得る。コンテナ化アプリケーションの複数のコンポーネント間のネットワークトラフィックを制御するために、コンテナベースのフレームワークによって定義されたネットワークセキュリティポリシーの追加の例が、図４に記載されている。

図４は、いくつかの実施形態に従って、コンテナベースのフレームワーク内の一群のノード上に展開されたコンテナ化アプリケーションのために、コンテナベースのフレームワークによって定義されたネットワークセキュリティポリシーの様々な例を示している。議論の目的のために、表４０２、４０４、および４０６に示されたネットワークセキュリティポリシーは、図２および３に記載された注文処理アプリケーション２００に関連して説明される。一実装形態において、表４０２に示されたように、一組のポリシーは、コンテナ化アプリケーション（例えば、２００）のコンポーネントのソースラベルおよび宛先ラベルとしての「ゾーンラベル」を用いて定義され得る。特定の実装形態において、一組のポリシーは、JavaScript（登録商標）オブジェクト記述（ＪＳＯＮ）オブジェクトを用いて実装されてもよく、またはＹＡＭＬオブジェクトとして実装され得る。表４０２に示されたゾーンベースのネットワークセキュリティポリシーは、ユーザサービスコンポーネント２０８からデータベースコンポーネント２１２への接続など、通常のシステム動作の一部ではないいくつかのトラフィックを許可することができる。コンテナ化アプリケーションに日常的な増分変更が生じた場合、例えば、より多くのサービスまたはデータベースミドルウェアがアプリケーションに追加された場合、これらのゾーンベースのポリシーを更新する必要がない。また、例えば、注文サービスコンポーネント２０６および請求書サービスコンポーネント２１０などのより多くのサービスが互いに通信するようになった場合でも、ゾーンベースのポリシーは、引き続き運用可能である。さらに、コンテナベースのフレームワークによって定義されたゾーンベースのポリシーは、通常、特定の経路がポリシーによって具体的にカバーされていない限り、コンポーネント間のトラフィックを許可する。このため、（「ウェブ」ゾーンまたは「フロント」ゾーンなどの）特定のコンポーネントへの内部トラフィックを拒否するために、ゾーンベースのポリシーは、「－」によって示された空の始点を有するポリシー指令を含むことができる。

別の手法において、表４０４に示すように、一組のポリシーは、「アプリラベル」（例えば、図２の２０４の「ＡＰＩゲートウェイ」などの各コンポーネントに対応する「アプリ」）をソースラベルおよび宛先ラベルとして用いて実装され得る。この場合、「アプリラベル」は、コンテナベースのアプリケーションのコンポーネントを一意に特定する。この実装形態において、システム内のネットワークトラフィックを最も正確に反映するポリシーは、表４０４に示された形態をとる。このようなポリシーは、システムにおいて予期されていない任意のトラフィックを許可しない可能性があるが、アプリケーションを変更すると、対応するポリシー変更をアプリケーションのコンポーネントに適用する必要がある。

さらに別の実装形態において、コンテナベースのフレームワークは、アプリケーションのコンポーネントを一意に特定するために使用される「ゾーンラベル」と「アプリラベル」の両方を利用する、よりバランスのとれたポリシーを実装することができる。例えば、アプリケーションのネットワーク分析は、重要なコンポーネントがメッセージキューコンポーネント２１４であることを判明することができる。ＡＰＩゲートウェイコンポーネント２０４とサービス２０６、２０８および２１０との間に一般的なゾーンベースのルールを有することは許容可能であるが、サービス自体、データベースコンポーネント２１２、およびメッセージキューコンポーネント２１４との通信は、アクセスを必要とするサービスに厳密に制限される必要がある。このような場合、一組のポリシーは、表４０６に示される形態をとることができる。なお、本開示に使用されている「ゾーンラベル」および「アプリラベル」という用語は、アプリケーション内のネットワークトラフィックの流れを定義するために、アプリケーションに利用され得るコンポーネントの一種の分類の例示である。例えば、「ゾーンラベル」は、第１バージョンのコンポーネントがトラフィックを送信することができる第１グループのコンポーネントを特定することができ、「アプリラベル」は、第１バージョンのコンポーネントがトラフィックを送信することができる第２グループのコンポーネントを特定することができる。「ゾーンラベル」は、第１バージョンのコンポーネントが第２グループのトラフィックを送信することができるより大きなグループ（例えば、セット）のコンポーネントを特定することができ、「アプリラベル」は、第１バージョンのコンポーネントがトラフィックを送信することができるより大きなグループ内の特定のセット（例えば、サブセット）のコンポーネントを特定することができる。いくつかの実施形態において、異なるラベル名、異なるラベルグループ、またはラベルの異なる層（例えば、ゾーンセル、コンポーネントを言及する４ラベルモデルなど）を用いて、アプリケーションのコンポーネントを特定およびグループ化することができる。

図５は、少なくとも１つの実施形態に従って、ネットワークトラフィックポリシーの例示的なライフサイクル５００を示すブロック図である。ネットワークトラフィックポリシーは、多くの異なるソースから発信され得る。

一例として、ネットワークセキュリティポリシーは、クラウドインフラストラクチャ（ＣＩ）／クラウド展開（ＣＤ）パイプラインの一部として由来する可能性がある。機能的な変更に取り組む開発チームは、特定の接続を開放するまたは制限する必要性を特定することができる。ネットワークポリシーは、対応するコードと共に開発され得る。５０２において、ネットワークポリシーは、アーチファクトビルド（例えば、ソフトウェアビルドの性能）の一部として、対応するコードと共にパッケージ化され得る。５０４において、ネットワークポリシーは、５０６で実行される展開プロセスの一部として、対応するコードと共に展開され得る。ネットワークセキュリティポリシーを含む新しいコードは、展開前に機能テストおよび統合テストを使用することによってテストされると仮定され得る。しかしながら、陰性テスト、すなわち、許可されべきではない（通常発生しない）トラフィックが実際にブロックされているか否かを検証するテストは、実行されない可能性が高い。

いくつかの実施形態において、オペレータは、５０８において、コンテナオーケストレータと直接に対話して、ネットワークセキュリティポリシーを作成することができる。いくつかの実施形態において、これは、例えば、ＣＩ／ＣＤ実行に従わない場合に、ネットワークセキュリティポリシーを構成する唯一の方法である。いくつかの実施形態において、オペレータは、例えば、脅威に応答して、特定のネットワークセキュリティポリシーを追加することができる。これらのシナリオにおいて、オペレータは、ポリシーを本番システムに展開する前に、ポリシーの包括的なテストを実行しないことがある。例えば、オペレータは、ステージング環境（staging environment）上でポリシーを試し、機能的な退化が発生するか否かを観察することができる。

ネットワークセキュリティポリシーの別の潜在的なソースは、観察された脅威またはネットワーク制御のニーズの変化に反応する自動システムを含んでもよい。５１０において、このような自動システムは、実行時に、ネットワークセキュリティポリシーを作成または調整することができる。

クラスタの制御プレーンであるクラスタオーケストレータ５１２は、ネットワークセキュリティポリシーを構成するためのインターフェイスを提供することができる。いくつかの実施形態において、クラスタオーケストレータ５１２は、ネットワークセキュリティポリシーが構文的に正しいか否かを決定することができる。しかしながら、通常、セマンティクス、すなわち、ポリシーが意味を成すか否か、またはポリシーが効果的であるかもしくは非破壊的であるかが、テストされる。一般的なフレームワークにおいて、ポリシーは、クラスタ状態５１４に記録される。

ネットワークオーケストレータ５１６（例えば、ネットワークドライバ）は、ネットワークセキュリティポリシーを実行して、ネットワーク制御５１８を作成することができる。ネットワークオーケストレータ５１６は、コンテナ間のネットワークをオーケストレータするために、クラスタ内に展開された別個のプラグ可能なモジュールであってもよい。クラウドネットワークインターフェイスを用いて、このようなモデルの共通インターフェイスを定義することができる。しかしながら、ネットワークセキュリティポリシーのサポートレベルは、異なるネットワークドライバによって異なる。いくつかは、このようなサポートを全く提供せず、パッケージのみを配信する。この場合、クラスタは、複数のドライバを利用する。１つのドライバは、一般的な接続に使用され、もう１つは、ネットワークポリシーサポートに使用される。多くの場合、パケットフローを管理するのは、ネットワークオーケストレータ５１６自体ではない。その代わりに、ネットワークオーケストレータ５１６は、通常、ワーカノード、ネットワークスタック、またはクラウドプロバイダのネットワーク構成などの下流システムを調整する。したがって、例えば、クラスタ内で作成されたポリシーは、ネットワークオーケストレータ５１６によってピックアップされ、トラフィックを制御するためのホストネイティブメカニズム、例えば、各ノード上のインターネットプロトコル（ＩＰ）表のルールに変更される可能性がある。

また、ネットワークセキュリティポリシーは、その特定のメカニズムの外部構成によって無効化される可能性がある。例えば、ホスト自体を管理するオペレータは、ネットワークオーケストレータ５１６によって設定されたルールを覆すルールを誤って追加することがある。このエラーは、通常、クラスタレベルでポリシーを分析するオペレータには直接に見えない。

ネットワークオーケストレータ５１６によって使用される情報は、クラスタと対話する人によってアクセスされない（または直接にアクセスされない）。クラスタのネットワークドライバがネットワークセキュリティポリシーをサポートしなくても、オペレータは、依然として、クラスタ内でネットワークセキュリティポリシーを作成し、５１４でクラスタ状態に記録されていることを確認し、全ての既存のポリシーにリストされていることを確認することができる。従来は、（例えば、ネットワークドライバであるネットワークオーケストレータ５１６がネットワークセキュリティポリシーをサポートしないため）そのポリシーが有効ではないというエラーまたは警告が提供されない。ネットワークドライバは、後の段階で削除または再設定される。これにより、ポリシーの実施を効果的に無効化することができるが、クラスタ状態５１４には反映されない。オペレータまたは自動化システムは、クラスタ状態を見ると、依然としてネットワークセキュリティポリシーがクラスタにおいて有効になっていることに気付くであろう。

上述のように、ネットワークセキュリティポリシーが予想結果を提供できない可能性がある潜在的なポイントは複数存在する。これは、ポリシー定義時のセマンティックエラー、別のポリシーの影響、ネットワークドライバまたはホスト／クラウドレベル制御の欠落または誤設定によってポリシーを無効化することに起因する可能性がある。これらの状況において、従来では、ネットワークセキュリティポリシーを展開するオペレータまたは自動システムにはフィードバックされない。

図６は、少なくとも１つの実施形態に従って、１つ以上のネットワークセキュリティルールを静的に検証するために、検証システムによって実行された例示的な動作を示すブロック図６００である。動作は、図１のテストシステム１０８、クラスタオーケストレータ６０２（例えば、図１の例示的な展開オーケストレータシステム１１６）、またはこのような検証動作を実行するように構成された別個のコンポーネント（図示せず）によって実行され得る。

６０４において、ネットワークセキュリティポリシー（例えば、正の経路または負の経路）を取得することができる。上述したように、ネットワークセキュリティポリシーは、ネットワークセキュリティポリシーのベースラインセットを取得するためのプロセスの一部として、（このような情報を記憶するように構成された記憶場所、例えば、図１のネットワークセキュリティポリシーデータストア１２０から）取得され得る。ネットワークセキュリティポリシーは、ネットワークセキュリティポリシーのベースラインセットの１つであってもよい。

いくつかの実施形態において、許可および／または制限された接続および／またはトラフィックフローを特定するネットワークセキュリティポリシーのベースラインセットは、ユーザによってまたはシステムによって定義され得る。別の例として、ネットワークセキュリティポリシーは、自動的に生成され得る。このような技術の例は、「コンピューティング環境に配置されたアプリケーションコンポーネントのネットワークセキュリティポリシーを生成する技術」と題された米国特許出願第１７／１２４１６２号に記載されている。さらに別の例として、ネットワークセキュリティポリシーのベースラインセットは、システムのトラフィックを監視することに少なくとも部分的に基づいて、生成され得る。例えば、システムは、クラスタ内のトラフィック経路を記録することによって経路のリストを生成し、システムが新しいトラフィックを観測するときにリストを監視し続けることができる。システムは、ネットワークトラフィックを観測すること（例えば、可能であれば特定のポートを介して、１つのコンテナから別のコンテナへ流れるトラフィックを特定すること）によって、正の経路を特定することができる。正の経路のセットが確立されると、正の経路のセットに含まれていない経路を特定することによって、負の経路を生成することもできる。

いくつかの実施形態において、６０４で取得されたネットワークセキュリティポリシーは、６０６で検証され、ポリシーが構文的に有効であることを確認することができる。構文検証は、プログラムの構文がプログラミングまたは文体エディタを含むか否かをチェックするプロセスである。殆ど全てのプログラミング言語の構文をチェックするツールが多数存在する。６０６においてネットワークセキュリティポリシーが無効であると判断された場合、６０８において（例えば、電子メール、テキストメッセージ、アラート、アラームなどの任意の適切な電子手段を介して）ユーザに通知され得る。

ネットワークセキュリティポリシーが構文的に有効である場合、６１０において、ネットワークセキュリティポリシーは、ネットワークセキュリティポリシーのベースラインセットに対して再び検証される。システムは、この検証を実行するために、予め定義された多くの動作（例えば、設定動作、関係）を使用することができる。一例として、いくつかの動作は、様々なオブジェクトのラベルを介して様々なオブジェクトを関連付けること（ラベルの適用範囲を決定することとも呼ばれる）に少なくとも部分的に基づいて、実行され得る。第１セットのラベルが第２セットのラベルのサブセットである場合、第１セットのラベルは、第２セットのラベルと一致する。部分集合記号⊆を用いて、ラベルのサブセットを示すことができる。

例えば、以下のラベルセットが与えられる場合、

システムは、以下のステートメントが真である（例えば、左側のラベルセットが、右側のセットのサブセットである）と見なすように構成され得る。（「｛｝」として示された）空のセットは、任意の他のセットのサブセットであると見なされ得る。

「結果」は、ルールと経路との間の関係を指定することができる。一例として、いくつかの実施形態において、結果は、３つの値、すなわち、「なし」、「許可」および「拒否」のうちの１つであってもよい（必要であれば、より多くの値を利用してもよい）。なお、これらの値は、任意の適切な方法で示され得る（例えば、整数０を用いて「なし」を示すことができ、整数１を用いて「許可」を示すことができ、および整数２を用いて「拒否」を示すことができる）。「なし」の結果は、ルールが経路によって指定されたコンポーネントを選択しないことを示す。「許可」の結果は、ルールが経路によって指定されたコンポーネントを選択し、経路の他端へのトラフィック／からのトラフィックを許可することを示す。「拒否」の結果は、ルールが経路によって指定されたコンポーネントを選択するが、経路の他端へのトラフィック／からのトラフィックを許可しないことを示す。

システムは、ルールの「適用範囲」を特定するように、すなわち、（経路データ構造に指定された）接続経路を着信ルールまたは送信ルールにマッピングすることによって結果を生成するように構成され得る。一例として、着信ルールの適用範囲は、以下のように示され得る。

同様に、送信ルールの適用範囲は、以下のように示され得る。

いくつかの実施形態において、システムは、ルールの等価性を決定するように構成され得る。ルールの等価性は、同じ種類の２つのルール（例えば、２つの送信ルール、２つの着信ルール）の間のバイナリ関係を指すことができる。両方のルールが一組の経路に対して同じ結果を有する場合、システムは、２つのルールが等価であると見なすように構成され得る。一例として、着信ルールの関係は、以下のように定義される。

送信ルールの関係は、以下のように定義される。

静的経路セットに関して、等価関係は、反射的、対称的、および推移的であり、以下のように示される。

いくつかの実施形態において、システムは、複数のルールの結果を組み合わせるように構成され得る。いくつかの実施形態において、例えば、以下のように、結果のいずれかが「許可」である場合、組み合わせられた結果は、「許可」として見なされてもよく、結果のいずれかが「拒否」である場合、組み合わせられた結果は、「拒否」として見なされてもよく、結果のいずれも「許可」または「拒否」ではない場合、結果は、「なし」として見なされ得る。

例えば、結果のいずれかが許可である場合、選択許可としてみなされ得る。結果のいずれも許可ではない場合、選択拒否としてみなされ得る。結果のいずれかが拒否であり、結果のいずれも許可ではなく、結果のいずれも拒否ではない場合、選択なしとしてみなされ得る。上記を前提として、ルール適用範囲の定義は、以下の通り、任意のルールセットに拡張され得る。

送信ルールの関係は、同様に定義され得る。さらに、等価関係は、任意のルールセットに拡張され得る。

送信ルールセットの関係は、同様に定義され得る。
システムは、多くの追加関係を定義するように構成され得る。例えば、関係「IngressPolicyCoverage」を用いて、経路および着信ポリシーを結果／ルールタプルセットにマッピングすることができる。他の関係「EgressPolicyCoverage」を用いて、経路および送信ポリシーを結果／ルールタプルセットにマッピングすることができる。別の関係「PolicyCoverage」は、経路およびポリシー全体を結果／ルールタプルセットにマッピングする使用されてもよく、着信および送信ルールマッピングの和集合（例えば、着信ポリシーの「IngressPolicyCoverage」と送信ポリシーの「EgressPolicyCoverage」との和集合）として定義され得る。別の関係「PolicyTrafficCoverage」を用いて、経路およびポリシーを結果／ルールタプルセットにマッピングすることができる。さらに別の関係「PolicyTrafficOutcome」を用いて、経路およびポリシーを結果／ルールタプルセット（例えば、PolicyTrafficCoverage）にマッピングすることができる。これらの結果は、上述した方法で組み合わせられ、単一の結果を決定することができる。

したがって、６１０において、各接続経路の各ネットワークセキュリティポリシーの適用範囲（または、少なくとも対応する接続経路の受信したネットワークセキュリティポリシー）が特定され、システムのネットワークセキュリティポリシー（例えば、受信したセキュリティポリシー）によって定義された予想挙動と比較され得る。適用範囲が予想挙動と一致する場合、ネットワークセキュリティポリシーは、有効であるとみなされ得る。不一致が確認された場合、ネットワークセキュリティポリシーは、無効であるとみなされ得る。

ネットワークセキュリティポリシーがネットワークセキュリティポリシーのベースラインセットに対して有効でない場合、６０８において、任意の適切な電子手段を介してユーザに通知する。しかしながら、ネットワークセキュリティポリシーが有効であると判断された場合、ネットワークセキュリティポリシーは、任意の適切な時点でクラスタオーケストレータ６０２によってパッケージ化され、展開され得る。

６１２において、別のネットワークセキュリティポリシーを取得することができる。一例として、オペレータは、クラスタオーケストレータ６０２のユーザインターフェイスを介して、既存のネットワークセキュリティポリシーを修正するか、または新しいネットワークセキュリティポリシーを生成することができる。別の例として、システムは、ネットワークの状態を検出することに少なくとも部分的に基づいて、ネットワークセキュリティポリシーを修正／生成するように構成され得る（例えば、１つの接続経路に沿って閾値を超えた量のトラフィックが、２つのコンポーネント間の全てのトラフィックをブロックするネットワークセキュリティポリシーをトリガすることができる）。

６１４において、クラスタオーケストレータ６０２は、６１２で受信したネットワークセキュリティポリシーが構文的に有効であるか否かを判断するための動作を実行するように構成され得る。６１６において、クラスタオーケストレータ６０２は、６１２で受信したネットワークセキュリティポリシーがベースラインに対して有効であるか否かを判断するための動作を実行するように構成され得る。これらの動作は、６０４で受信したネットワークセキュリティポリシーに関して６１０で実行された動作と同じまたは同様の動作であってもよい。６１４においてチェックが無効であると判断された場合、６１８において、ユーザは、任意の適切な電子手段を介して通知され得る。そうでない場合、６２０において、ネットワークセキュリティポリシーは、クラスタ状態に記録され得る。６２２において、ネットワークセキュリティポリシーがクラスタ状態に記録されたことを特定したことに応答して、ネットワークドライバ（例えば、図５の例示的なネットワークオーケストレータ５１６）は、ネットワークセキュリティポリシーに従って、ノードへのトラフィックおよび／またはノードからのトラフィックを許可および／またはブロックするために、１つ以上のネットワーク制御を実施するように構成され得る。

いくつかの実施形態において、ネットワークセキュリティポリシーをクラスタ状態に記録することは、図７に関連して説明したように、１つ以上のネットワークセキュリティルールを動的に検証するためのトリガとしてみなされ得る。

図７は、少なくとも１つの実施形態に従って、１つ以上のネットワークセキュリティルールを動的に検証するために、検証システムによって実行された例示的な動作を示すブロック図７００である。動作は、図１のテストシステム１０８、図１の展開オーケストレータシステム１１６、図６のクラスタオーケストレータ６０２、またはこのような検証動作を実行するように構成された別個のコンポーネント（図示せず）によって実行され得る。

７０２において、イベントベースのトリガを受信する。トリガは、様々の形であってもよい。いくつかの実施形態において、トリガは、クラスタ状態が新しいネットワークセキュリティポリシーまたは修正された（調整または削除された）ネットワークセキュリティポリシーを含むという検出であってもよい。いくつかの実施形態において、イベントベースのトリガは、ユーザが新しいネットワークセキュリティポリシーを追加することおよび／またはシステムが新しいネットワークセキュリティポリシーを生成することに応答して、受信され得る。

７０４において、所定の頻度および／または周期および／または所定のスケジュールに従って、定期的なトリガを受信する。非限定的な例として、所定のスケジュールは、特定の日および／または時間にネットワークセキュリティポリシーを動的に検証することを示すことができる。

７０６において、イベントベースのトリガおよび定期的なトリガは、動的検証プロセスをそれぞれ開始することができる。動的検証は、ネットワークセキュリティポリシーが動作可能であることを検証するために、クラスタ内で合成トラフィックを生成することを含んでもよい。ポリシーメカニズムを無効にする複数の方法が存在するため、接続がブロックされることを検証することは重要である。しかしながら、動的検証は、全ての着信トラフィックをブロックするホストレベルまたは基礎となるネットワークレベルのルールなど、トラフィックがブロックされる原因となる可能性の低い設定ミスを捕捉する可能性もある。

いくつかの実施形態において、動的検証は、テストを開始することと、テスト結果を待つこととを含む非同期プロセスである。テストは、期待されている一組の経路の接続または非接続を検証することを含む。経路接続のいずれかが期待と異なる場合、警告が生成される。

いくつかの実施形態において、動的検証は、所定の経路について、以下のこと、すなわち、
１．コンテナのインスタンスを接続のソースとして特定すること（通常、接続経路がラベルを用いて指定されるため、このプロセスは、一組のラベルと一致する（このインスタンスを含む）１つ以上のコンテナを特定することを含む）、
２．接続先のコンテナのインスタンスを特定すること、
３．ソースコンテナから宛先コンテナへの接続を開始すること、
４．接続の結果を観察すること、
５．テストの成功または失敗を報告することを含む。

テストの成功または失敗は、必ずしも接続の成功または失敗に対応しない。例えば、経路がブロックされると予想されるが、接続が成功した場合、これらの条件は、テストの失敗を示す。失敗の検証は、ネットワークポリシー実装の挙動と一致させる必要がある。例えば、ネットワークセキュリティポリシーが（例えば、ＩＰ表ＤＲＯＰターゲットを介して）接続の試行を単に無視する場合、予想される挙動は、接続タイムアウトであるべきである。他の種類の接続失敗、例えば、ソースに配信されるＩＣＭＰパケットで拒否された接続は、異常であると見なされ、ネットワークセキュリティポリシーに関する問題を示す。

コンテナオーケストレータは、通常、ラベルなどの特定の基準に一致する実行中のコンテナをリストすることを可能にするプログラム可能なインターフェイスを提供する。システムは、プログラム可能なインターフェイスを用いて、所定のテストのソースおよび宛先として動作し得る全てのコンテナの有限集合を確立することができる。例えば、ラベル｛アプリ：ユーザサービス｝に対して、そのラベルを持つ全てのサービス（例えば、図２のユーザサービス２０８）が選択される。別の例において、ラベル｛ゾーン：サービス｝に対して、ゾーン「サービス」に関連するラベル（例えば、図２の注文サービス２０６、ユーザサービス２０８、請求書サービス２１０）を持つ全てのコンテナが選択される。

大きなクラスタまたは非常に広く指定された経路（すなわち、複数の異なるコンテナを選択するラベルを使用する経路）を有するクラスタの場合、可能な組み合わせの数が膨大である。しかしながら、動的検証プロセスは、信頼できる結果を生成するために、全ての組み合わせを処理する必要はない。いくつかの実施形態において、選択されるコンテナの数は、構成可能である。例えば、システムは、各宛先のコンテナの特定の一部をランダムにテストするように構成されてもよく、または新しいコンテナのみ、または以前の動的検証の実行に接続を検証しなかったコンテナのみ（この場合、システムは、検証されたコンテナの状態を追跡する）、または最近追加されたポリシーによって選択されたコンテナ、またはこれらの要素の任意の組み合わせをテストするように構成され得る。コンテナを選択するときに考慮する要素の選択は、動的検証のトリガに依存し得る。例えば、割合または未検証のコンテナに基づく選択は、定期的なトリガに対して行われてもよく、最近追加されたポリシーによって指定されたコンテナの選択は、検証が新しいポリシーの追加によってトリガされるときに行われてもよく、コンテナの年齢に基づく選択は、新しいコンテナがクラスタに追加されるときに行われてもよい。システム管理者は、これらのルールを調整して、特定の作業負荷および意図している適用範囲に対して最適な結果を達成することができる。

エンドツーエンド検証を実行するために、検証プロセスは、コンテナのネットワーク名前空間から、ターゲットコンテナのＩＰアドレス、通常クラスタのオーバーレイネットワーク内のエフェメラルＩＰアドレスへの接続を開始する必要がある。そのために、テストを実行するソフトウェアは、コンテナの実行環境で動作する必要がある。これは、複数の方法で実現することができる。一例として、サイドカー（sidecar）アプリケーションを利用することができる。いくつかの実施形態において、クラスタオーケストレータは、新たに作成されたポッドにサイドカーアプリケーションを動的に導入するメカニズムを提供することができる。その後、サイドカーアプリケーションを利用して、所定のコンテナの名前空間から別のコンテナへの接続を開始することができる。検証を実施する別の方法は、コンテナをホストする計算インスタンス上で動作する特権プロセスを使用することである。特権プロセスは、所定のコンテナのネットワーク名前空間に入り、コンテナ環境からネットワーク接続を実行することができる。システム（例えば、コンテナ化された作業負荷をホストするための標準的なプラットフォームであるLinux（登録商標））は、このような名前空間を切り替えることができる。別の例として、システムは、Kubernetes' DaemonSetなどのメカニズムを使用して、検証ソフトウェアのインスタンスがクラスタ内の全てのインスタンス上でホストされていることを保証することができる。

いくつかの実施形態において、各々の正の経路および負の経路をテストすることができる。いくつかの実施形態において、負の経路は、システムにとって既知の正の経路セットに基づいて、ユーザによって定義または推論され得る（例えば、負の経路は、正の経路セットに含まれていない経路セットを特定することによって生成され得る）。一例として、負の経路の自動検証は、正の経路を含むベースラインが完全であると考えられるとき、すなわち、クラスタ内の全ての予想トラフィックを含むときに行うことができる。その後、システムは、ヒューリスティックにまたはランダム選択によって負の経路を検証することができる。例えば、ランダム選択は、以下のこと、すなわち、
１．（ソース）コンテナをランダムに選択すること、
２．別の（宛先）コンテナをランダムに選択すること、
３．宛先コンテナによって公開されている全ての（またはランダムな）ポートを選択すること、
４．２つのコンテナ間の特定の経路が、ベースライン経路のいずれによって拒否されているか否かをチェックすることを行うように機能することができる。

別の手法は、より直接的な選択を含むことができる。例えば、選択プロセスは、以下のこと、すなわち、
１．ソースコンテナを選択すること、
２．ソースコンテナからのトラフィックを許可する全てのコンテナ／ポートを特定すること、
３．クラスタ内に存在するが、前のステップで取得されたこの特定のコンテナから許可された宛先セット内に含まれないコンテナ／ポートセットから、宛先コンテナを選択することを含むことができる。

「動的検証のためのコンテナの選択」で説明した全ての考慮事項がここにも適用される。宛先コンテナのソースは、そこで説明した基準のいずれかに基づいて選択され得る。

７０８において、システムは、テスト結果を取得することができる。いくつかの実施形態において、テスト結果は、実行された全てのテストから得られた全ての結果を含んでもよく、またはテスト結果は、実行された一部のテストから得られた一部の結果を含んでもよい。例えば、テスト結果を取得することは、７１０で有効性をチェックする前に、全てのテスト結果を取得することを含むことができる。他の実施形態において、テスト結果は、漸増的に取得され、各テストは、次のテスト結果のセットに進む前に有効性をチェックする。

７１０において、システムは、テストの有効性を判定することができる。一例として、各テストのテスト結果は、漸増的に取得され得る。したがって、各テスト結果について、テストが有効であるか（予想される接続挙動が観察された）または有効でないか（観察された実際の接続挙動が、予想される接続挙動と一致しなかった）を判断することができる。テストが有効でない（観察された実際の接続挙動が、予想される接続挙動と一致しなかった）場合、７１２において、任意の適切な電子手段（例えば、電子メール、テキスト、アラート、アラーム、プッシュ通知など）を用いて、ユーザに警告することができる。テスト結果が漸増的に取得される場合、７０８～７１２の動作は、実施されるテストの数に応じて、任意の適切な回数に実施され得る。

７１４において、全てのテスト結果が有効であると判断された場合（例えば、各テスト結果において予想される接続挙動が観察された場合）、プロセスは、完了する。

図８は、少なくとも１つの実施形態に従って、１つ以上のネットワークセキュリティルールを検証するための例示的な方法８００を示す図である。方法８００は、任意の適切な順序で実行され得る。なお、図８を参照していくつかの動作を説明するが、より多いまたはより少ない動作を利用してもよい。いくつかの実施形態において、方法８００は、（例えば、図１のテストシステム１０８の一部として、または図１の本番環境１２２のアプリケーションおよび／またはサービスの一部としての）クエリ処理システムによって実行され得る。

方法８００は、８０２から始まる。８０２において、コンテナ化環境（例えば、環境２００）の一組の接続経路を取得することができる。いくつかの実施形態において、一組の接続経路は、コンテナ化環境内のコンテナ対の間の接続を示すことができる。

８０４において、一組の接続経路のうち、１つの接続経路に少なくとも部分的に基づいて、一対のコンテナの第１のコンテナと第２のコンテナとを特定することができる。一例として、接続経路は、ソースコンテナに対応するラベルまたは一組のラベルを特定することができる。このラベルまたは一組のラベルは、各コンテナに各々関連付けられたラベルと照合され、同じラベルに関連付けられた１つ以上のコンテナを特定することができる。同様に、接続経路は、宛先コンテナに対応する別のラベル（または一組のラベル）を特定することができる。このラベルまたは一組のラベルは、各コンテナに各々関連付けられたラベルと照合され、同じラベルに関連付けられた１つ以上のコンテナを特定することができる。したがって、システムは、ソースコンテナとして機能し得る１つ以上のコンテナと、宛先コンテナとして機能し得る１つ以上のコンテナとを特定することができる。

８０６において、接続経路に対応するネットワークポリシーを決定することができる。いくつかの実施形態において、ネットワークポリシーは、第１のコンテナと第２のコンテナとの間の特定の接続の予想結果を示す。一例として、ソースコンテナは、８０４において特定された１つ以上のソースコンテナから特定することができ、宛先コンテナは、８０４において特定された１つ以上の宛先コンテナからを特定することができる。次に、システムは、ソースコンテナに対応するラベルおよび宛先コンテナに対応するラベルを特定するネットワークポリシー（例えば、通信ポリシーデータ構造）を取得することができる。ポリシーは、トラフィックが許可またはブロックされていることを示すことができる。いくつかの実施形態において、ポリシーは、特定のポートに関連してもよい。

８０８において、第１のコンテナから第２のコンテナへの接続を初期化することができる。非限定的な一例として、サイドカーアプリケーションは、クラスタオーケストレータ（例えば、図１の展開オーケストレータシステム１１６、図６のクラスタオーケストレータ６０２など）によって提供されたインターフェイスを用いて導入され得る。クラスタオーケストレータは、このサイドカーアプリケーションを利用して、第１のコンテナから第２のコンテナへの接続を初期化することができる。

８１０において、接続の結果を判断することができる。一例として、サイドカーアプリケーションによって初期化された接続が確立される可能性があり、または接続の確立が失敗した可能性もある。

８１２において、システムは、結果が接続経路に対応するネットワークポリシーによって示された予想結果とは異なるという判断に少なくとも部分的に基づいて、結果をユーザ装置（例えば、図１のユーザ装置１１６）に提示することができる。例えば、その経路のネットワークセキュリティポリシーが、トラフィックが許可されていることを示すが、テスト結果が、接続が失敗したことを示す場合、電子メールがユーザに送信され得る。

例示的なアーキテクチャ
上述したように、ＩａａＳ（Infrastructure as a Service）は、１つの特定の種類のクラウドコンピューティングである。ＩａａＳは、パブリックネットワーク（例えば、インターネット）を介して仮想化計算リソースを提供するように構成され得る。ＩａａＳモデルにおいて、クラウドコンピューティングプロバイダは、インフラストラクチャ要素（例えば、サーバ、記憶装置、ネットワークノード（例えば、ハードウェア）、展開ソフトウェア、プラットフォーム仮想化（例えば、ハイパーバイザ層）など）をホストすることができる。場合によっては、ＩａａＳプロバイダは、インフラストラクチャ要素に付随する様々なサービス（例えば、課金、監視、ロギング、負荷分散およびクラスタリングなど）を提供することができる。したがって、これらのサービスがポリシー駆動型であり得るため、ＩａａＳユーザは、アプリケーションの可用性および性能を維持するために、負荷分散を駆動するためのポリシーを実装することができる。

いくつかの例において、ＩａａＳ顧客は、インターネットなどの広域ネットワーク（ＷＡＮ）を介してリソースおよびサービスにアクセスすることができ、クラウドプロバイダのサービスを使用してアプリケーションスタックの残りの要素をインストールすることができる。例えば、ユーザは、ＩａａＳプラットフォームにログインして、仮想マシン（ＶＭ）を作成し、各ＶＭにオペレーティングシステム（ＯＳ）をインストールし、データベースなどのミドルウェアを展開し、ワークロードおよびバックアップの記憶バケットを作成し、ＶＭに企業ソフトウェアをインストールすることができる。顧客は、プロバイダのサービスを使用して、ネットワークトラフィックのバランシング、アプリケーションのトラブルシューティング、パフォーマンスの監視、災害復旧の管理などを含む様々な機能を実行することができる。

殆どの場合、クラウドコンピューティングモデルは、クラウドプロバイダの参加を必要とする。クラウドプロバイダは、ＩａａＳの提供（例えば、オファー、レンタル、販売）に特化した第３者サービスであってもよいが、その必要はない。また、企業は、プライベートクラウドを配置し、インフラストラクチャサービスを提供するプロバイダになることもできる。

いくつかの例において、ＩａａＳの配置は、用意したアプリケーションサーバなどに新しいアプリケーションまたは新しいバージョンのアプリケーションを配置するプロセスである。ＩａａＳの配置は、サーバを用意する（例えば、ライブラリ、デーモンなどをインストールする）プロセスを含んでもよい。ＩａａＳの配置は、多くの場合、クラウドプロバイダによって、ハイパーバイザ層（例えば、サーバ、記憶装置、ネットワークハードウェア、および仮想化）の下で管理される。したがって、顧客は、ＯＳ、ミドルウェア、および／またはアプリケーションの展開（例えば、セルフサービス仮想マシン（例えば、オンデマンドでスピンアップできるもの）などを行うことができる。

いくつかの例において、ＩａａＳのプロビジョニングは、使用されるコンピュータまたは仮想ホストを取得すること、およびコンピュータまたは仮想ホスト上に必要なライブラリまたはサービスをインストールすることを含んでもよい。殆どの場合、配置は、プロビジョニングを含まず、まずプロビジョニングを実行する必要がある。

場合によっては、ＩａａＳのプロビジョニングには２つの異なる課題がある。第１に、何かを実行する前に、インフラストラクチャの初期セットをプロビジョニングするという課題がある。第２に、全てのものをプロビジョニングした後に、既存のインフラストラクチャを進化させる（例えば、新しいサービスの追加、サービスの変更、サービスの削除）という課題がある。場合によっては、インフラストラクチャの構成を宣言的に定義することを可能にすることによって、これらの２つの課題に対処することができる。言い換えれば、インフラストラクチャ（例えば、どの要素が必要とされるか、およびこれらの要素がどのように相互作用するか）は、１つ以上の構成ファイルによって定義され得る。したがって、インフラストラクチャの全体的なトポロジ（例えば、どのリソースがどれに依存するか、どのように連携するか）は、宣言的に記述することができる。いくつかの例において、トポロジが定義されると、構成ファイルに記述された異なる要素を作成および／または管理するためのワークフローを生成することができる。

いくつかの例において、インフラストラクチャは、多くの相互接続された要素を含むことができる。例えば、コアネットワークとしても知られている１つ以上の仮想プライベートクラウド（ＶＰＣ）（例えば、構成可能な計算リソースおよび／または共有されている計算リソースの潜在的なオンデマンドプール）が存在してもよい。いくつかの例において、ネットワークをどのように設定するかを定義するためにプロビジョニングされる１つ以上のグループルールと、１つ以上の仮想マシン（ＶＭ）とが存在する可能性がある。ロードバランサ、データベースなどの他のインフラストラクチャ要素もプロビジョニングされ得る。ますます多くのインフラストラクチャ要素が望まれるおよび／または追加されるにつれて、インフラストラクチャは、漸進的に進化することができる。

いくつかの例において、様々な仮想コンピューティング環境にわたってインフラストラクチャコードの展開を可能にするために、連続展開技法を採用してもよい。また、記載された技法は、これらの環境内のインフラストラクチャ管理を可能にすることができる。いくつかの例において、サービスチームは、１つ以上の、通常多くの異なる生産環境（例えば、時には全世界に及ぶ種々の異なる地理的場所にわたって）に展開されることが望まれるコードを書き込むことができる。しかしながら、いくつかの例において、コードを展開するためのインフラストラクチャを最初に設定しなければならない。いくつかの例において、プロビジョニングは、手動で行うことができ、プロビジョニングツールを用いてリソースをプロビジョニングすることができ、および／またはインフラストラクチャをプロビジョニングした後に、展開ツールを用いてコードを展開することができる。

図９は、少なくとも１つの実施形態に従って、ＩａａＳアーキテクチャの例示的なパターンを示すブロック図９００である。サービスオペレータ９０２は、仮想クラウドネットワーク（ＶＣＮ）９０６およびセキュアホストサブネット９０８を含み得るセキュアホストテナンシ９０４に通信可能に接続され得る。いくつかの例において、サービスオペレータ９０２は、１つ以上のクライアントコンピューティング装置を使用することができる。１つ以上のクライアントコンピューティング装置は、例えば、Microsoft Windows Mobile（登録商標）のようなソフトウェア、および／またはｉＯＳ、Windowsフォン、アンドロイド（登録商標）、ブラックベリー９およびパームＯＳなどのさまざまなモバイルオペレーティングシステムを実行することができ、インターネット、電子メール、ショートメッセージサービス（ＳＭＳ）、ブラックベリー（登録商標）または他の通信プロトコルが有効化された手持ち式携帯装置（例えば、iPhone（登録商標）、携帯電話、iPad（登録商標）、タブレット、携帯情報端末（ＰＤＡ）またはウェアラブル装置（Google Glass（登録商標）ヘッドマウントディスプレイ）であってもよい。クライアントコンピューティング装置は、例示として、Microsoft Windows（登録商標）オペレーティングシステム、Apple Macintosh（登録商標）オペレーティングシステムおよび／またはLinux（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む汎用のパーソナルコンピュータであってもよい。代替的には、クライアントコンピューティング装置は、例えば、さまざまなGNU/Linuxオペレーティングシステム、例えば、Google Chrome（登録商標）OSを含むがこれに限定されない市販のUNIX（登録商標）またはUNIXに類似するさまざまなオペレーティングシステムを実行するワークステーションコンピュータであってもよい。代替的にまたは追加的には、クライアントコンピューティング装置は、ＶＣＮ９０６および／またはインターネットにアクセスできるネットワークを介して通信可能な他の電子機器、例えば、シンクライアントコンピュータ、インターネット対応のゲームシステム（例えば、Kinect（登録商標）ジェスチャ入力装置を備えるまたは備えないMicrosoft Xbox（登録商標）ゲームコンソール）、および／またはパーソナルメッセージング装置であってもよい。

ＶＣＮ９０６は、ローカルピアリングゲートウェイ（ＬＰＧ）９１０を含むことができ、このＬＰＧ９１０は、ＳＳＨ ＶＣＮ９１２に含まれるＬＰＧ９１０を介してセキュアシェル（ＳＳＨ）ＶＣＮ９１２に通信可能に接続することができる。ＳＳＨ ＶＣＮ９１２は、ＳＳＨサブネット９１４を含むことができ、ＳＳＨ ＶＣＮ９１２は、制御プレーンＶＣＮ９１６に含まれるＬＰＧ９１０を介して、制御プレーンＶＣＮ９１６に通信可能に接続され得る。また、ＳＳＨ ＶＣＮ９１２は、ＬＰＧ９１０を介して、データプレーンＶＣＮ９１８に通信可能に接続され得る。制御プレーンＶＣＮ９１６およびデータプレーンＶＣＮ９１８は、ＩａａＳプロバイダによって所有および／または運営され得るサービステナンシ９１９に含まれてもよい。

制御プレーンＶＣＮ９１６は、境界ネットワーク（例えば、企業イントラネットと外部ネットワークとの間の企業ネットワークの部分）として機能する制御プレーンＤＭＺ（demilitarized zone）層９２０を含むことができる。ＤＭＺベースのサーバは、特定の信頼性を有し、セキュリティ侵害を封じ込めることができる。さらに、ＤＭＺ層９２０は、１つ以上のロードバランサ（ＬＢ）サブネット９２２と、アプリサブネット９２６を含むことができる制御プレーンアプリ層９２４と、データベース（ＤＢ）サブネット９３０（例えば、フロントエンドＤＢサブネットおよび／またはバックエンドＤＢサブネット）を含むことができる制御プレーンデータ層９２８とを含むことができる。制御プレーンＤＭＺ層９２０に含まれたＬＢサブネット９２２は、制御プレーンアプリ層９２４に含まれるアプリサブネット９２６と制御プレーンＶＣＮ９１６に含まれ得るインターネットゲートウェイ９３４とに通信可能に接続されてもよく、アプリサブネット９２６は、制御プレーンデータ層９２８に含まれるＤＢサブネット９３０と、サービスゲートウェイ９３６と、ネットワークアドレス変換（ＮＡＴ）ゲートウェイ９３８とに通信可能に接続され得る。制御プレーンＶＣＮ９１６は、サービスゲートウェイ９３６およびＮＡＴゲートウェイ９３８を含むことができる。

制御プレーンＶＣＮ９１６は、データプレーンミラーアプリ層９４０を含むことができ、データプレーンミラーアプリ層９４０は、アプリサブネット９２６を含むことができる。データプレーンミラーアプリ層９４０に含まれたアプリサブネット９２６は、計算インスタンス９４４を実行することができる仮想ネットワークインターフェイスコントローラ（ＶＮＩＣ）９４２を含むことができる。計算インスタンス９４４は、データプレーンミラーアプリ層９４０のアプリサブネット９２６を、データプレーンアプリ層９４６に含まれ得るアプリサブネット９２６に通信可能に接続することができる。

データプレーンＶＣＮ９１８は、データプレーンアプリ層９４６と、データプレーンＤＭＺ層９４８と、データプレーンデータ層９５０とを含むことができる。データプレーンＤＭＺ層９４８は、データプレーンアプリ層９４６のアプリサブネット９２６およびデータプレーンＶＣＮ９１８のインターネットゲートウェイ９３４に通信可能に接続され得るＬＢサブネット９２２を含むことができる。アプリサブネット９２６は、データプレーンＶＣＮ９１８のサービスゲートウェイ９３６およびデータプレーンＶＣＮ９１８のＮＡＴゲートウェイ９３８に通信可能に接続され得る。また、データプレーンデータ層９５０は、データプレーンアプリ層９４６のアプリサブネット９２６に通信可能に接続され得るＤＢサブネット９３０を含むことができる。

制御プレーンＶＣＮ９１６のインターネットゲートウェイ９３４およびデータプレーンＶＣＮ９１８のインターネットゲートウェイ９３４は、パブリックインターネット９５４に通信可能に接続され得るメタデータ管理サービス９５２に通信可能に接続され得る。パブリックインターネット９５４は、制御プレーンＶＣＮ９１６のＮＡＴゲートウェイ９３８およびデータプレーンＶＣＮ９１８のＮＡＴゲートウェイ９３８に通信可能に接続され得る。制御プレーンＶＣＮ９１６のサービスゲートウェイ９３６およびデータプレーンＶＣＮ９１８のサービスゲートウェイ９３６は、クラウドサービス９５６に通信可能に接続され得る。

いくつかの例において、制御プレーンＶＣＮ９１６またはデータプレーンＶＣＮ９１８のサービスゲートウェイ９３６は、パブリックインターネット９５４を経由することなく、クラウドサービス９５６へのアプリケーションプログラミングインターフェイス（ＡＰＩ）呼び出しを行うことができる。サービスゲートウェイ９３６からのクラウドサービス９５６へのＡＰＩ呼び出しは、一方向であり得る。サービスゲートウェイ９３６は、クラウドサービス９５６へのＡＰＩ呼び出しを行うことができ、クラウドサービス９５６は、要求データをサービスゲートウェイ９３６に送信することができる。しかしながら、クラウドサービス９５６は、サービスゲートウェイ９３６へのＡＰＩ呼び出しを開始しないことがある。

いくつかの例において、セキュアホストテナンシ９０４は、孤立であり得るサービステナンシ９１９に直接に接続され得る。セキュアホストサブネット９０８は、孤立のシステムとの双方向通信を可能にするＬＰＧ９１０を介して、ＳＳＨサブネット９１４と通信することができる。セキュアホストサブネット９０８をＳＳＨサブネット９１４に接続することによって、セキュアホストサブネット９０８は、サービステナンシ９１９内の他のエンティティにアクセスすることができる。

制御プレーンＶＣＮ９１６は、サービステナンシ９１９のユーザが所望のリソースを設定またはプロビジョニングすることを可能にする。制御プレーンＶＣＮ９１６においてプロビジョニングされた所望のリソースは、データプレーンＶＣＮ９１８において展開または使用され得る。いくつかの例において、制御プレーンＶＣＮ９１６は、データプレーンＶＣＮ９１８から隔離されてもよく、制御プレーンＶＣＮ９１６のデータプレーンミラーアプリ層９４０は、データプレーンミラーアプリ層９４０およびデータプレーンアプリ層９４６に含まれ得るＶＮＩＣ９４２を介して、データプレーンＶＣＮ９１８のデータプレーンアプリ層９４６と通信することができる。

いくつかの例において、システムのユーザまたは顧客は、要求をメタデータ管理サービス９５２に通信することができるパブリックインターネット９５４を介して、例えば、作成（create）、読み取り（read）、更新（update）、または削除（delte）（ＣＲＵＤ）操作などの要求を行うことができる。メタデータ管理サービス９５２は、インターネットゲートウェイ９３４を介して、要求を制御プレーンＶＣＮ９１６に通信することができる。要求は、制御プレーンＤＭＺ層９２０に含まれるＬＢサブネット９２２によって受信され得る。ＬＢサブネット９２２は、要求が有効であると判断することができ、この判断に応答して、ＬＢサブネット９２２は、要求を制御プレーンアプリ層９２４に含まれるアプリサブネット９２６に送信することができる。要求が検証され、パブリックインターネット９５４への呼び出しを必要とする場合、パブリックインターネット９５４への呼び出しを、パブリックインターネット９５４への呼び出しを行うことができるＮＡＴゲートウェイ９３８に送信することができる。要求を記憶するためのメモリは、ＤＢサブネット９３０に格納され得る。

いくつかの例において、データプレーンミラーアプリ層９４０は、制御プレーンＶＣＮ９１６とデータプレーンＶＣＮ９１８との間の直接通信を容易にすることができる。例えば、構成に対する変更、更新、または他の適切な修正は、データプレーンＶＣＮ９１８に含まれるリソースに適用されることが望ましい場合がある。制御プレーンＶＣＮ９１６は、ＶＮＩＣ９４２を介してデータプレーンＶＣＮ９１８に含まれるリソースと直接に通信することができるため、構成に対する変更、更新、または他の適切な修正を実行することができる。

いくつかの実施形態において、制御プレーンＶＣＮ９１６およびデータプレーンＶＣＮ９１８は、サービステナンシ９１９に含まれてもよい。この場合、システムのユーザまたは顧客は、制御プレーンＶＣＮ９１６またはデータプレーンＶＣＮ９１８のいずれかを所有または操作しなくてもよい。代わりに、ＩａａＳプロバイダは、制御プレーンＶＣＮ９１６およびデータプレーンＶＣＮ９１８を所有または操作してもよく、これらの両方は、サービステナンシ９１９に含まれてもよい。この実施形態は、ネットワークの隔離を可能にすることによって、ユーザまたは顧客が他のユーザのリソースまたは他の顧客のリソースと対話することを防止できる。また、この実施形態は、システムのユーザまたは顧客が、記憶するための所望のレベルのセキュリティを有しない可能性のあるパブリックインターネット９５４に依存する必要なく、データベースをプライベートに記憶することを可能にすることができる。

他の実施形態において、制御プレーンＶＣＮ９１６に含まれるＬＢサブネット９２２は、サービスゲートウェイ９３６から信号を受信するように構成され得る。この実施形態において、制御プレーンＶＣＮ９１６およびデータプレーンＶＣＮ９１８は、パブリックインターネット９５４を呼び出すことなく、ＩａａＳプロバイダの顧客によって呼び出されるように構成され得る。顧客が使用するデータベースは、ＩａａＳプロバイダによって制御され、パブリックインターネット９５４から隔離され得るサービステナンシ９１９に格納され得るため、ＩａａＳプロバイダの顧客は、この実施形態を望む場合がある。

図１０は、少なくとも１つの実施形態に従って、ＩａａＳアーキテクチャの別の例示的なパラメータを示すブロック図１０００である。サービスオペレータ１００２（例えば、図９のサービスオペレータ９０２）は、仮想クラウドネットワーク（ＶＣＮ）１００６（例えば、図９のＶＣＮ９０６）およびセキュアホストサブネット１００８（例えば、図９のセキュアホストサブネット９０８）を含み得るセキュアホストテナンシ１００４（例えば、図９のセキュアホストテナンシ９０４）に通信可能に接続され得る。ＶＣＮ１００６は、ＳＳＨ ＶＣＮ１０１２に含まれるＬＰＧ９１０を介してセキュアシェル（ＳＳＨ）ＶＣＮ１０１２（例えば、図９のＳＳＨ ＶＣＮ９１２）に通信可能に接続され得るローカルピアリングゲートウェイ（ＬＰＧ）１０１０（例えば、図９のＬＰＧ９１０）を含むことができる。ＳＳＨ ＶＣＮ１０１２は、ＳＳＨサブネット１０１４（例えば、図９のＳＳＨサブネット９１４）を含むことができ、ＳＳＨ ＶＣＮ１０１２は、制御プレーンＶＣＮ１０１６に含まれるＬＰＧ１０１０を介して制御プレーンＶＣＮ１０９（例えば、図９の制御プレーンＶＣＮ９１６）に通信可能に接続することができる。制御プレーンＶＣＮ１０９は、サービステナンシ１０１９（例えば、図９のサービステナンシ９１９）に含まれてもよく、データプレーンＶＣＮ１０１８（例えば、図９のデータプレーンＶＣＮ９１８）は、システムのユーザまたは顧客によって所有または運営され得る顧客テナンシ１０２１に含まれてもよい。

制御プレーンＶＣＮ１０１６は、ＬＢサブネット１０２２（例えば、図９のＬＢサブネット９２２）を含むことができる制御プレーンＤＭＺ層１０２０（例えば、図９の制御プレーンＤＭＺ層９２０）と、アプリサブネット１０２６（例えば、図９のアプリサブネット９２６）を含むことができる制御プレーンアプリ層１０１６（例えば、図９の制御プレーンアプリ層９２４）と、データベース（ＤＢ）サブネット１０３０（例えば、図９のＤＢサブネット９３０と同様）を含むことができる制御プレーンデータ層１０２８（例えば、図９の制御プレーンデータ層９２８）とを含むことができる。制御プレーンＤＭＺ層１０２０に含まれるＬＢサブネット１０２２は、制御プレーンアプリ層１０１６に含まれるアプリサブネット１０２６と、制御プレーンＶＣＮ１０１６に含まれ得るインターネットゲートウェイ１０３４（例えば、図９のインターネットゲートウェイ９３４）とに通信可能に接続され得る。アプリサブネット１０２６は、制御プレーンデータ層１０２８に含まれるＤＢサブネット１０３０、サービスゲートウェイ１０３６（例えば、図９のサービスゲートウェイ）およびネットワークアドレス変換（ＮＡＴ）ゲートウェイ１０３８（例えば、図９のＮＡＴゲートウェイ９３８）に通信可能に接続され得る。制御プレーンＶＣＮ１０１６は、サービスゲートウェイ１０３６およびＮＡＴゲートウェイ１０３８を含むことができる。

制御プレーンＶＣＮ１０１６は、アプリサブネット１０２６を含むことができるデータプレーンミラーアプリ層１０４０（例えば、図９のデータプレーンミラーアプリ層９４０）を含むことができる。データプレーンミラーアプリ層１０４０に含まれるアプリサブネット１０２６は、（例えば、図９の計算インスタンス９４４と同様の）計算インスタンス１０４４を実行することができる仮想ネットワークインターフェイスコントローラ（ＶＮＩＣ）１０４２（例えば、ＶＮＩＣ９４２）を含むことができる。計算インスタンス１０４４は、データプレーンミラーアプリ層１０４０に含まれるＶＮＩＣ１０４２およびデータプレーンアプリ層１０４６に含まれるＶＮＩＣ１０４２を介して、データプレーンミラーアプリ層１０４０のアプリサブネット１０２６と、データプレーンアプリ層１０４６（例えば、図９のデータプレーンアプリ層９４６）に含まれ得るアプリサブネット１０２６との間の通信を促進することができる。

制御プレーンＶＣＮ１０１６に含まれるインターネットゲートウェイ１０３４は、パブリックインターネット１０５４（例えば、図９のパブリックインターネット９５４）に通信可能に接続され得るメタデータ管理サービス１０５２（例えば、図９のメタデータ管理サービス９５２）に通信可能に接続され得る。パブリックインターネット１０５４は、制御プレーンＶＣＮ１０１６に含まれるＮＡＴゲートウェイ１０３８に通信可能に接続され得る。制御プレーンＶＣＮ１０１６に含まれるサービスゲートウェイ１０３６は、クラウドサービス１０５６（例えば、図９のクラウドサービス９５６）に通信可能に接続され得る。

いくつかの例において、データプレーンＶＣＮ１０１８は、顧客テナンシ１０２１に含まれてもよい。この場合、ＩａａＳプロバイダは、顧客ごとに制御プレーンＶＣＮ１０１６を提供することができ、ＩａａＳプロバイダは、顧客ごとに、サービステナンシ１０１９に含まれる固有の計算インスタンス１０４４を構成することができる。各計算インスタンス１０４４は、サービステナンシ１０１９に含まれる制御プレーンＶＣＮ１０１６と、顧客テナンシ１０２１に含まれるデータプレーンＶＣＮ１０１８との間の通信を許可することができる。計算インスタンス１０４４は、サービステナンシ１０１９に含まれる制御プレーンＶＣＮ１０１６においてプロビジョニングされるリソースを、顧客テナンシ１０２１に含まれるデータプレーンＶＣＮ１０１８に展開することまたは使用することを許可することができる。

他の例において、ＩａａＳプロバイダの顧客は、顧客テナンシ１０２１に存在するデータベースを有することができる。この例において、制御プレーンＶＣＮ１０１６は、アプリサブネット１０２６を含むことができるデータプレーンマイナーアプリ層１０４０を含むことができる。データプレーンミラーアプリ層１０４０は、データプレーンＶＣＮ１０１８に存在してもよいが、データプレーンミラーアプリ層１０４０は、データプレーンＶＣＮ１０１８に存在しなくてもよい。すなわち、データプレーンミラーアプリ層１０４０は、顧客テナンシ１０２１にアクセスすることができるが、データプレーンミラーアプリ層１０４０は、データプレーンＶＣＮ１０１８に存在しなくてもよく、ＩａａＳプロバイダの顧客によって所有または運営されなくてもよい。データプレーンミラーアプリ層１０４０は、データプレーンＶＣＮ１０１８への呼び出しを行うように構成され得るが、制御プレーンＶＣＮ１０１６に含まれる任意のエンティティへの呼び出しを行うように構成されなくてもよい。顧客は、制御プレーンＶＣＮ１０１６にプロビジョニングされたデータプレーンＶＣＮ１０１８内のリソースを展開することまたは使用することを望むことができ、データプレーンミラーアプリケーション階層１０４０は、顧客のリソースの所望の展開または他の使用を促進することができる。

いくつかの実施形態において、ＩａａＳプロバイダの顧客は、フィルタをデータプレーンＶＣＮ１０１８に適用することができる。この実施形態において、顧客は、データプレーンＶＣＮ１０１８がアクセスできるものを決定することができ、顧客は、データプレーンＶＣＮ１０１８からのパブリックインターネット１０５４へのアクセスを制限することができる。ＩａａＳプロバイダは、データプレーンＶＣＮ１０１８から任意の外部ネットワークまたはデータベースへのアクセスにフィルタを適用するまたは制御することができない場合がある。顧客が顧客テナンシ１０２１に含まれるデータプレーンＶＣＮ１０１８にフィルタおよび制御を適用することは、データプレーンＶＣＮ１０１８を他の顧客およびパブリックインターネット１０５４から隔離することを支援することができる。

いくつかの実施形態において、クラウドサービス１０５６は、サービスゲートウェイ１０３６によって呼び出されて、パブリックインターネット１０５４上に、制御プレーンＶＣＮ１０１６上に、またはデータプレーンＶＣＮ１０１８上に存在していない可能性があるサービスにアクセスすることができる。クラウドサービス１０５６と制御プレーンＶＣＮ１０１６またはデータプレーンＶＣＮ１０１８との間の接続は、ライブまたは連続的でなくてもよい。クラウドサービス１０５６は、ＩａａＳプロバイダによって所有または運営されている別のネットワーク上に存在してもよい。クラウドサービス１０５６は、サービスゲートウェイ１０３６から呼び出しを受信するように構成されてもよく、パブリックインターネット１０５４から呼び出しを受信しないように構成され得る。いくつかのクラウドサービス１０５６は、他のクラウドサービス１０５６から隔離されてもよく、制御プレーンＶＣＮ１０１６は、制御プレーンＶＣＮ１０１６と同じ地域に配置していない可能性があるクラウドサービス１０５６から隔離され得る。例えば、制御プレーンＶＣＮ１０１６は、「地域１」に配置されてもよく、クラウドサービス「展開８」は、「地域１」および「地域２」に配置され得る。展開８への呼び出しが地域１に配置された制御プレーンＶＣＮ１０１６に含まれるサービスゲートウェイ１０３６によって行われる場合、この呼び出しは、地域１内の展開８に送信され得る。この例において、制御プレーンＶＣＮ１０１６または地域１の展開８は、地域２の展開８と通信可能に接続されなくてもよい。

図１１は、少なくとも１つの実施形態に従って、ＩａａＳアーキテクチャの別の例示的なパターンを示すブロック図１１００である。サービスオペレータ１１０２（例えば、図９のサービスオペレータ９０２）は、仮想クラウドネットワーク（ＶＣＮ）１１０６（例えば、図９のＶＣＮ９０６）およびセキュアホストサブネット１１０８（例えば、図９のセキュアホストサブネット９０８）を含み得るセキュアホストテナンシ１１０４（例えば、図９のセキュアホストテナンシ９０４）に通信可能に接続され得る。ＶＣＮ１１０６は、ＳＳＨ ＶＣＮ１１１２に含まれるＬＰＧ１１１０を介してＳＳＨ ＶＣＮ１１１２（例えば、図９のＳＳＨ ＶＣＮ９１２）に通信可能に接続され得るＬＰＧ１１１０（例えば、図９のＬＰＧ９１０）を含むことができる。ＳＳＨ ＶＣＮ１１１２は、ＳＳＨサブネット１１１４（例えば、図９のＳＳＨサブネット９１４）を含むことができ、ＳＳＨ ＶＣＮ１１１２は、制御プレーンＶＣＮ１１１６に含まれるＬＰＧ１１１０を介して制御プレーンＶＣＮ１１１６（例えば、図９の制御プレーンＶＣＮ９１６）に通信可能に接続されてもよく、データプレーンＶＣＮ１１１８に含まれるＬＰＧ１１１０を介してデータプレーンＶＣＮ１１１８（例えば、図９のデータプレーン９１８）に通信可能に接続され得る。制御プレーンＶＣＮ１１１６およびデータプレーンＶＣＮ１１１８は、サービステナンシ１１１９（例えば、図９のサービステナント９１９）に含まれてもよい。

制御プレーンＶＣＮ１１１６は、ロードバランサ（ＬＢ）サブネット１１２２（例えば、図９のＬＢサブネット９２２）を含むことができる制御プレーンＤＭＺ層１１２０（例えば、図９の制御プレーンＤＭＺ層９２０）と、アプリサブネット１１２６（例えば、図９のアプリサブネット９２６と同様）を含むことができる制御プレーンアプリ層１１２４（例えば、図９の制御プレーンアプリ層９２４）と、ＤＢサブネット１１３０を含むことができる制御プレーンデータ層１１２８（例えば、図９の制御プレーンデータ層９２８）とを含むことができる。制御プレーンＤＭＺ層１１２０に含まれるＬＢサブネット１１２２は、制御プレーンアプリ層１１２４に含まれるアプリサブネット１１２６と、制御プレーンＶＣＮ１１１６に含まれ得るインターネットゲートウェイ１１３４（例えば、図９のインターネットゲートウェイ９３４）とに通信可能に接続され得る。アプリサブネット１１２６は、制御プレーンデータ層１１２８に含まれるＤＢサブネット１１３０と、サービスゲートウェイ１１３６（例えば、図９のサービスゲートウェイ）およびネットワークアドレス変換（ＮＡＴ）ゲートウェイ１１３８（例えば、図９のＮＡＴゲートウェイ９３８）とに通信可能に接続され得る。制御プレーンＶＣＮ１１１６は、サービスゲートウェイ１１３６およびＮＡＴゲートウェイ１１３８を含むことができる。

データプレーンＶＣＮ１１１８は、データプレーンアプリ層１１４６（例えば、図９のデータプレーンアプリ層９４６）と、データプレーンＤＭＺ層１１４８（例えば、図９のデータプレーンＤＭＺ層９４８）と、データプレーンデータ層１１５０（例えば、図９のデータプレーンデータ階層９５０）とを含むことができる。データプレーンＤＭＺ層１１４８は、データプレーンＶＣＮ１１１８に含まれるデータプレーンアプリ層１１４６およびインターネットゲートウェイ１１３４の信頼できるアプリサブネット１１６０および信頼できないアプリサブネット１１６２に通信可能に接続され得るＬＢサブネット１１２２を含むことができる。信頼できるアプリサブネット１１６０は、データプレーンＶＣＮ１１１８に含まれるサービスゲートウェイ１１３６、データプレーンＶＣＮ１１１８に含まれるＮＡＴゲートウェイ１１３８、およびデータプレーンデータ層１１５０に含まれるＤＢサブネット１１３０に通信可能に接続され得る。信頼できないアプリサブネット１１６２は、データプレーンＶＣＮ１１１８に含まれるサービスゲートウェイ１１３６、およびデータプレーンデータ層１１５０に含まれるＤＢサブネット１１３０に通信可能に接続され得る。データプレーンデータ層１１５０は、データプレーンＶＣＮ１１１８に含まれるサービスゲートウェイ１１３６に通信可能に接続され得るＤＢサブネット１１３０を含むことができる。

信頼できないアプリサブネット１１６２は、テナント仮想マシン（ＶＭ）１１６６（１）～（Ｎ）に通信可能に接続され得る１つ以上のプライマリＶＮＩＣ１１６４（１）～（Ｎ）を含むことができる。各テナントＶＭ１１６６（１）～（Ｎ）は、それぞれの顧客テナンシ１１７０（１）～（Ｎ）に含まれ得るそれぞれのコンテナ送信ＶＣＮ１１６８（１）～（Ｎ）に含まれ得るそれぞれのアプリサブネット１１６７（１）～（Ｎ）に通信可能に接続され得る。それぞれのセカンダリＶＮＩＣ１１７２（１）～（Ｎ）は、データプレーンＶＣＮ１１１８に含まれる信頼できないアプリサブネット１１６２と、コンテナ送信ＶＣＮ１１６８（１）～（Ｎ）に含まれるアプリサブネットとの間の通信を促進することができる。各コンテナ送信ＶＣＮ１１６８（１）～（Ｎ）は、パブリックインターネット１１５４（例えば、図９のパブリックインターネット９５４）に通信可能に接続され得るＮＡＴゲートウェイ１１３８を含むことができる。

制御プレーンＶＣＮ１１１６に含まれるインターネットゲートウェイ１１３４およびデータプレーンＶＣＮ１１１８に含まれるインターネットゲートウェイ１１３４は、パブリックインターネット１１５４に通信可能に接続され得るメタデータ管理サービス１１５２（例えば、図９のメタデータ管理システム９５２）に通信可能に接続され得る。パブリックインターネット１１５４は、制御プレーンＶＣＮ１１１６に含まれるＮＡＴゲートウェイ１１３８およびデータプレーンＶＣＮ１１１８に含まれるＮＡＴゲートウェイ１１３８に通信可能に接続され得る。制御プレーンＶＣＮ１１１６に含まれるサービスゲートウェイ１１３６およびデータプレーンＶＣＮ１１１８に含まれるサービスゲートウェイ１１３６は、クラウドサービス１１５６に通信可能に接続され得る。

いくつかの実施形態において、データプレーンＶＣＮ１１１８は、顧客テナンシ１１７０に統合され得る。この統合は、コードを実行するときにサポートを望む場合がある場合などのいくつかの場合において、ＩａａＳプロバイダの顧客にとって有用または望ましい場合がある。顧客は、実行すると、破壊的であり得る、他の顧客リソースと通信し得る、または望ましくない影響を引き起こし得るコードを提供することがある。従って、ＩａａＳプロバイダは、顧客がＩａａＳプロバイダに提供したコードを実行するか否かを判断することができる。

いくつかの例において、ＩａａＳプロバイダの顧客は、一時的なネットワークアクセスをＩａａＳプロバイダに許可することができ、データプレーンアプリ層１１４６に追加する機能を要求することができる。機能を実行するためのコードは、ＶＭ１１６６（１）～（Ｎ）で実行され得るが、データプレーンＶＣＮ１１１８上の他の場所で実行されるように構成されることができない。各ＶＭ１１６６（１）～（Ｎ）は、１つの顧客テナンシ１１７０に接続され得る。ＶＭ１１６６（１）～（Ｎ）に含まれるそれぞれのコンテナ１１７１（１）～（Ｎ）は、コードを実行するように構成され得る。この場合、二重の隔離（例えば、コンテナ１１７１（１）～（Ｎ）は、コードを実行し、コンテナ１１７１（１）～（Ｎ）は、少なくとも、信頼できないアプリサブネット１１６２に含まれるＶＭ１１６６（１）～（Ｎ）に含まれ得る）が存在してもよく、これは、誤ったコードまたは望ましくないコードがＩａａＳプロバイダのネットワークに損傷を与えること、または異なる顧客のネットワークに損傷を与えることを防止することを支援することができる。コンテナ１１７１（１）～（Ｎ）は、顧客テナンシ１１７０に通信可能に接続されてもよく、顧客テナンシ１１７０からデータを送信または受信するように構成され得る。コンテナ１１７１（１）～（Ｎ）は、データプレーンＶＣＮ１１１８内の任意の他のエンティティからデータを送信または受信するように構成されなくてもよい。コードの実行が完了すると、ＩａａＳ提供者は、コンテナ１１７１（Ｉ）～（Ｎ）をキルするまたは廃棄することができる。

いくつかの実施形態において、信頼できるアプリサブネット１１６０は、ＩａａＳプロバイダによって所有または運営され得るコードを実行することができる。この実施形態において、信頼できるアプリサブネット１１６０は、ＤＢサブネット１１３０に通信可能に接続され、ＤＢサブネット１１３０においてＣＲＵＤ操作を実行するように構成され得る。信頼できないアプリサブネット１１６２は、ＤＢサブネット１１３０に通信可能に接続され得るが、この実施形態において、信頼できないアプリサブネットは、ＤＢサブネット１１３０内で読み取り操作を実行するように構成され得る。各顧客のＶＭ１１６６（１）～（Ｎ）に含まれ、顧客からのコードを実行することができるコンテナ１１７１（１）～（Ｎ）は、ＤＢサブネット１１３０と通信可能に接続されなくてもよい。

他の実施形態において、制御プレーンＶＣＮ１１１６およびデータプレーンＶＣＮ１１１８は、通信可能に直接に結合されなくてもよい。この実施形態において、制御プレーンＶＣＮ１１１６とデータプレーンＶＣＮ１１１８との間に直接的な通信は、存在しないことがある。しかしながら、少なくとも１つの方法による間接的な通信は、存在してもよい。制御プレーンＶＣＮ１１１６とデータプレーンＶＣＮ１１１８との間の通信を容易にすることができるＬＰＧ１１１０が、ＩａａＳプロバイダによって確立され得る。別の例において、制御プレーンＶＣＮ１１１６またはデータプレーンＶＣＮ１１１８は、サービスゲートウェイ１１３６を介してクラウドサービス１１５６への呼び出しを行うことができる。例えば、制御プレーンＶＣＮ１１１６からクラウドサービス１１５６への呼び出しは、データプレーンＶＣＮ１１１８と通信することができるサービスの要求を含むことができる。

図１２は、少なくとも１つの実施形態に従って、ＩａａＳアーキテクチャの別の例示的なパラメータを示すブロック図１２００である。サービスオペレータ１２０２（例えば、図９のサービスオペレータ９０２）は、仮想クラウドネットワーク（ＶＣＮ）１２０６（例えば、図９のＶＣＮ９０６）およびセキュアホストサブネット１２０８（例えば、図９のセキュアホストサブネット９０８）を含み得るセキュアホストテナンシ１２０４（例えば、図９のセキュアホストテナンシ９０４）に通信可能に接続され得る。ＶＣＮ１２０６は、ＳＳＨ ＶＣＮ１２１２に含まれるＬＰＧ１２１０を介してＳＳＨ ＶＣＮ１２１２（例えば、図９のＳＳＨ ＶＣＮ９１２）に通信可能に接続され得るＬＰＧ１２１０（例えば、図９のＬＰＧ９１０）を含むことができる。ＳＳＨ ＶＣＮ１２１２は、ＳＳＨサブネット１２１４（例えば、図９のＳＳＨサブネット９１４）を含むことができ、ＳＳＨ ＶＣＮ１２１２は、制御プレーンＶＣＮ１２１６に含まれるＬＰＧ１２１０を介して制御プレーンＶＣＮ１２１６（例えば、図９の制御プレーンＶＣＮ９１６）に通信可能に接続されてもよく、データプレーンＶＣＮ１２１８に含まれるＬＰＧ１２１０を介してデータプレーンＶＣＮ１２１８（例えば、図９のデータプレーン９１８）に通信可能に接続され得る。制御プレーンＶＣＮ１２１６およびデータプレーンＶＣＮ１２１８は、サービステナンシ１２１９（例えば、図９のサービステナンシ９１９）に含まれてもよい。

制御プレーンＶＣＮ１２１６は、ＬＢサブネット１２２２（例えば、図９のＬＢサブネット９２２）を含み得る制御プレーンＤＭＺ層１２２０（例えば、図９の制御プレーンＤＭＺ層９２０）、アプリサブネット１２２６（例えば、図９のアプリサブネット９２６）を含み得る制御プレーンアプリ層１２２４（例えば、図９の制御プレーンアプリ層９２４）、ＤＢサブネット１２３０（例えば、図１１のＤＢサブネット１１３０）を含み得る制御プレーンデータ層１２２８（例えば、図９の制御プレーンデータ層９２８）を含むことができる。制御プレーンＤＭＺ層１２２０に含まれるＬＢサブネット１２２２は、制御プレーンアプリ層１２２４に含まれるアプリサブネット１２２６と、制御プレーンＶＣＮ１２１６に含まれ得るインターネットゲートウェイ１２３４（例えば、図９のインターネットゲートウェイ９３４）とに通信可能に接続され得る。アプリサブネット１２２６は、制御プレーンデータ層１２２８に含まれるＤＢサブネット１２３０と、サービスゲートウェイ１２３６（例えば、図９のサービスゲートウェイ）およびネットワークアドレス変換（ＮＡＴ）ゲートウェイ１２３８（例えば、図９のＮＡＴゲートウェイ９３８）とに通信可能に接続され得る。制御プレーンＶＣＮ１２１６は、サービスゲートウェイ１２３６およびＮＡＴゲートウェイ１２３８を含むことができる。

データプレーンＶＣＮ１２１８は、データプレーンアプリ層１２４６（例えば、図９のデータプレーンアプリ層９４６）、データプレーンＤＭＺ層１２４８（例えば、図９のデータプレーンＤＭＺ層９４８）、およびデータプレーンデータ層１２５０（例えば、図９のデータプレーンデータ層９５０）を含むことができる。データプレーンＤＭＺ層１２４８は、データプレーンアプリ層１２４６の信頼できるアプリサブネット１２６０（例えば、図１１の信頼できるアプリサブネット１１６０）および信頼できないアプリサブネット１２６２（例えば、図１１の信頼できないアプリサブネット１１６２）およびデータプレーンＶＣＮ１２１８に含まれるインターネットゲートウェイ１２３４に通信可能に接続され得るＬＢサブネット１２２２を含むことができる。信頼できるアプリサブネット１２６０は、データプレーンＶＣＮ１２１８に含まれるサービスゲートウェイ１２３６、データプレーンＶＣＮ１２１８に含まれるＮＡＴゲートウェイ１２３８、およびデータプレーンデータ層１２５０に含まれるＤＢサブネット１２３０に通信可能に接続され得る。信頼できないアプリサブネット１２６２は、データプレーンＶＣＮ１２１８に含まれるサービスゲートウェイ１２３６、およびデータプレーンデータ層１２５０に含まれるＤＢサブネット１２３０に通信可能に接続され得る。データプレーンデータ層１２５０は、データプレーンＶＣＮ１２１８に含まれるサービスゲートウェイ１２３６に通信可能に接続され得るＤＢサブケット１２３０を含むことができる。

信頼できないアプリサブネット１２６２は、信頼できないアプリサブネット１２６２に常駐するテナント仮想マシン（ＶＭ）１２６６（１）～（Ｎ）に通信可能に接続され得るプライマリＹＮＩＣ１２６４（１）～（Ｎ）を含むことができる。各テナントＶＭ１２６６（１）～（Ｎ）は、それぞれのコンテナ１２６７（１）～（Ｎ）においてコードを実行することができ、コンテナ送信ＶＣＮ１２６８に含まれ得るデータプレーンアプリ層１２４６に含まれ得るアプリサブネット１２２６に通信可能に接続され得る。各セカンダリＶＮＩＣ１２７２（１）～（Ｎ）は、データプレーンＶＣＮ１２１８に含まれる信頼できないアプリサブネット１２６２とコンテナ送信ＶＣＮ１２６８に含まれるアプリサブネットとの間の通信を促進することができる。コンテナ送信ＶＣＮは、パブリックインターネット１２５４（例えば、図９のパブリックインターネット９５４）に通信可能に接続することができるＮＡＴゲートウェイ１２３８を含むことができる。

制御プレーンＶＣＮ１２１６に含まれるインターネットゲートウェイ１２３４およびデータプレーンＶＣＮ１２１８に含まれるインターネットゲートウェイ１２３４は、パブリックインターネット１２５４に通信可能に接続され得るメタデータ管理サービス１２５２（例えば、図９のメタデータ管理システム９５２）に通信可能に接続され得る。パブリックインターネット１２５４は、制御プレーンＶＣＮ１２１６に含まれるインターネットゲートウェイ１２３４およびデータプレーンＶＣＮ１２１８に含まれるＮＡＴゲートウェイ１２３８に通信可能に接続され得る。制御プレーンＶＣＮ１２１６に含まれるインターネットゲートウェイ１２３４およびデータプレーンＶＣＮ１２１８に含まれるサービスゲートウェイ１２３６は、クラウドサービス１２５６に通信可能に接続され得る。

いくつかの例において、図１２のブロック図１２００のアーキテクチャによって示されたパターンは、図１１のブロック図１１００のアーキテクチャによって示されたパターンの例外と考えられ、ＩａａＳプロバイダが顧客と直接に通信できない（例えば、非接続地域）場合、ＩａａＳプロバイダの顧客にとって望ましいことがある。顧客は、各顧客のＶＭ１２６６（１）～（Ｎ）に含まれるそれぞれのコンテナ１２６７（１）～（Ｎ）にリアルタイムでアクセスすることができる。コンテナ１２６７（１）～（Ｎ）は、コンテナ送信ＶＣＮ１２６８に含まれ得るデータプレーンアプリ層１２４６のアプリサブネット１２２６に含まれるそれぞれのセカンダリＶＮＩＣ１２７２（１）～（Ｎ）を呼び出すように構成され得る。セカンダリＶＮＩＣ１２７２（１）～（Ｎ）は、パブリックインターネット１２５４に呼び出しを送信することができるＮＡＴゲートウェイ１２３８に呼び出しを送信することができる。この例において、顧客がリアルタイムでアクセスできるコンテナ１２６７（１）～（Ｎ）は、制御プレーンＶＣＮ１２１６から隔離されてもよく、データプレーンＶＣＮ１２１８に含まれる他のエンティティから隔離され得る。また、コンテナ１２６７（１）～（Ｎ）は、他の顧客のリソースから隔離され得る。

他の例において、顧客は、コンテナ１２６７（１）～（Ｎ）を使用して、クラウドサービス１２５６を呼び出すことができる。この例では、顧客は、コンテナ１２６７（１）～（Ｎ）において、クラウドサービス１２５６からサービスを要求するコードを実行することができる。コンテナ１２６７（１）～（Ｎ）は、要求をパブリックインターネット１２５４に送信することができるＮＡＴゲートウェイに要求を送信することができるセカンダリＶＮＩＣ１２７２（１）～（Ｎ）にこの要求を送信することができる。パブリックインターネット１２５４は、インターネットゲートウェイ１２３４を介して、制御プレーンＶＣＮ１２１６に含まれるＬＢサブネット１２２２にこの要求を送信することができる。要求が有効であるとの判断に応答して、ＬＢサブネットは、この要求をアプリサブネット１２２６に送信することができ、アプリサブネット１２２６は、サービスゲートウェイ１２３６を介して、この要求をクラウドサービス１２５６に要求を送信することができる。

なお、図示されたＩａａＳアーキテクチャ９００、１０００、１１００および１２００は、図示されたもの以外の要素を含んでもよい。また、図示された実施形態は、本開示の実施形態を組み込むことができるクラウドインフラストラクチャシステムの一部の例に過ぎない。他のいくつかの実施形態において、ＩａａＳシステムは、図示されたものよりも多いまたは少ない要素を有してよく、２つ以上の要素を組み合わせてよく、または要素の異なる構成または配置を有してよい。

特定の実施形態において、本開示に記載されたＩａａＳシステムは、セルフサービス、サブスクリプションベース、柔軟な拡張可能性、信頼性、高可用性、および安全な方法で顧客に提供されるアプリケーション、ミドルウェア、およびデータベースサービスのスイートを含むことができる。このようなＩａａＳシステムの一例は、本出願人によって提供されたオラクル（登録商標）クラウドインフラストラクチャ（ＯＣＩ）である。

図１３は、様々な実施形態が実装され得る例示的なコンピュータシステム１３００を示す。システム１３００は、上述したコンピュータシステムのいずれかを実装するために使用され得る。図示のように、コンピュータシステム１３００は、バスサブシステム１３０２を介して多数の周辺サブシステムと通信する処理ユニット１３０４を含む。これらの周辺サブシステムは、処理加速ユニット１３０６、Ｉ／Ｏサブシステム１３０８、記憶サブシステム１３１８、および通信サブシステム１３２４を含んでもよい。記憶サブシステム１３１８は、有形のコンピュータ可読記憶媒体１３２２およびシステムメモリ１３１０を含む。

バスサブシステム１３０２は、コンピュータシステム１３００の様々な構成要素およびサブシステムを意図したように相互に通信させるための機構を提供する。バスサブシステム１３０２は、単一のバスとして概略的に示されているが、バスサブシステムの代替的な実施形態は、複数のバスを利用してもよい。バスサブシステム１３０２は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスを含む、いくつかの種類のバス構造のいずれかであってもよい。例えば、このようなアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）、バス拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子標準協会（ＶＥＳＡ）ローカルバス、およびＩＥＥＥ Ｐ１３８６．１標準に準拠して製造されたメザニンバスとして実装できる周辺機器相互接続（ＰＣＩ）バスなどを含むことができる。

１つ以上の集積回路（例えば、従来のマイクロプロセッサまたはマイクロコントローラ）として実装され得る処理ユニット１３０４は、コンピュータシステム１３００の動作を制御する。処理ユニット１３０４は、１つ以上のプロセッサを含んでもよい。これらのプロセッサは、シングルコアまたはマルチコアプロセッサを含んでもよい。いくつかの実施形態において、処理ユニット１３０４は、各処理ユニットに含まれるシングルコアまたはマルチコアプロセッサを有する１つ以上の独立した処理ユニット１３３２および／または１３３４として実装され得る。他の実施形態において、処理ユニット１３０４は、２つのデュアルコアプロセッサを単一のチップに統合することによって形成されたクワッドコア（quad-core）処理ユニットとして実装され得る。

様々な実施形態において、処理ユニット１３０４は、プログラムコードに応答して様々なプログラムを実行することができ、同時に実行する複数のプログラムまたはプロセスを維持することができる。任意の時点で、実行されるプログラムコードの一部または全部は、プロセッサ１３０４および／または記憶サブシステム１３１８に常駐することができる。プロセッサ１３０４は、適切なプログラミングを通して、上述した様々な機能性を提供することができる。コンピュータシステム１３００は、デジタル信号プロセッサ（ＤＳＰ）、専用プロセッサおよび／または同種のものを含むことができる処理加速ユニット１３０６をさらに含んでもよい。

Ｉ／Ｏサブシステム１３０８は、ユーザインターフェイス入力装置と、ユーザインターフェイス出力装置とを含むことができる。ユーザインターフェイス入力装置は、キーボード、マウスまたはトラックボールなどのポインティング装置、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声命令認識システムを備える音声入力装置、マイクロフォン、および他の種類の入力装置を含んでもよい。また、ユーザインターフェイス入力装置は、例えば、Microsoft Kinect（登録商標）モーションセンサのようなモーション検知および／またはジェスチャ認識装置を含んでもよい。Microsoft Kinect（登録商標）モーションセンサは、ジェスチャおよび音声命令を利用する自然ユーザインターフェイス（NUI）を介して、Microsoft Xbox（登録商標）３６０ゲームコントローラなどの入力装置を制御することができ、それと対話することができる。また、ユーザインターフェイス入力装置は、Google Glass（登録商標）瞬き検出器のような眼球ジェスチャ認識装置を含むことができる。Google Glass（登録商標）瞬き検出器は、ユーザの眼球活動（例えば、写真を撮るときおよび／またはメニューを選択するときの「瞬き」）を検出し、眼球活動を入力装置（例えば、Google Glass（登録商標））に入力する入力に変換する。さらに、ユーザインターフェイス入力装置は、音声命令を介してユーザと音声認識システム（例えば、Siri（登録商標）ナビゲータ）との対話を可能にする音声認識検出装置を含んでもよい。

また、ユーザインターフェイス入力装置は、三次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッド、グラフィックタブレット、スピーカなどのオーディオ／ビジュアル装置、デジタルカメラ、デジタルビデオカメラ、ポータブルメディアプレーヤ、ウェブカメラ、イメージスキャナ、指紋スキャナ、バーコードリーダ、３Ｄスキャナ、３Ｄプリンタ、レーザ距離計、および視線追跡装置を含むがこれらに限定されない。さらに、ユーザインターフェイス入力装置は、例えば、コンピュータ断層撮影装置、磁気共鳴像装置、超音波放射断層撮影装置、および医療用超音波装置などのような医用画像入力装置を含んでもよい。また、ユーザインターフェイス入力装置は、例えば、ＭＩＤＩキーボードおよび電子楽器などの音声入力装置を含んでもよい。

ユーザインターフェイス出力装置は、ディスプレイサブシステム、インジケータライト、またはオーディオ出力装置などの非視覚ディスプレイを含んでもよい。ディスプレイサブシステムは、例えば、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを使用するフラットパネル装置、投射装置またはタッチスクリーンであってもよい。一般的に、「出力装置」という用語を使用する場合、コンピュータシステム１３００から情報をユーザまたは他のコンピュータに出力するための全ての可能な種類の装置および機構を含むことを意図している。例えば、ユーザインターフェイス出力装置は、文字、画像およびオーディオ／ビデオ情報を視覚的に伝達するさまざまな表示装置、例えば、モニタ、プリンタ、スピーカ、ヘッドフォン、カーナビゲーションシステム、プロッタ、音声出力装置、およびモデムを含むがこれらに限定されない。

コンピュータシステム１３００は、記憶サブシステム１３１８を含むことができる。記憶サブシステム１３１８は、ソフトウェア要素を備え、図示では、これらのソフトウェア要素は、システムメモリ１３１０内に配置されている。システムメモリ１３１０は、処理ユニット１３０４にロード可能かつ実行可能なプログラム命令、およびこれらのプログラムの実行により生成されたデータを記憶することができる。

コンピュータシステム１３００の構成およびタイプに応じて、システムメモリ１３１０は、揮発性メモリ（例えば、ランダムアクセスメモリ（random access memory：ＲＡＭ））であってもよく、および／または、不揮発性メモリ（例えば、読取り専用メモリ（read-only memory：ＲＯＭ）、フラッシュメモリ）であってもよい。一般的に、ＲＡＭは、処理ユニット１３０４がすぐにアクセス可能なデータおよび／またはプログラムモジュール、および／または、処理ユニット１３０４によって現在操作および実行されているデータおよび／またはプログラムモジュールを収容する。いくつかの実現例では、システムメモリ１３１０は、スタティックランダムアクセスメモリ（static random access memory：ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（dynamic random access memory：ＤＲＡＭ）などの複数の異なるタイプのメモリを含み得る。いくつかの実現例では、始動中などにコンピュータシステム１３００内の要素間で情報を転送することを助ける基本ルーチンを含む基本入力／出力システム（basic input/output system：ＢＩＯＳ）が、一般的にＲＯＭに格納され得る。一例としておよび非限定的に、システムメモリ１３１０は、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（relational database management system：ＲＤＢＭＳ）などを含み得るアプリケーションプログラム１３１２、プログラムデータ１３１４およびオペレーティングシステム１３１６も示す。一例として、オペレーティングシステム１３１６は、Microsoft Windows（登録商標）、Apple Macintosh（登録商標）および／もしくはLinux（登録商標）オペレーティングシステムのさまざまなバージョン、さまざまな市販のUNIX（登録商標）もしくはUNIXライクオペレーティングシステム（さまざまなGNU/Linuxオペレーティングシステム、Google Chrome（登録商標）ＯＳなどを含むが、これらに限定されるものではない）、および／または、ｉＯＳ、Windows（登録商標）フォン、アンドロイド（登録商標）ＯＳ、ブラックベリー（登録商標）１３ ＯＳおよびPalm（登録商標）ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムを含み得る。

また、記憶サブシステム１３１８は、いくつかの実施例の機能を提供する基本的なプログラミングおよびデータ構造を格納するための有形のコンピュータ可読記憶媒体を提供することができる。プロセッサによって実行されたときに上記の機能を提供するソフトウェア（プログラム、コードモジュール、命令）は、記憶サブシステム１３１８に記憶され得る。これらのソフトウェアモジュールまたは命令は、処理ユニット１３０４によって実行され得る。また、記憶サブシステム１３１８は、本開示に従って使用されるデータを記憶するためのリポジトリを提供することができる。

また、記憶サブシステム１３００は、コンピュータ可読記憶媒体１３２２にさらに接続可能なコンピュータ可読記憶媒体リーダ１３２０を含むことができる。コンピュータ可読記憶媒体１３２２は、システムメモリ１３１０と共に、または必要に応じてシステムメモリ１３１０と組み合わせて、コンピュータ可読情報を一時的におよび／または永久に収容、格納、送信および検索するための記憶媒体に加えて、リモート記憶装置、ローカル記憶装置、固定的な記憶装置および／または取外し可能な記憶装置を包括的に表すことができる。

また、コードまたはコードの一部を含むコンピュータ可読記憶媒体１３２２は、当該技術分野において公知のまたは使用される任意の適切な媒体を含んでもよい。当該媒体は、情報の格納および／または送信のための任意の方法または技術において実現される揮発性および不揮発性の、取外し可能および取外し不可能な媒体などであるが、これらに限定されるものではない記憶媒体および通信媒体を含む。これは、ＲＡＭ、ＲＯＭ、電子的消去・プログラム可能ＲＯＭ（electronically erasable programmable ROM：ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（digital versatile disk：ＤＶＤ）、または他の光学式記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または他の有形のコンピュータ可読媒体などの有形のコンピュータ可読記憶媒体を含むことができる。また、これは、データ信号、データ送信などの無形のコンピュータ可読媒体、または、所望の情報を送信するために使用可能であり且つコンピュータシステム１３００によってアクセス可能なその他の媒体を含むことができる。

一例として、コンピュータ可読記憶媒体１３２２は、取外し不可能な不揮発性磁気媒体から読取るまたは当該媒体に書込むハードディスクドライブ、取外し可能な不揮発性磁気ディスクから読取るまたは当該ディスクに書込む磁気ディスクドライブ、ならびに、ＣＤ ＲＯＭ、ＤＶＤおよびブルーレイ（登録商標）ディスクまたは他の光学式媒体などの取外し可能な不揮発性光学ディスクから読取るまたは当該ディスクに書込む光学式ディスクドライブを含んでもよい。コンピュータ可読記憶媒体１３２２は、ジップ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（universal serial bus：ＵＳＢ）フラッシュドライブ、セキュアデジタル（secure digital：ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含み得るが、これらに限定されるものではない。また、コンピュータ可読記憶媒体１３２２は、フラッシュメモリベースのＳＳＤ、企業向けフラッシュドライブ、ソリッドステートＲＯＭなどの不揮発性メモリに基づくソリッドステートドライブ（solid-state drive：ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭなどの揮発性メモリに基づくＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（magnetoresistive RAM：ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭとフラッシュメモリベースのＳＳＤとの組み合わせを使用するハイブリッドＳＳＤを含んでもよい。ディスクドライブおよびそれらの関連のコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュールおよび他のデータの不揮発性記憶装置をコンピュータシステム１３００に提供することができる。

通信サブシステム１３２４は、他のコンピュータシステムおよびネットワークとのインターフェイスを提供する。通信サブシステム１３２４は、他のシステムからデータを受信し、コンピュータシステム１３００から他のシステムにデータを送信するためのインターフェイスの役割を果たす。例えば、通信サブシステム１３２４は、コンピュータシステム１３００がインターネットを介して１つ以上の装置に接続することを可能にし得る。いくつかの実施例では、通信サブシステム１３２４は、（例えば３Ｇ、４ＧまたはＥＤＧＥ（enhanced data rates for global evolution）などの携帯電話技術、高度データネットワーク技術を用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（radio frequency：ＲＦ）トランシーバ構成要素、ＷｉＦｉ（ＩＥＥＥ８０２．１１ファミリ標準または他のモバイル通信技術またはそれらの任意の組み合わせ）、全地球測位システム（global positioning system：ＧＰＳ）レシーバ構成要素、および／または、他の構成要素を含んでもよい。いくつかの実施例では、通信サブシステム１３２４は、無線インターフェイスに加えて、または無線インターフェイスの代わりに、有線ネットワーク接続（例えば、イーサネット（登録商標））を提供することができる。

また、いくつかの実施例において、通信サブシステム１３２４は、コンピュータシステム１３００を使用し得る１人以上のユーザを代表して、構造化されたおよび／または構造化されていないデータフィード１３２６、イベントストリーム１３２８、イベント更新１３３０などの形態で入力通信を受信することができる。

一例として、通信サブシステム１３２４は、ツイッター（登録商標）フィード、フェースブック（登録商標）更新、リッチ・サイト・サマリ（Rich Site Summary：ＲＳＳ）フィードなどのウェブフィードなどのデータフィード１３２６をリアルタイムでソーシャルネットワークおよび／または他の通信サービスのユーザから受信し、および／または、１つ以上の第三者情報源からリアルタイム更新を受信するように構成され得る。

また、通信サブシステム１３２４は、連続的なデータストリームの形態でデータを受信するように構成され得て、当該データは、連続的である場合もあれば本質的に明確な端部を持たない状態で境界がない場合もあるリアルタイムイベントのイベントストリーム１３２８および／またはイベント更新１３３０を含んでもよい。連続的なデータを生成するアプリケーションの例としては、例えばセンサデータアプリケーション、金融ティッカ、ネットワーク性能測定ツール（例えばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通モニタリングなどを含んでもよい。

また、通信サブシステム１３２４は、構造化されたおよび／または構造化されていないデータフィード１３２６、イベントストリーム１３２８、イベント更新１３３０などを、コンピュータシステム１３００に結合された１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するように構成され得る。

コンピュータシステム１３００は、手持ち式携帯機器（例えば、iPhone（登録商標）携帯電話、iPad（登録商標）計算タブレット、ＰＤＡ）、ウェアラブル装置（例えば、Google Glass（登録商標）ヘッドマウントディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラックまたはその他のデータ処理システムを含む様々な種類のうちの１つであってもよい。

コンピュータおよびネットワークが絶え間なく進化し続けるため、図示されたコンピュータシステム１３００の説明は、特定の例として意図されているにすぎない。図示されたシステムよりも多くのまたは少ない数の構成要素を有する多くの他の構成も可能である。例えば、ハードウェア、ファームウェア、（アプレットを含む）ソフトウェア、または組み合わせにおいて、カスタマイズされたハードウェアも使用されてもよく、および／または、特定の要素が実装され得る。さらに、ネットワーク入力／出力装置などの他の計算装置への接続が利用され得る。本開示において提供される開示および教示に基づいて、当業者は、様々な実施例を実現するための他の手段および／または方法を理解するであろう。

本開示の特定の実施形態を説明してきたが、さまざまな変更、改変、代替構成、および同等物も本開示の範囲内に包含される。本開示の実施形態は、特定のデータ処理環境内で動作するのに限定されず、複数のデータ処理環境内で自由に動作することができる。さらに、一連の特定の処置およびステップを用いて本開示の実施形態を説明してきたが、本開示の範囲が説明された一連の処置およびステップに限定されないことは、当業者にとって明らかであろう。上述した実施形態のさまざまな特徴および態様は、個別にまたは共同で使用することができる。

さらに、ハードウェアおよびソフトウェアの特定の組み合わせを用いて本開示の実施形態を説明してきたが、ハードウェアおよびソフトウェアの他の組み合わせも本開示の範囲内に含まれることを認識すべきである。ハードウェアのみ、ソフトウェアのみ、またはそれらの組み合わせを用いて、本開示の実施形態を実現することができる。本開示に記載されたさまざまなプロセスは、同一のプロセッサまたは任意の組み合わせの異なるプロセッサ上で実行することができる。したがって、特定の処理を実行するように構成要素またはモジュールを構成すると説明する場合、その構成は、例えば、その処理を実行するように電子回路を設計することによって、その処理を実行するようにプログラム可能な電子回路（マイクロプロセッサなど）をプログラムすることによって、またはそれらの組み合わせによって実現することができる。プロセスは、プロセス間の通信を行う従来技術を含むがこれに限定されないさまざまな技術を用いて通信を行うことができる。異なる対のプロセスは、異なる技術を使用することができ、または同一対のプロセスは、異なる時間で異なる技術を使用することができる。

したがって、明細書および図面は、限定的な意味ではなく例示的な意味であるとみなすべきである。しかしながら、特許請求の範囲により定められた幅広い主旨および範囲から逸脱することなく、追加、削減、削除および他の修飾および変更を行ってもよいことは、明らかであろう。したがって、本開示の特定の実施形態を説明したが、これらの実施形態は、限定することを意図していない。さまざまな変更およびその等価物は、添付の特許請求の範囲に含まれる。

本開示を説明する文脈に（特に特許請求の範囲の文脈に）使用された不定冠詞「a」／「an」、定冠詞「the」および同様の参照は、本開示に特に明記しない限りまたは内容上明らかに他の意味を示す場合を除き、単数および複数の両方を含むように解釈すべきである。用語「含む（comprising）」、「有する（having）」、「含む（including）」、および「含有する（containing）」は、特に明記しない限り、非限定的な用語（すなわち、「含むがこれに限定されない」という意味）として解釈されるべきである。「接続されている」という用語は、たとえ何かが介在していても、その一部または全部が内部に含まれている、取り付けられている、または一緒に結合されていると解釈されるべきである。本開示において、値の範囲の列挙は、単にその範囲内に含まれる各個別の値を各々言及する速記方法として意図され、本開示に特に明記しない限り、各個別の値は、本開示に個別に記載されるように、本開示に組み込まれる。本開示に特に明記しない限りまたは内容上明らかに他の意味を示す場合を除き、本開示に記載の全ての方法は、任意の適切な順序で行うことができる。本開示において、任意の例および全ての例または例示的な言語（例えば、「～のような」）の使用は、本開示の実施形態をより明瞭にするよう意図されており、特に明記しない限り、本開示の範囲を限定するものではない。明細書内の用語は、本開示の実施に不可欠な任意の非請求要素を示すものと解釈すべきではない。

「Ｘ、Ｙ、またはＺの少なくとも１つ」というフレーズのような選言的言語は、特に断らない限り、項目、用語などがＸ、ＹもしくはＺ、またはそれらの任意の組み合わせ（例えば、Ｘ、Ｙ、および／またはＺ）のいずれかであってもよいことを示すために一般的に用いられるものとして文脈内で理解されることを意図している。したがって、このような選言的言語は、特定の実施形態が、Ｘの少なくとも１つ、Ｙの少なくとも１つ、またはＺの少なくとも１つが存在することを必要とすることを一般的に意図しておらず、またはそれを暗示していない。

本開示を実施するために知られている最良の形態を含み、本開示の好ましい実施形態が本明細書に記載されている。これらの好ましい実施形態の変形形態は、前述の説明を読めば当業者には明らかになるであろう。当業者は、適宜、このような変形例を採用することができ、本開示は、本明細書に具体的に記載されている以外の方法で実施され得る。したがって、本開示は、適用される法律によって許可され、本明細書に添付された請求項に記載された主題の全ての変形および等価物を含む。さらに、その全ての可能な変形における上記の要素の任意の組み合わせは、本明細書において別段の指示がない限り、本開示に包含される。

本明細書に引用された刊行物、特許出願、および特許を含む全ての参考文献は、各文献が参照により組み込まれることが個別にかつ明確に示され、その全体が本明細書に記載された場合と同じ程度に、参照により組み込まれるものとする。

前述の明細書において、本開示の態様は、その特定の実施形態を参照して説明されているが、当業者は、本開示がそれに限定されないことを認識するであろう。上述の開示の様々な特徴および態様は、個々にまたは共同で使用され得る。さらに、実施形態は、本明細書のより広い精神および範囲から逸脱することなく、本明細書に説明されるものを超える任意の数の環境および用途において利用されることができる。したがって、明細書および図面は、限定的ではなく例示的であると見なされるべきである。

Claims (20)

1. コンピュータで実行される方法であって、
   コンピューティング装置が、コンテナ化環境の一組の接続経路を取得することを含み、前記一組の接続経路は、前記コンテナ化環境内のコンテナ対の間の接続を各々示し、前記方法は、
   前記コンピューティング装置が、前記一組の接続経路のうち、１つの接続経路に少なくとも部分的に基づいて、一対のコンテナの第１のコンテナと第２のコンテナとを特定することと、
   前記コンピューティング装置が、前記接続経路に対応するネットワークポリシーを決定することとを含み、前記ネットワークポリシーは、前記第１のコンテナと前記第２のコンテナとの間の特定の接続の予想結果を示し、前記方法は、
   前記コンピューティング装置が、前記第１のコンテナから前記第２のコンテナへの接続を初期化することと、
   前記コンピューティング装置が、前記接続の結果を判断することと、
   前記結果が前記接続経路に対応する前記ネットワークポリシーによって示された前記予想結果とは異なるという判断に少なくとも部分的に基づいて、前記結果をユーザ装置に提示することとを含む、コンピュータで実行される方法。
2. 前記結果は、前記接続が確立されたことまたは前記接続の確立が失敗しことを示す、請求項１に記載のコンピュータで実行される方法。
3. 前記方法は、前記一組の接続経路のうち、第１サブセットの接続経路中の各接続経路に各々対応する１つ以上のネットワークポリシーに少なくとも部分的に基づいて、前記第１サブセットの接続経路を正の経路として特定することを含み、特定の接続経路を正の経路として特定することは、対応するネットワークポリシーに少なくとも部分的に基づいて、前記接続経路の２つのコンテナ間の接続が許可されることを決定することを含み、
   前記方法は、前記一組の接続経路のうち、第２サブセットの接続経路を生成することをさらに含み、前記第２サブセットの接続経路は、負の経路に対応し、前記第２サブセットの接続経路は、前記第１サブセットの接続経路の特定に少なくとも部分的に基づいて生成される、請求項１に記載のコンピュータで実行される方法。
4. 前記一組の接続経路を取得することは、前記一組の接続経路のうちの少なくとも１つの接続経路のために、
   実行時に、前記コンテナ化環境の２つのコンテナ間のネットワークトラフィックを監視することと、
   前記監視に少なくとも部分的に基づいて、対応する接続経路を生成することとを含む、請求項１に記載のコンピュータで実行される方法。
5. 前記一組の接続経路を取得することは、前記一組の接続経路のうちの少なくとも１つの接続経路のために、特定のコンテナ対の間の特定の接続が許可されているかまたは許可されていないかを示す所定の接続経路を取得することをさらに含む、請求項１に記載のコンピュータで実行される方法。
6. 前記第１のコンテナが第１のラベルに関連付けられ、前記第２のコンテナが第２のラベルに関連付けられているという判断に少なくとも部分的に基づいて、前記第１のコンテナと前記第２のコンテナとを特定することをさらに含む、請求項１に記載のコンピュータで実行される方法。
7. 前記第１のコンテナは、前記第１のラベルに関連付けられた複数のコンテナのうちの１つであり、
   前記方法は、
   前記複数のコンテナのうちの少なくとも１つの他のコンテナと前記第２のコンテナとの間の追加の接続を開始することと、
   前記コンピューティング装置が、前記追加の接続の追加の結果を判断することと、
   前記追加の結果が、前記接続経路に対応する前記ネットワークポリシーによって示された前記予想結果とは異なるという判断に少なくとも部分的に基づいて、前記追加の結果を提示することとをさらに含む、請求項６に記載のコンピュータで実行される方法。
8. コンピューティング装置であって、
   プロセッサと、
   命令を記憶するメモリとを備え、前記命令は、前記プロセッサによって実行されると、前記コンピューティング装置に、
   コンテナ化環境の一組の接続経路を取得させ、前記一組の接続経路は、前記コンテナ化環境内のコンテナ対の間の接続を各々示し、前記命令は前記コンピューティング装置に、
   前記一組の接続経路のうち、１つの接続経路に少なくとも部分的に基づいて、一対のコンテナの第１のコンテナと第２のコンテナとを特定させ、
   前記接続経路に対応するネットワークポリシーを決定させ、前記ネットワークポリシーは、前記第１のコンテナと前記第２のコンテナとの間の特定の接続の予想結果を示し、前記命令は前記コンピューティング装置に、
   前記第１のコンテナから前記第２のコンテナへの接続を初期化させ、
   前記接続の結果を判断させ、
   前記結果が前記接続経路に対応する前記ネットワークポリシーによって示された前記予想結果とは異なるという判断に少なくとも部分的に基づいて、前記結果をユーザ装置に提示させる、コンピューティング装置。
9. 前記結果は、前記接続が確立されたこと、または、前記接続の確立が失敗したことを示す、請求項８に記載のコンピューティング装置。
10. 前記命令は、前記コンピューティング装置に、
    前記一組の接続経路のうち、第１サブセットの接続経路中の各接続経路に各々対応する１つ以上のネットワークポリシーに少なくとも部分的に基づいて、前記第１サブセットの接続経路を正の経路として特定させ、特定の接続経路を正の経路として特定することは、対応するネットワークポリシーに少なくとも部分的に基づいて、前記接続経路の２つのコンテナ間の接続が許可されることを決定することを含み、前記命令は前記コンピューティング装置に、
    前記一組の接続経路のうち、第２サブセットの接続経路を生成させ、前記第２サブセットの接続経路は、負の経路に対応し、前記第２サブセットの接続経路は、前記第１サブセットの接続経路の特定に少なくとも部分的に基づいて生成される、請求項８に記載のコンピューティング装置。
11. 前記一組の接続経路を取得するための前記命令を実行することは、前記コンピューティング装置に、前記一組の接続経路のうちの少なくとも１つの接続経路について、
    実行時に、前記コンテナ化環境の２つのコンテナ間のネットワークトラフィックを監視させ、
    前記監視に少なくとも部分的に基づいて、対応する接続経路を生成させる、請求項８に記載のコンピューティング装置。
12. 前記一組の接続経路を取得するための前記命令を実行することは、前記コンピューティング装置に、前記一組の接続経路のうちの少なくとも１つの接続経路について、特定のコンテナ対の間の特定の接続が許可されているかまたは許可されていないかを示す所定の接続経路をさらに取得させる、請求項８に記載のコンピューティング装置。
13. 前記命令を実行することは、前記コンピューティング装置に、前記第１のコンテナが第１のラベルに関連付けられ、かつ、前記第２のコンテナが第２のラベルに関連付けられているという判断に少なくとも部分的に基づいて、前記第１のコンテナと前記第２のコンテナとを特定させる、請求項８に記載のコンピューティング装置。
14. 前記第１のコンテナは、前記第１のラベルに関連付けられた複数のコンテナのうちの１つであり、
    前記命令を実行することは、前記コンピューティング装置に、
    前記複数のコンテナのうちの少なくとも１つの他のコンテナと前記第２のコンテナとの間の追加の接続を開始させ、
    前記追加の接続の追加の結果を確認させ、
    前記追加の結果が、前記接続経路に対応する前記ネットワークポリシーによって示された前記予想結果とは異なると確認したことに少なくとも部分的に基づいて、前記追加の結果を提示させる、請求項１３に記載のコンピューティング装置。
15. コンピュータ実行可能な命令を記憶する非一時的なコンピュータ可読媒体であって、前記命令は、コンピューティング装置の１つ以上のプロセッサによって実行されると、前記コンピューティング装置に、
    コンテナ化環境の一組の接続経路を取得させ、前記一組の接続経路は、前記コンテナ化環境内のコンテナ対の間の接続を各々示し、前記命令は前記コンピューティング装置に、
    前記一組の接続経路のうち、１つの接続経路に少なくとも部分的に基づいて、一対のコンテナの第１のコンテナと第２のコンテナとを特定させ、
    前記接続経路に対応するネットワークポリシーを決定させ、前記ネットワークポリシーは、前記第１のコンテナと前記第２のコンテナとの間の特定の接続の予想結果を示し、前記命令は前記コンピューティング装置に、
    前記第１のコンテナから前記第２のコンテナへの接続を初期化させ、
    前記接続の結果を確認させ、
    前記結果が前記接続経路に対応する前記ネットワークポリシーによって示された前記予想結果とは異なると確認したことに少なくとも部分的に基づいて、前記結果をユーザ装置に提示させる、非一時的なコンピュータ可読媒体。
16. 前記コンピュータ実行可能な命令を実行することは、前記コンピューティング装置に、
    前記一組の接続経路のうち、第１サブセットの接続経路中の各接続経路に各々対応する１つ以上のネットワークポリシーに少なくとも部分的に基づいて、前記第１サブセットの接続経路を正の経路として特定させ、特定の接続経路を正の経路として特定することは、対応するネットワークポリシーに少なくとも部分的に基づいて、前記接続経路の２つのコンテナ間の接続が許可されることを決定することを含み、
    前記命令を実行することは前記コンピューティング装置に、前記一組の接続経路のうち、第２サブセットの接続経路を生成させ、前記第２サブセットの接続経路は、負の経路に対応し、前記第２サブセットの接続経路は、前記第１サブセットの接続経路の特定に少なくとも部分的に基づいて生成される、請求項１５に記載の非一時的なコンピュータ可読媒体。
17. 前記一組の接続経路を取得するための前記コンピュータ実行可能な命令を実行することは、前記コンピューティング装置に、 前記一組の接続経路のうちの少なくとも１つの接続経路について、
    実行時に、前記コンテナ化環境の２つのコンテナ間のネットワークトラフィックを監視させ、
    前記監視に少なくとも部分的に基づいて、対応する接続経路を生成させる、請求項１５に記載のコンピュータ可読媒体。
18. 前記一組の接続経路を取得するための前記コンピュータ実行可能な命令を実行することは、前記コンピューティング装置に、前記一組の接続経路のうちの少なくとも１つの接続経路について、特定のコンテナ対の間の特定の接続が許可されているかまたは許可されていないかを示す所定の接続経路をさらに取得させる、請求項１５に記載のコンピュータ可読媒体。
19. 前記コンピュータ実行可能な命令を実行することは、前記コンピューティング装置に、前記第１のコンテナが第１のラベルに関連付けられ、前記第２のコンテナが第２のラベルに関連付けられているという判断に少なくとも部分的に基づいて、前記第１のコンテナと前記第２のコンテナとを特定させる、請求項１５に記載のコンピュータ可読媒体。
20. 前記第１のコンテナは、前記第１のラベルに関連付けられた複数のコンテナのうちの１つであり、
    前記コンピュータ実行可能な命令を実行することは、前記コンピューティング装置に、
    前記複数のコンテナのうちの少なくとも１つの他のコンテナと前記第２のコンテナとの間の追加の接続を開始させ、
    前記追加の接続の追加の結果を確認させ、
    前記追加の結果が、前記接続経路に対応する前記ネットワークポリシーによって示された前記予想結果とは異なると確認したことに少なくとも部分的に基づいて、前記追加の結果を提示することとを含む、請求項１９に記載のコンピュータ可読媒体。

Images