第1章 Image サービス (glance)

Red Hat OpenStack Platform (RHOSP) でのイメージおよびストレージを管理します。

仮想マシンのイメージとは、ブート可能なオペレーティングシステムがインストールされた仮想ディスクが含まれるファイルです。仮想マシンのイメージは、複数の形式をサポートしています。以下は、RHOSP で利用可能な形式です。

  • RAW: 非構造化のディスクイメージ形式
  • QCOW2: QEMU エミュレーターでサポートされているディスク形式。この形式には、QEMU 1.1 以降が必要な QCOW2v3 (QCOW3 と呼ばれる場合があります) が含まれます。
  • ISO: ディスク上のデータをセクター単位でコピーし、バイナリーファイルに格納した形式
  • AKI: Amazon Kernel Image
  • AMI: Amazon Machine Image
  • ARI: Amazon RAMDisk Image
  • VDI: VirtualBox の仮想マシンモニターおよび QEMU エミュレーターでサポートされているディスク形式
  • VHD: VMware、VirtualBox などの仮想マシンモニターで使用されている一般的なディスク形式
  • PLOOP: OS コンテナーを実行するのに Virtuozzo でサポートおよび使用されているディスク形式
  • OVA: Image サービス (glance) に保存されているのが OVA tar アーカイブファイルであることを示します。
  • DOCKER: Image サービス (glance) に保存されているのがコンテナーファイルシステムの Docker tar アーカイブであることを示します。

通常、仮想マシンイメージの形式に ISO は考慮されませんが、ISO にはオペレーティングシステムがインストール済みのブート可能なファイルシステムが含まれているので、他の形式の仮想マシンイメージファイルと同様に使用されます。

公式の Red Hat Enterprise Linux クラウドイメージをダウンロードするには、お使いのアカウントに有効な Red Hat Enterprise Linux サブスクリプションが必要です。

カスタマーポータルにログインしていない場合には、プロンプトが表示されるので Red Hat アカウントの認証情報を入力する必要があります。

1.1. Image サービスについての理解

Red Hat OpenStack Platform (RHOSP) Image サービス (glance) の機能

1.1.1. サポート対象の Image サービスバックエンド

以下に示す Image サービス (glance) バックエンドのシナリオがサポートされます。

  • Ceph を使用する場合には、RBD がデフォルトのバックエンドです。詳しい情報は、Advanced Overcloud CustomizationConfiguring Ceph Storage を参照してください。
  • RBD マルチストア。詳細は、「ストレージエッジアーキテクチャーの要件」 を参照してください。
  • Object Storage (swift)。詳しい情報は、Advanced Overcloud CustomizationUsing an External Object Storage Cluster を参照してください。

    Image サービスは、Object Storage のタイプとバックエンドをデフォルトとして使用します。

  • Block Storage (cinder)。詳しい情報は、Advanced Overcloud CustomizationConfiguring cinder back end for the Image service を参照してください。
  • NFS。詳しい情報は、Advanced Overcloud CustomizationConfiguring NFS Storage を参照してください。

    Important

    NFS はサポート対象の Image サービス用デプロイメントオプションですが、より堅牢なオプションを利用することができます。

    NFS は Image サービスネイティブではありません。NFS 共有を Image サービスにマウントした場合、Image サービスは操作を管理しません。Image サービスはファイルシステムにデータを書き込みますが、バックエンドが NFS 共有であることを認識しません。

    この種別のデプロイメントでは、ファイル共有に異常が発生しても、Image サービスは要求をリトライすることができません。つまり、バックエンドで障害が発生した場合、ストアは読み取り専用モードに移行するか、ローカルファイルシステムにデータの書き込みを続けます。この場合、データを損失する可能性があります。この状況から回復するには、ファイル共有がマウントされ同期されている状態にし、続いて Image サービスを再起動する必要があります。このような理由により、Red Hat では、Image サービスのバックエンドとして NFS を推奨しません。

    ただし、Image サービスのバックエンドに NFS を使用することを選択した場合には、以下のベストプラクティスがリスクを軽減するのに役立ちます。

    • 信頼性の高い実稼働環境グレードの NFS バックエンドを使用する。
    • コントローラーノードと NFS バックエンドの間に強力で信頼性の高い接続があることを確認してください。レイヤー 2 (L2) ネットワーク接続が推奨されます。
    • マウントされたファイル共有のモニタリングおよびアラート機能を追加する。
    • 基になるファイルシステムのアクセス許可を設定します。書き込み権限は、ストアとして使用する共有ファイルシステムに設定する必要があります。
    • glance-api プロセスが実行されるユーザーおよびグループが、ローカルファイルシステムのマウントポイントに対する書き込み権限を持たないようにしてください。これにより、プロセスはマウントの異常を検出して、書き込みを試みる際にストアを読み取り専用モードに移行することができます。

