APIエンドポイント構成に関する推奨事項¶
内部API通信¶
OpenStackはパブリックとプライベート両方のAPIエンドポイントを提供します。デフォルトではOpenStackコンポーネントはパブリックとして定義されたエンドポイントを使用します。推奨はこれらのコンポーネントを適切なセキュリティドメイン内で使用するよう構成することです。
サービスはOpenStackサービスカタログに基づいて、それぞれのAPIエンドポイントを選択します。これらのサービスは、リストされた外部もしくは内部APIエンドポイントの値に従わないことがあります。これは内部管理トラフィックが外部APIエンドポイントへルーティングされる可能性があります。
Identity サービスカタログの内部 URL の設定¶
Identity のカタログは内部 URL を認識できるようにすべきです。この機能はデフォルトで利用されませんが、設定により有効化できます。さらに、この動作が標準になると、予期される変更と前方互換性があるべきです。
エンドポイント用の内部URL登録
$ openstack endpoint create identity \
--region RegionOne internal \
https://MANAGEMENT_IP:5000/v3
MANAGEMENT_IP をコントローラーノードの管理 IP アドレスに置き換えます。
内部URL用のアプリケーション構成¶
いくつかのサービスは特定のAPIエンドポイントの仕様を強制することができます。従って、それぞれのOpenStackサービスと他サービスとの通信は明示的に適切な内部APIエンドポイントへアクセスするよう構成する必要があります。
各プロジェクトで一貫性の無いAPIエンドポイントを提供しています。将来のリリースにおいてこれらの不一致を Identity サービスカタログを使った一貫性で解決しようとしています。
構成例#1: nova¶
cinder_catalog_info='volume:cinder:internalURL'
glance_protocol='https'
neutron_url='https://neutron-host:9696'
neutron_admin_auth_url='https://neutron-host:9696'
s3_host='s3-host'
s3_use_ssl=True
構成例#2: cinder¶
glance_host = 'https://glance-server'
Paste と ミドルウェア¶
OpenStack内のほぼ全てのAPIエンドポイントと他のHTTPサービスはPythonのPaste Deployライブラリを利用しています。このライブラリにより、アプリケーションの設定によってはリクエストフィルターのパイプラインが操作が可能だと理解することがセキュリティの観点から重要になります。このパイプライン連鎖の中のそれぞれの要素は*ミドルウェア*として呼ばれています。パイプラインの中でフィルター順序を変更したり、ミドルウェアを追加すると予期しないセキュリティ上の影響が発生する可能性があります。
実装者がOpenStackの基本機能を拡張するためにミドルウェアを追加することは一般的です。私たちは非標準のソフトウェアコンポーネントをHTTPリクエストパイプラインへ追加することによって生じる潜在的なセキュリティについて慎重に検討する事を推奨しています。
Paste Deploy の詳細は Python Paste Deployment ドキュメント を参照してください。
APIエンドポイントのプロセス分離とポリシー¶
特にパブリックなセキュリティドメインに属するAPIエンドポイントプロセスは分離すべきです。ディプロイメント可能であれば、APIエンドポイントは分離のために増設されたホスト上に構成すべきです。
名前空間¶
多くのOSは現在コンパートメント化をサポートしています。Linuxではプロセスに独立したドメインを割り当てる名前空間をサポートしています。システムのコンパートメント化についてはこのマニュアルの別の部分で詳しく説明されています。
ネットワークポリシー¶
APIエンドポイントは一般的に複数のセキュリティドメインをまたがるため、APIプロセスのコンパートメント化には特別の注意を払うべきです。この話題の詳細は セキュリティドメインのブリッジ を参照してください。
慎重なデザインを行えば、ネットワークACLとIDS技術をネットワークサービス間の特定の通信に摘要する事が出来ます。重要なドメインをまたがるサービスとして、OpenStackのメッセージキューにこの手の明示的な強制は適しています。
ポリシーを強制するために、サービス、ホストベースのファイアウォール(例えばiptables)、ローカルポリシー(SELinuxやAppArmor)、オプションとしてグローバルネットワークポリシーを設定できます。
強制アクセス制御¶
APIエンドポイントのプロセスはマシン上の他のプロセスと分離すべきです。これらのプロセスの構成は任意のアクセス制御方法ではなく、強制アクセス制御によって制限されるべきです。これらのアクセス制御の目的はAPIエンドポイントのセキュリティ侵害の抑制と、特権侵害の防止です。強制アクセス制御を利用する事で、禁止されたリソースへのアクセスが厳しく制限され、早期の警告が得られるようになります。
API エンドポイントのレートリミット¶
Rate Limiting is a means to control the frequency of events received by a network based application. When robust rate limiting is not present, it can result in an application being susceptible to various denial of service attacks. This is especially true for APIs, which by their nature are designed to accept a high frequency of similar request types and operations.
Within OpenStack, it is recommended that all endpoints, especially public, are provided with an extra layer of protection, by means of either a rate-limiting proxy or web application firewall.
It is key that the operator carefully plans and considers the individual performance needs of users and services within their OpenStack cloud when configuring and implementing any rate limiting functionality.
Common solutions for providing rate-limiting are Nginx, HAProxy, OpenRepose, or Apache Modules such as mod_ratelimit, mod_qos, or mod_security.
