6.8. Networking

OpenStack Networking は、複数のノードに複数のプロセスをデプロイするスタンドアロンのサービスです。これらのプロセスは、相互、その他の OpenStack サービスと対話します。OpenStack Networking サービスの主なプロセスは、neutron-server で、OpenStack Networking API を公開し、追加の処理のためにプロジェクト要求をプラグインスイートに渡す Python デーモンです。

OpenStack Networking のコンポーネントは以下のとおりです。

以下の図は、OpenStack Networking コンポーネントのアーキテクチャーおよびネットワークフローの図を示しています。

このアプローチは、分散仮想ルーター (DVR) および Layer-3 高可用性 (L3HA) が使用された場合に大幅に変更されることに注意してください。L3HA はルーター間で VRRP を実装するため、これらのモードは neutron のセキュリティーランドスケープを変更します。デプロイメントは、ルーターに対する DoS 攻撃を軽減できるように適切にサイズで強化する必要があります。また、VRRP スプーフィングの脅威に対処するために、ルーター間のローカルネットワークトラフィックを機密として扱う必要があります。DVR はネットワークコンポーネント (ルーティングなど) をコンピュートノードに移行する一方で、まだネットワークノードが必要です。したがって、コンピュートノードはパブリックネットワーク間のアクセスを必要とするため、ファイアウォールルールとセキュリティーモデルがこのアプローチをサポートする必要があるため、公開機能が高まり、お客様が追加でセキュリティーを考慮する必要があります。

本項では、コントローラーノード、ネットワークノード、および実行中のインスタンス用のコンピュートノードセットが含まれる標準のアーキテクチャーを説明します。物理サーバーのネットワーク接続を確立するために、通常の neutron デプロイメントは、4 つの異なる物理データセンターネットワークで設定されます。

このトラフィックを別のゾーンに分割することを推奨します。詳細は次のセクションを参照してください。

重大なシステムは互いに分離させて、セキュリティーゾーンという概念を使用することを推奨します。実用的な方法では、VLAN およびファイアウォールルールを使用してネットワークトラフィックを分離します。このキュレートは細かい詳細で行い、neutron に接続する必要のあるサービスのみがこれを実行できるようにする必要があります。

以下の図は、ゾーンが特定のコンポーネントを分離するために作成されていることがわかります。

.

OpenStack Network インフラストラクチャーを設計するための初期アーキテクチャーフェーズでは、適切なセキュリティー制御および監査のメカニズムを特定できるようにするためにも、適切な専門知識で物理ネットワークインフラストラクチャーのデザインをアシストできるようにしておくことが重要です。

OpenStack Networking は、プロジェクト固有の仮想ネットワークをアーキテクトする機能を提供する、仮想ネットワークサービスのレイヤーを追加します。現在、これらの仮想化サービスは、従来のネットワークに対応するネットワークほど成熟していません。このような仮想化サービスの現在の状態を、仮想化および従来のネットワーク境界に実装する必要のあるコントロールを定めるため、それらを採用する前にこれらの仮想化サービスの現在の状態を考慮してください。

OpenStack Networking は、プロジェクト/ネットワークの組み合わせ: VLAN (IEEE 802.1Q タグ付け) または VXLAN または GRE カプセル化を使用する L2 トンネルのトラフィック分離に、2 つの異なるメカニズムを使用できます。OpenStack デプロイメントのスコープおよびスケーリングは、トラフィックの分離または分離に使用する方法を決定します。

VLAN は、特定の VLAN ID (VID) フィールド値を持つ IEEE 802.1Q ヘッダーが含まれる特定の物理ネットワーク上のパケットとして認識されます。同じ物理ネットワークを共有する VLAN ネットワークは、L2 で相互に分離され、IP アドレス空間が重複している可能性もあります。VLAN ネットワークをサポートする各物理ネットワークは、別個の VLAN トランク k として扱われ、異なる領域の VID 値を持ちます。有効な VID の値は 1 から 4094 までです。

VLAN 設定は、OpenStack の設計要件によって異なります。OpenStack Networking が VLAN をより効率的に使用できるようにするには、VLAN 範囲 (各プロジェクトの 1 つ) を割り当てて、各コンピュートノードの物理スイッチポートを VLAN トランクポートに切り替える必要があります。

ネットワークトンネリングは、各プロジェクト/ネットワークの組み合わせを、その組み合わせに属するネットワークトラフィックの特定に使用される一意の “tunnel-id" と組み合わせてカプセル化します。プロジェクトの L2 ネットワーク接続は、物理ローリティーまたは下層のネットワーク設計とは独立しています。IP パケット内にトラフィックをカプセル化することで、そのトラフィックはレイヤー 3 の境界をまたがり、事前設定済みの VLAN および VLAN トランク接続の必要性がなくなります。トンネリングにより、ネットワークデータのトラフィックに難読化のレイヤーが追加され、個別のプロジェクトトラフィックの可視性が、ビューのモニターポイントを模倣します。