1.1.2. イメージの署名および検証

イメージの署名および検証により、デプロイ担当者がイメージに署名して、その署名と公開鍵の証明書をイメージの属性として保存できるようにすることで、イメージの整合性と信頼性を保護します。

この機能を利用すると、次のタスクを実行できます。

  • 秘密鍵を使用してイメージに署名し、そのイメージ、署名、公開鍵の証明書 (検証メタデータ) への参照をアップロードすることができます。Image サービスは、署名が有効かどうかを検証します。
  • Compute サービスでイメージを作成し、Compute サービスがそのイメージに署名し、イメージや検証メタデータをアップロードすることができます。Image サービスは、この場合も、署名が有効であるかどうかを検証します。
  • Compute サービスで署名済みのイメージを要求することができます。Image サービスは、イメージと検証メタデータを提供します。これにより、Compute サービスはイメージを起動する前に検証することができます。

イメージの署名および検証に関する詳しい情報は、Manage Secrets with OpenStack Key ManagerValidating Image Service (glance) images を参照してください。

1.1.3. イメージの変換

イメージの変換は、イメージのインポート中にタスク API を呼び出して、イメージを変換します。

インポートのワークフローの一環として、プラグインがイメージの変換機能を提供します。このプラグインは、デプロイ担当者の設定に基づいて、アクティブ化/非アクティブ化することができます。そのため、デプロイ担当者は、デプロイメントに希望のイメージ形式を指定する必要があります。

内部では、Image サービスが特定の形式でイメージのビットを受信します。これらのビットは、一時的な場所に保管されます。次にプラグインが起動されて、イメージを対象のフォーマットに変換し、最終的な保管場所に移動します。タスクが終了すると、一時的な場所は削除されます。このため、Image サービスでは最初にアップロードした形式は保持されません。

イメージ変換の詳細については、「イメージ変換の有効化」 を参照してください。

注記

イメージの変換は、イメージをインポートする時にだけトリガーされます。イメージのアップロード時には実行されません。以下に例を示します。

$ glance image-create-via-import \
    --disk-format qcow2 \
    --container-format bare \
    --name NAME \
    --visibility public \
    --import-method web-download \
    --uri http://server/image.qcow2

1.1.4. 相互運用可能なイメージのインポート

相互運用可能なイメージのインポートワークフローにより、以下の 2 とおりの方法でイメージをインポートすることができます。

  • web-download (デフォルト) メソッドを使用して、URI からイメージをインポートする。
  • glance-direct メソッドを使用して、ローカルファイルシステムからイメージをインポートする。

1.1.5. Image サービスのキャッシュ機能を使用したスケーラビリティーの向上

glance-api キャッシュメカニズムを使用して、Image サービス (glance) API サーバーにイメージのコピーを保存し、それらを自動的に取得してスケーラビリティーを向上させます。Image サービスのキャッシュ機能を使用することで、複数のホスト上で glance-api を実行することができます。つまり、同じイメージをバックエンドストレージから何度も取得する必要はありません。Image サービスのキャッシュ機能は、Image サービスの動作には一切影響を与えません。

Red Hat OpenStack Platform director (tripleo) heat テンプレートを使用して、Image サービスのキャッシュ機能を設定します。

手順

  1. 環境ファイルの GlanceCacheEnabled パラメーターの値を true に設定します。これにより、glance-api.conf Heat テンプレートの flavor の値が自動的に keystone+cachemanagement に設定されます。

    parameter_defaults:
        GlanceCacheEnabled: true
  2. オーバークラウドを再デプロイする際に、openstack overcloud deploy コマンドにその環境ファイルを追加します。
  3. オプション: オーバークラウドを再デプロイする際に、glance_cache_pruner を異なる頻度に調節します。5 分間の頻度の例を以下に示します。

    parameter_defaults:
      ControllerExtraConfig:
        glance::cache::pruner::minute: '*/5'

    ファイルシステムを使い果たす状況を回避するために、ご自分のニーズに合わせて頻度を調節します。異なる頻度を選択する場合は、以下の要素を考慮に入れます。

    • 実際の環境でキャッシュするファイルのサイズ
    • 利用可能なファイルシステムの容量
    • 環境がイメージをキャッシュする頻度