OpenStack Networking は現在 GRE および VXLAN カプセル化の両方をサポートしています。L2 分離を提供する技術は、デプロイメントで作成されるプロジェクトネットワークのスコープおよびサイズによって異なります。

Compute は、OpenStack Networking サービスの使用により、プロジェクトのネットワークトラフィックのアクセス制御をサポートします。セキュリティーグループにより、管理者およびプロジェクトがトラフィックの種別を指定することができ、かつ方向 (ingress/egress) が仮想インターフェイスポートを通過できる方向 (ingress/egress) を指定することができます。セキュリティーグループルールは、ステートフル L2-L4 トラフィックフィルターです。

OpenStack Networking ルーターは、複数の L2 ネットワークを接続でき、1 つ以上のプライベート L2 ネットワークを、インターネットにアクセスするためのパブリックネットワークなど、共有外部ネットワークに接続するゲートウェイを提供することもできます。

L3 ルーターは、ルーターを外部ネットワークにリンクするゲートウェイポートで、基本的なネットワークアドレス変換 (SNAT および DNAT) 機能を提供します。このルーター SNAT (ソース NAT) デフォルトですべての egress トラフィックをサポートし、Floating IP をサポートします。Floating IP は、外部ネットワーク上のパブリック IP からルーターに接続された他のサブネットにプライベート IP に静的 1 対 1 のプライベート IP へのマッピングを作成します。Floating IP (DNAT 経由) は、インスタンスに外部インバウンドの接続性を提供し、あるインスタンスから別のインスタンスから移行することができます。

プロジェクトインスタンスのより詳細な接続のために、プロジェクトごとの L3 ルーティングと Floating IP を使用することを検討してください。パブリックネットワークに接続されたインスタンス、または Floating IP を使用して、特別な考慮する必要があります。外部で公開される必要があるサービスのみに対して、セキュリティーグループの使用を慎重に検討することが推奨されます。

デフォルトでは、QoS (Quality of Service) ポリシーおよびルールはクラウド管理者によって管理されます。これにより、プロジェクトが特定の QoS ルールを作成できず、またポートに特定のポリシーをアタッチすることはできません。管理者が通信するアプリケーションなどの一部のユースケースでは、管理者がプロジェクトを信頼し、独自のポリシーをポートに作成および接続できるようにします。そのためには、policy.json ファイルを変更します。

Red Hat OpenStack Platform 12 から、neutron は、受信トラフィックと送信トラフィックの両方で、帯域幅を制限する QoS ルールをサポートしています。この QoS ルールは QosBandwidthLimitRule という名前で、毎秒キロビットで測定される負の整数を 2 つ受け取ります。

QoSBandwidthLimitRule は、neutron Open vSwitch、Linux ブリッジ、および SR-IOV ドライバーに実装されています。ただし、SR-IOV ドライバーでは、max-burst-kbps の値が使用されず、設定されている場合は無視されます。

QoS ルール QosDscpMarkingRule は、IPv4 (RFC 2474) のサービスヘッダーのタイプに Differentiated Service Code Point (DSCP) 値を設定し、仮想マシンから出るすべてのトラフィックで、IPv6 のトラフィッククラスヘッダー (ルールが適用されます) を設定します。これは、ネットワークが輻輳に合致するように、パケットのドロップの優先度を示す、有効な値が 21 の 6 ビットヘッダーです。また、ファイアウォールで使用して、アクセス制御リストに対する有効なトラフィックまたは無効なトラフィックを一致させることもできます。

OpenStack Load-balancing サービス (octavia) は、Red Hat OpenStack Platform director のインストール環境で、Load Balancing-as-a-Service (LBaaS) の実装を提供します。負荷分散機能を実現するために、octavia では複数のプロバイダードライバーを有効にする設定がサポートされます。参照プロバイダードライバー (Amphora プロバイダードライバー) は、オープンソースのスケーラビリティーに優れた高可用性負荷分散プロバイダーです。仮想マシン群 (amphora と総称される) を管理し、オンデマンドで起動することで、負荷分散サービスを提供します。

Load-balancing サービスの詳細は、Using Octavia for Load Balancing-as-a-Service を参照してください。

本項では、OpenStack デプロイメント内のプロジェクトネットワークセキュリティーに適用される、OpenStack Networking の設定に関する適切なプラクティスについて説明します。

OpenStack Networking API サービスが受信クライアント接続用にネットワークソケットをバインドするインターフェイスまたは IP アドレスを制限するには、/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf ファイルで bind_host および bind_por t を指定します。

# Address to bind the API server
bind_host = IP ADDRESS OF SERVER