1.1.6. イメージの事前キャッシュ

Red Hat OpenStack Platform (RHOSP) director は、glance-api サービスの一部としてイメージを事前キャッシュすることができます。

1.1.6.1. 定期的にイメージを事前キャッシュする際のデフォルト間隔の設定

イメージの事前キャッシュのデフォルト間隔は、300 秒です。実際の要件に応じて、デフォルトの間隔を増減することができます。

手順

  1. アンダークラウドの環境ファイルの ExtraConfig パラメーターを使用して、実際の要件に応じて新しい間隔を追加します。

    parameter_defaults:
      ControllerExtraConfig:
        glance::config::glance_api_config:
          DEFAULT/cache_prefetcher_interval:
            value: '<300>'

    <300> を、イメージを事前キャッシュする間隔の秒数に置き換えてください。

  2. /home/stack/templates/ の環境ファイルで間隔を修正したら、stack ユーザーとしてログインして設定をデプロイします。

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/<env_file>.yaml

    <env_file> は、追加した ExtraConfig 設定が含まれる環境ファイルの名前に置き換えてください。

    重要

    オーバークラウドの作成時に追加の環境ファイルを渡した場合には、予定外の変更がオーバークラウドに加えられないように、ここで -e オプションを使用して環境ファイルを再度渡します。

openstack overcloud deploy コマンドについての詳しい情報は、Director のインストールと使用方法デプロイメントコマンド を参照してください。

1.1.6.2. 定期的なジョブを使用したイメージの事前キャッシュ

前提条件

定期的なジョブを使用してイメージを事前キャッシュするには、glance_api サービスを実行しているノードに直接接続された glance-cache-manage コマンドを使用する必要があります。サービスの要求に応答するノードを非表示にするプロキシーは使用しないでください。アンダークラウドは glance_api サービスを実行しているネットワークにアクセスできない可能性があるため、最初のオーバークラウドノード (デフォルトでは controller-0 という名前です) でコマンドを実行します。

前提条件として以下の手順を実施して、正しいホストからコマンドが実行され、必要な認証情報が設定されるようにします。また、glance-api コンテナー内から glance-cache-manage コマンドが実行されるようにします。

手順

  1. アンダークラウドに stack ユーザーとしてログインし、controller-0 のプロビジョニング IP アドレスを特定します。

    (undercloud) [stack@site-undercloud-0 ~]$ openstack server list -f value -c Name -c Networks | grep controller
    overcloud-controller-1 ctlplane=192.168.24.40
    overcloud-controller-2 ctlplane=192.168.24.13
    overcloud-controller-0 ctlplane=192.168.24.71
    (undercloud) [stack@site-undercloud-0 ~]$
  2. オーバークラウドに対して認証するには、/home/stack/overcloudrc (デフォルト) に保存されている認証情報を controller-0 にコピーします。

    $ scp ~/overcloudrc heat-admin@192.168.24.71:/home/heat-admin/
  3. controller-0 に接続します。

    $ ssh heat-admin@192.168.24.71
  4. controller-0 において、heat-admin ユーザーとして glance_api service の IP アドレスを特定します。以下の例では、IP アドレスは 172.25.1.105 です。

    (overcloud) [root@controller-0 ~]# grep -A 10 '^listen glance_api' /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg
    listen glance_api
     server central-controller0-0.internalapi.redhat.local 172.25.1.105:9292 check fall 5 inter 2000 rise 2
  5. glance-cache-manage コマンドは glance_api コンテナーでしか利用できないため、そのコンテナーに対して実行するスクリプトを作成します。このコンテナーには、オーバークラウドに対して認証するための環境変数がすでに設定されています。controller-0/home/heat-admin に、以下の内容でスクリプト glance_pod.sh を作成します。

    sudo podman exec -ti \
     -e NOVA_VERSION=$NOVA_VERSION \
     -e COMPUTE_API_VERSION=$COMPUTE_API_VERSION \
     -e OS_USERNAME=$OS_USERNAME \
     -e OS_PROJECT_NAME=$OS_PROJECT_NAME \
     -e OS_USER_DOMAIN_NAME=$OS_USER_DOMAIN_NAME \
     -e OS_PROJECT_DOMAIN_NAME=$OS_PROJECT_DOMAIN_NAME \
     -e OS_NO_CACHE=$OS_NO_CACHE \
     -e OS_CLOUDNAME=$OS_CLOUDNAME \
     -e no_proxy=$no_proxy \
     -e OS_AUTH_TYPE=$OS_AUTH_TYPE \
     -e OS_PASSWORD=$OS_PASSWORD \
     -e OS_AUTH_URL=$OS_AUTH_URL \
     -e OS_IDENTITY_API_VERSION=$OS_IDENTITY_API_VERSION \
     -e OS_COMPUTE_API_VERSION=$OS_COMPUTE_API_VERSION \
     -e OS_IMAGE_API_VERSION=$OS_IMAGE_API_VERSION \
     -e OS_VOLUME_API_VERSION=$OS_VOLUME_API_VERSION \
     -e OS_REGION_NAME=$OS_REGION_NAME \
    glance_api /bin/bash
  6. source コマンドで overcloudrc ファイルを読み込み、glance_pod.sh スクリプトを実行して、オーバークラウドのコントローラーノードに対して認証するのに必要な環境変数が設定されている glance_api コンテナーに対して実行します。

    [heat-admin@controller-0 ~]$ source overcloudrc
    (overcloudrc) [heat-admin@central-controller-0 ~]$ bash glance_pod.sh
    ()[glance@controller-0 /]$
  7. glance image-list 等のコマンドを使用して、コンテナーでオーバークラウドに対して認証されたコマンドを実行できることを確認します。

    ()[glance@controller-0 /]$ glance image-list
    +--------------------------------------+----------------------------------+
    | ID                                   | Name                             |
    +--------------------------------------+----------------------------------+
    | ad2f8daf-56f3-4e10-b5dc-d28d3a81f659 | cirros-0.4.0-x86_64-disk.img       |
    +--------------------------------------+----------------------------------+
    ()[glance@controller-0 /]$

手順

  1. 管理ユーザーとして、キャッシュするイメージをキューに追加します。

    $ glance-cache-manage --host=<host_ip> queue-image <image_id>
    • <host_ip> を glance-api コンテナーが実行されているコントローラーノードの IP アドレスに置き換えます。
    • <image_id> をキューに追加するイメージの ID に置き換えます。

      事前にキャッシュするイメージをキューに追加すると、cache_images 定期ジョブはキューに追加されたすべてのイメージを同時に事前取得します。

      注記

      イメージキャッシュは各ノードにローカルなので、Red Hat OpenStack Platform が HA 設定でデプロイされている場合 (3、5、または 7 台のコントローラー)、glance-cache-manage コマンドを実行する際に --host オプションでホストのアドレスを指定する必要があります。

  2. 以下のコマンドを実行して、イメージキャッシュ内のイメージを表示します。

    $ glance-cache-manage --host=<host_ip> list-cached

    <host_ip> を環境内のホストの IP アドレスに置き換えてください。

関連情報

以下の目的で、さらに glance-cache-manage コマンドを使用することができます。

  • list-cached: 現在キャッシュされているすべてのイメージをリスト表示する。
  • list-queued: キャッシュするために現在キューに追加されているすべてのイメージをリスト表示する。
  • queue-image: キャッシュするためにイメージをキューに追加する。
  • delete-cached-image: キャッシュからイメージを削除する。
  • delete-all-cached-images: キャッシュからすべてのイメージを削除する。
  • delete-cached-image: キャッシュのキューからイメージを削除する。
  • delete-all-queued-images: キャッシュのキューからすべてのイメージを削除する。

1.1.7. Image サービス API を使用したスパースイメージのアップロードの有効化

Image サービス (glance) API を使用すると、スパースイメージのアップロードを使用して、ネットワークトラフィックを削減し、ストレージスペースを節約できます。この機能は、分散コンピュートノード (DCN) 環境で特に便利です。スパースイメージファイルの場合、Image サービスは null バイトシーケンスを書き込みません。Image サービスは、指定されたオフセットでデータを書き込みます。ストレージバックエンドは、これらのオフセットを、実際にはストレージスペースを消費しない null バイトとして解釈します。