# Port the bind the API server to
bind_port = 9696

OpenStack Networking サービスのさまざまなコンポーネントは、メッセージングキューまたはデータベース接続のいずれかを使用して、OpenStack Networking の他のコンポーネントと通信します。

OpenStack Networking は、ユーザーがネットワークリソースのセルフサービス設定を提供します。クラウドアーキテクトとオペレーターは、ユーザーが利用可能なネットワークリソースを作成、更新、破棄できる設計のユースケースを評価することが重要です。

OpenStack Networking 内のポリシーエンジンと設定ファイル (policy.json) は、プロジェクトネットワークのメソッドおよびオブジェクトに対するユーザーの詳細な認可を提供する方法を提供します。OpenStack Networking ポリシーの定義は、ネットワークの可用性、ネットワークセキュリティー、および OpenStack セキュリティー全体に影響します。クラウドアーキテクトとオペレーターは、ネットワークリソースの管理に対するユーザーおよびプロジェクトアクセスに対して、ポリシーを慎重に評価する必要があります。

OpenStack が複数の外部アクセスポイントを提供する場合は、複数の仮想 NIC を複数の外部アクセスポイントにアタッチするプロジェクトの機能を制限することが重要です。よりこれらのセキュリティーゾーンがブリッジされ、セキュリティーへの不正アクセスの原因となる可能性があります。Compute が提供するホスト集約関数を使用するか、プロジェクトインスタンスを異なる仮想ネットワーク設定を持つ複数のプロジェクトに分割することで、このリスクを軽減することができます。ホストアグリゲートについての詳細は、link:https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/13/html/configuring_the_compute_service_for_instance_creation/crea ting-and-managing-host-aggregates (ホストアグリゲートの作成と管理) を参照してください。

セキュリティーグループとは、セキュリティーグループルールのコレクションです。セキュリティーグループとそれらのグループにより、管理者およびプロジェクトがトラフィックの種別を指定することができ、かつ方向 (ingress/egress) が仮想インターフェイスポートを通過できる方向 (ingress/egress) を指定することができます。OpenStack Networking で仮想インターフェイスのポートが作成されると、セキュリティーグループが関連付けられます。デプロイメントごとに動作を変更するには、デフォルトのセキュリティーグループにルールを追加できます。

Compute API を使用してセキュリティーグループを変更する場合、更新されたセキュリティーグループはインスタンスのすべての仮想インターフェイスポートに適用されます。これは、neutron にあるように、コンピュートセキュリティーグループ API がポートベースではなくインスタンスベースであるためです。

クォータは、プロジェクトで利用可能なネットワークリソースの数を制限できます。すべてのプロジェクトに対してデフォルトのクォータを適用できます。クォータオプションを確認するには、/var/lib/config-data/puppet-generated /neutron/etc/neutron/neutron.conf を参照してください。

OpenStack Networking は、クォータ拡張 API 経由でプロジェクトごとのクォータ制限もサポートします。プロジェクトごとのクォータを有効にするには、/var/lib/config-data/puppet-generated/neutron/e tc/neutron/neutron.conf で quota_driver オプションを設定する必要があります。以下に例を示します。

quota_driver = neutron.db.quota_db.DbQuotaDriver

OpenStack Networking には、インスタンスの ARP スプーフィングの脅威を緩和するための組み込み機能が含まれています。これは、結果となるリスクに注意を払う場合を除き無効にしないでください。

設定ファイルには、コンポーネントのスムーズに機能するために必要な重要なパラメーターおよび情報が含まれます。非特権ユーザーが故意・過失で変更したり、ファイル自体を変更したり、削除したりすると、重大な可用性の問題が原因で、他のエンドユーザーにサービス拒否が発生します。そのため、このような重要な設定ファイルのユーザー所有権を root に設定し、グループの所有権を neutron に設定する必要があります。

neutron グループはホストにありません。ls -l を使用すると、グループ所有者の GID が表示されます。

sudo ls -l /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
-rw-r-----. 1 root 42435 41748 Dec 11 09:34 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

sudo stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
root UNKNOWN

neuton.conf 設定ファイルのユーザーおよびグループの所有権が、それぞれ root および neutron に設定されていることを確認します。

sudo docker exec -it neutron_api stat -L -c "%U %G" /etc/neutron/neutron.conf
root neutron

neutron.conf 設定ファイルのパーミッションが 640 またはより厳格に設定されていることを確認します。

$ stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf で、[DEFAULT] セクションの auth_strategy の値が、noauth または noauth2 ではなく keystone に設定されていることを確認します。

/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf で、[keystone_authtoken] セクションの auth_uri の値が https: で始まる Identity API エンドポイントに設定されていることを確認します。

/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf で、[DEFAULT] セクションのパラメーター use_ssl が True に設定されていることを確認します。