制限事項

  • スパースイメージのアップロードは、Ceph RBD でのみサポートされます。
  • スパースイメージのアップロードは、ファイルシステムではサポートされません。
  • スパース性は、クライアントと Image サービス API 間の転送中は維持されません。イメージは、Image サービス API レベルでスパース化されます。

前提条件

  • Red Hat OpenStack Platform (RHOSP) デプロイメントで、Image サービスのバックエンドに RBD を使用している。

手順

  1. アンダークラウドノードに stack ユーザーとしてログインします。
  2. source コマンドで stackrc 認証情報ファイルを読み込みます。

    $ source stackrc
  3. 以下の内容で環境ファイルを作成します。

    parameter_defaults:
        GlanceSparseUploadEnabled: true
  4. その他の環境ファイルと共に新しい環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

    $ openstack overcloud deploy \
    --templates \
    …
    -e <existing_overcloud_environment_files> \
    -e <new_environment_file>.yaml \
    …

    イメージのアップロードの詳細については、「イメージのアップロード」 を参照してください。

検証

イメージをインポートしてそのサイズを確認し、スパースイメージのアップロードを検証することができます。

  1. イメージファイルをローカルにダウンロードします。

    $ wget <file_location>/<file_name>

    <file_location> をファイルの場所に置き換えます。<file_name> は、ファイルの名前に置き換えます。

    次の手順では、コマンド例を使用します。必要に応じて、値をご使用の環境の値に置き換えてください。

    $ wget https://cloud.centos.org/centos/6/images/CentOS-6-x86_64-GenericCloud-1508.qcow2
  2. アップロードするイメージのディスクサイズと仮想サイズを確認します。

     qemu-img info <file_name>

    次の手順では、コマンド例を使用します。必要に応じて、値をご使用の環境の値に置き換えてください。

    $ qemu-img info CentOS-6-x86_64-GenericCloud-1508.qcow2
    
    image: CentOS-6-x86_64-GenericCloud-1508.qcow2
    file format: qcow2
    virtual size: 8 GiB (8589934592 bytes)
    disk size: 1.09 GiB
    cluster_size: 65536
    Format specific information:
    compat: 0.10
    refcount bits: 1
  3. イメージをインポートします。

    $ glance image-create-via-import --disk-format qcow2 --container-format bare --name centos_1 --file <file_name>
  4. イメージ ID を記録します。後続のステップで必要になります。
  5. イメージがインポートされ、アクティブ状態にあることを確認します。

    $ openstack image show <image_id>
  6. Ceph Storage ノードから、イメージのサイズが、ステップ 1 出力の仮想サイズよりも小さいことを確認します。

    $ sudo rbd -p images diff <image_id> | awk '{ SUM += $2 } END { print SUM/1024/1024/1024 " GB" }'
    
    1.03906 GB
  7. オプション:コントローラーノードの glance 設定ファイルで rbd_thin_provisioning が設定されていることを確認できます。

    1. コントローラーノードにアクセスするために SSH を使用します。

      $ ssh -A -t heat-admin@<controller_node_IP_address>
    2. そのコントローラーノードで rbd_thin_provisioningTrue に等しいことを確認します。

      $ sudo podman exec -it glance_api sh -c 'grep ^rbd_thin_provisioning /etc/glance/glance-api.conf'

1.1.8. metadef API の保護

Red Hat OpenStack Platform (RHOSP) では、ユーザーはメタデータ定義 (metadef) API を使用してキー/値のペアおよびタグメタデータを定義することができます。現時点では、ユーザーが作成することのできる metadef 名前空間、オブジェクト、属性、リソース、またはタグの数に制限はありません。

metadef API により、情報が権限のないユーザーに漏えいする可能性があります。悪意のあるユーザーは制約がないことを悪用し、Image サービス (glance) のデータベースを無制限のリソースで埋め尽くすことができます。これにより、サービス拒否 (DoS) 型の攻撃を行うことができます。

Image サービスのポリシーは metadef API を制御します。ただし、metadef API のデフォルトのポリシー設定では、すべてのユーザーが metadef 情報を作成または読み取ることができます。metadef リソースへのアクセスは所有者だけに制限されている訳ではないため、内部インフラストラクチャーの詳細や顧客名などの秘匿すべき名前を持つ metadef リソースの情報が、悪意のあるユーザーに漏えいする可能性があります。

1.1.8.1. metadef API を制限するためのポリシーの設定

Image サービス (glance) をよりセキュアにするには、Red Hat OpenStack Platform (RHOSP) デプロイメントのデフォルトでは metadef 変更 API へのアクセスを管理者だけに制限します。

手順

  1. クラウド管理者として新たな heat テンプレートの環境ファイルを作成し (例: lock-down-glance-metadef-api.yaml)、Image サービス metadef API のポリシーオーバーライドを含めます。

    ...
    parameter_defaults:
      GlanceApiPolicies: {
    	glance-metadef_default: { key: 'metadef_default', value: '' },
    	glance-metadef_admin: { key: 'metadef_admin', value: 'role:admin' },
    	glance-get_metadef_namespace: { key: 'get_metadef_namespace', value: 'rule:metadef_default' },
    	glance-get_metadef_namespaces: { key: 'get_metadef_namespaces', value: 'rule:metadef_default' },
    	glance-modify_metadef_namespace: { key: 'modify_metadef_namespace', value: 'rule:metadef_admin' },
    	glance-add_metadef_namespace: { key: 'add_metadef_namespace', value: 'rule:metadef_admin' },
    	glance-delete_metadef_namespace: { key: 'delete_metadef_namespace', value: 'rule:metadef_admin' },
    	glance-get_metadef_object: { key: 'get_metadef_object', value: 'rule:metadef_default' },
    	glance-get_metadef_objects: { key: 'get_metadef_objects', value: 'rule:metadef_default' },
    	glance-modify_metadef_object: { key: 'modify_metadef_object', value: 'rule:metadef_admin' },
    	glance-add_metadef_object: { key: 'add_metadef_object', value: 'rule:metadef_admin' },
    	glance-delete_metadef_object: { key: 'delete_metadef_object', value: 'rule:metadef_admin' },
    	glance-list_metadef_resource_types: { key: 'list_metadef_resource_types', value: 'rule:metadef_default' },
    	glance-get_metadef_resource_type: { key: 'get_metadef_resource_type', value: 'rule:metadef_default' },
    	glance-add_metadef_resource_type_association: { key: 'add_metadef_resource_type_association', value: 'rule:metadef_admin' },
    	glance-remove_metadef_resource_type_association: { key: 'remove_metadef_resource_type_association', value: 'rule:metadef_admin' },
    	glance-get_metadef_property: { key: 'get_metadef_property', value: 'rule:metadef_default' },
    	glance-get_metadef_properties: { key: 'get_metadef_properties', value: 'rule:metadef_default' },
    	glance-modify_metadef_property: { key: 'modify_metadef_property', value: 'rule:metadef_admin' },
    	glance-add_metadef_property: { key: 'add_metadef_property', value: 'rule:metadef_admin' },
    	glance-remove_metadef_property: { key: 'remove_metadef_property', value: 'rule:metadef_admin' },
    	glance-get_metadef_tag: { key: 'get_metadef_tag', value: 'rule:metadef_default' },
    	glance-get_metadef_tags: { key: 'get_metadef_tags', value: 'rule:metadef_default' },
    	glance-modify_metadef_tag: { key: 'modify_metadef_tag', value: 'rule:metadef_admin' },
    	glance-add_metadef_tag: { key: 'add_metadef_tag', value: 'rule:metadef_admin' },
    	glance-add_metadef_tags: { key: 'add_metadef_tags', value: 'rule:metadef_admin' },
    	glance-delete_metadef_tag: { key: 'delete_metadef_tag', value: 'rule:metadef_admin' },
    	glance-delete_metadef_tags: { key: 'delete_metadef_tags', value: 'rule:metadef_admin' }
      }
    
    …
  2. オーバークラウドのデプロイ時に -e オプションを使用して、ポリシーオーバーライドが含まれる環境ファイルをデプロイメントコマンドに追加します。

    $ openstack overcloud deploy -e lock-down-glance-metadef-api.yaml

1.1.8.2. metadef API の有効化

以前にメタデータ定義 (metadef) API を制限している場合や、新規のデフォルトを緩和する場合は、metadef 変更ポリシーをオーバーライドして、ユーザーがそれぞれのリソースを更新できるようにすることが可能です。

重要

metadef API への書き込みアクセスに依存するユーザーを管理するクラウド管理者は、すべてのユーザーがこれらの API にアクセスできるようにすることが可能です。ただし、この種の設定では、顧客名や内部プロジェクト等の秘匿すべきリソース名が意図せず漏えいする可能性があります。すべてのユーザーに読み取りアクセスしか付与していない場合であっても、管理者はシステムを監査し、過去に作成したセキュリティー的に脆弱なリソースを識別する必要があります。

手順

  1. クラウド管理者としてアンダークラウドにログインし、ポリシーオーバーライド用のファイルを作成します。以下に例を示します。

    $ cat open-up-glance-api-metadef.yaml
  2. すべてのユーザーが metadef API を読み取り/書き込みできるように、ポリシーオーバーライドファイルを設定します。

    GlanceApiPolicies: {
        glance-metadef_default: { key: 'metadef_default', value: '' },
        glance-get_metadef_namespace: { key: 'get_metadef_namespace', value: 'rule:metadef_default' },
        glance-get_metadef_namespaces: { key: 'get_metadef_namespaces', value: 'rule:metadef_default' },
        glance-modify_metadef_namespace: { key: 'modify_metadef_namespace', value: 'rule:metadef_default' },
        glance-add_metadef_namespace: { key: 'add_metadef_namespace', value: 'rule:metadef_default' },
        glance-delete_metadef_namespace: { key: 'delete_metadef_namespace', value: 'rule:metadef_default' },
        glance-get_metadef_object: { key: 'get_metadef_object', value: 'rule:metadef_default' },
        glance-get_metadef_objects: { key: 'get_metadef_objects', value: 'rule:metadef_default' },
        glance-modify_metadef_object: { key: 'modify_metadef_object', value: 'rule:metadef_default' },
        glance-add_metadef_object: { key: 'add_metadef_object', value: 'rule:metadef_default' },
        glance-delete_metadef_object: { key: 'delete_metadef_object', value: 'rule:metadef_default' },
        glance-list_metadef_resource_types: { key: 'list_metadef_resource_types', value: 'rule:metadef_default' },
        glance-get_metadef_resource_type: { key: 'get_metadef_resource_type', value: 'rule:metadef_default' },
        glance-add_metadef_resource_type_association: { key: 'add_metadef_resource_type_association', value: 'rule:metadef_default' },
        glance-remove_metadef_resource_type_association: { key: 'remove_metadef_resource_type_association', value: 'rule:metadef_default' },
        glance-get_metadef_property: { key: 'get_metadef_property', value: 'rule:metadef_default' },
        glance-get_metadef_properties: { key: 'get_metadef_properties', value: 'rule:metadef_default' },
        glance-modify_metadef_property: { key: 'modify_metadef_property', value: 'rule:metadef_default' },
        glance-add_metadef_property: { key: 'add_metadef_property', value: 'rule:metadef_default' },
        glance-remove_metadef_property: { key: 'remove_metadef_property', value: 'rule:metadef_default' },
        glance-get_metadef_tag: { key: 'get_metadef_tag', value: 'rule:metadef_default' },
        glance-get_metadef_tags: { key: 'get_metadef_tags', value: 'rule:metadef_default' },
        glance-modify_metadef_tag: { key: 'modify_metadef_tag', value: 'rule:metadef_default' },
        glance-add_metadef_tag: { key: 'add_metadef_tag', value: 'rule:metadef_default' },
        glance-add_metadef_tags: { key: 'add_metadef_tags', value: 'rule:metadef_default' },
        glance-delete_metadef_tag: { key: 'delete_metadef_tag', value: 'rule:metadef_default' },
        glance-delete_metadef_tags: { key: 'delete_metadef_tags', value: 'rule:metadef_default' }
      }
    注記

    すべての metadef ポリシーを設定する際に、rule:metadeta_default を使用する必要があります。

  3. オーバークラウドのデプロイ時に -e オプションを使用して、デプロイメントコマンドに新しいポリシーファイルを追加します。

    $ openstack overcloud deploy -e open-up-glance-api-metadef.yaml