第5章 cinder ボリュームの暗号化

barbican を使用して Block Storage (cinder) の暗号化キーを管理することができます。この設定は、LUKS を使用して、インスタンスに接続されているディスク (ブートディスクを含む) を暗号化します。キー管理はユーザーに透過的です。暗号化種別として luks を使用して新規ボリュームを作成すると、cinder はボリュームの対称キーシークレットを生成し、それを barbican に保存します。インスタンスをブート (または暗号化されたボリュームをアタッチ) する場合は、nova はキーを barbican から取得して、そのシークレットをコンピュートノード上の Libvirt シークレットとしてローカルに保存します。

重要

Nova は、暗号化されていない場合に初回使用時に暗号化されたボリュームをフォーマットします。作成されるブロックデバイスは、コンピュートノードに提示されます。

注記

設定ファイルを更新する場合には、特定の OpenStack サービスはコンテナー内で実行されるようになったことを認識する必要があります。これは、keystone、nova、cinder などのサービスが対象です。その結果、考慮すべき管理プラクティスがいくつかあります。

  • 物理ノードのホストオペレーティングシステム上の設定ファイル (例: /etc/cinder/cinder.conf) は更新しないでください。コンテナー化されたサービスはこのようなファイルを参照しません。
  • コンテナー内で実行されている設定ファイルは更新しないでください。コンテナーを再起動すると、変更が失われます。

    代わりに、コンテナー化されたサービスを変更する必要がある場合は、コンテナーの生成に使用される /var/lib/config-data/puppet-generated/ の設定ファイルを更新します。

    以下に例を示します。

  • keystone: /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf
  • cinder: /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf
  • nova: /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf

    変更は、コンテナーを再起動した後に適用されます。

  1. cinder-volume および nova-compute サービスを実行しているノードで、nova と cinder の両方がキー管理に barbican を使用するように設定されていることを確認します。

    $ crudini --get /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf key_manager backend
    castellan.key_manager.barbican_key_manager.BarbicanKeyManager
    
    $ crudini --get /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf key_manager backend
    castellan.key_manager.barbican_key_manager.BarbicanKeyManager
  2. 暗号化を使用するボリュームテンプレートを作成します。新しいボリュームを作成すると、設定からモデル化できます。

    $ openstack volume type create --encryption-provider nova.volume.encryptors.luks.LuksEncryptor --encryption-cipher aes-xts-plain64 --encryption-key-size 256 --encryption-control-location front-end LuksEncryptor-Template-256
    +-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    | Field       | Value                                                                                                                                                                              |
    +-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    | description | None                                                                                                                                                                               |
    | encryption  | cipher='aes-xts-plain64', control_location='front-end', encryption_id='9df604d0-8584-4ce8-b450-e13e6316c4d3', key_size='256', provider='nova.volume.encryptors.luks.LuksEncryptor' |
    | id          | 78898a82-8f4c-44b2-a460-40a5da9e4d59                                                                                                                                               |
    | is_public   | True                                                                                                                                                                               |
    | name        | LuksEncryptor-Template-256                                                                                                                                                         |
    +-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  3. 新しいボリュームを作成して、LuksEncryptor-Template-256 設定を使用するように指定します。

    注記

    暗号化されたボリュームを作成するユーザーに、プロジェクトで creator barbican ロールがあることを確認します。詳細は、creator ロールへのユーザーアクセスの付与 セクションを参照してください。

    $ openstack volume create --size 1 --type LuksEncryptor-Template-256 'Encrypted-Test-Volume'
    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | attachments         | []                                   |
    | availability_zone   | nova                                 |
    | bootable            | false                                |
    | consistencygroup_id | None                                 |
    | created_at          | 2018-01-22T00:19:06.000000           |
    | description         | None                                 |
    | encrypted           | True                                 |
    | id                  | a361fd0b-882a-46cc-a669-c633630b5c93 |
    | migration_status    | None                                 |
    | multiattach         | False                                |
    | name                | Encrypted-Test-Volume                |
    | properties          |                                      |
    | replication_status  | None                                 |
    | size                | 1                                    |
    | snapshot_id         | None                                 |
    | source_volid        | None                                 |
    | status              | creating                             |
    | type                | LuksEncryptor-Template-256           |
    | updated_at          | None                                 |
    | user_id             | 0e73cb3111614365a144e7f8f1a972af     |
    +---------------------+--------------------------------------+

    生成されるシークレットは barbican バックエンドに自動的にアップロードされます。

  4. barbican を使用して、ディスクの暗号化キーが存在することを確認します。この例では、タイムスタンプが LUKS ボリュームの作成時間と一致します。

    $ openstack secret list
    +------------------------------------------------------------------------------------+------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+
    | Secret href                                                                        | Name | Created                   | Status | Content types                             | Algorithm | Bit length | Secret type | Mode | Expiration |
    +------------------------------------------------------------------------------------+------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+
    | https://192.168.123.169:9311/v1/secrets/24845e6d-64a5-4071-ba99-0fdd1046172e | None | 2018-01-22T02:23:15+00:00 | ACTIVE | {u'default': u'application/octet-stream'} | aes       |        256 | symmetric   | None | None       |
    +------------------------------------------------------------------------------------+------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+
  5. 新規ボリュームを既存のインスタンスにアタッチします。以下に例を示します。

    $ openstack server add volume testInstance Encrypted-Test-Volume

    その後、ボリュームはゲストオペレーティングシステムに表示され、組み込みツールを使用してマウントできます。

5.1. 既存のボリューム鍵の Barbican への移行

以前のバージョンでは、デプロイメントでディスク暗号化キーの管理に ConfKeyManager が使用される可能性がありました。そのため、固定キーが生成され、nova および cinder の設定ファイルに保存されていました。以下の手順で、キー ID を barbican に移行することができます。このユーティリティーは、barbican への移行についてスコープ内の encryption_key_id エントリーのデータベースをスキャンすることで機能します。各エントリーは新しい barbican キー ID を取得し、既存の ConfKeyManager シークレットが保持されます。

注記

以前は、ConfKeyManager を使用して暗号化されたボリュームの所有権を再割り当てすることができました。これは、barbican が管理するキーを持つボリュームにはできません。

注記

barbican をアクティベートすると、既存の keymgr ボリュームが破損しません。

有効な場合、移行プロセスは自動的に実行されますが、次のセクションで説明されているように、一部の設定が必要になります。実際の移行は cinder-volume および cinder-backup プロセスで実行され、cinder ログファイル内の進捗を追跡できます。

  • cinder-volume: cinder のVolumesおよびSnapshotsテーブルに保存される鍵を移行します。
  • cinder-backup: Backups テーブルの鍵を移行します。

5.1.1. 移行手順の概要

  1. barbican サービスをデプロイします。
  2. creator ロールを cinder サービスに追加します。以下に例を示します。

    #openstack role create creator
    #openstack role add --user cinder creator  --project service
  3. cinder-volume および cinder-backup サービスを再起動します。
  4. cinder-volume および cinder-backup は、移行プロセスを自動的に開始します。
  5. 移行が完了したことを示すメッセージのログを監視し、ボリュームが ConfKeyManager オールゼロ暗号鍵 ID を使用していないことを確認します。
  6. cinder.conf および nova.conf から fixed_key オプションを削除します。この設定が設定されているノードを判別する必要があります。
  7. cinder サービスから creator ロールを削除します。

5.1.2. 動作の違い

barbican が管理する暗号化ボリュームは、ConfKeyManager を使用するボリュームとは異なる動作をします。

  • 現在、barbican シークレットの所有権を転送することができないため、暗号化されたボリュームの所有権は移動できません。
  • barbican は、シークレットの読み取りと削除ができるかより厳しいので、一部の cinder ボリューム操作に影響を及ぼす可能性があります。たとえば、別のユーザーのボリュームの割り当て、割り当て解除、または削除はできません。

5.1.3. 移行プロセスの確認

本セクションでは、移行タスクのステータスを表示する方法を説明します。プロセスを起動すると、これらのエントリーの 1 つがログに表示されます。これは、移行が正しく開始するか、または発生した問題を特定するかどうかを示します。

  • Not migrating encryption keys because the ConfKeyManager is still in use.
  • Not migrating encryption keys because the ConfKeyManager's fixed_key is not in use.
  • Not migrating encryption keys because migration to the 'XXX' key_manager backend is not supported. - このメッセージが表示されることはほとんどありません。barbican 以外の別の Key Manager バックエンドに遭遇していたコードを処理するための安全チェックです。これは、コードが 1 つの移行シナリオ (ConfKeyManager から barbican ) のみをサポートする ためです。
  • Not migrating encryption keys because there are no volumes associated with this host. - これは、cinder-volume が複数のホストで実行され、特定のホストにボリュームが関連付けられていない場合に生じる可能性があります。これは、すべてのホストが独自のボリュームを処理するため発生します。
  • Starting migration of ConfKeyManager keys.
  • Migrating volume <UUID> encryption key to Barbican - 移行時に、ホストのボリュームがすべて検証され、ボリュームが ConfKeyManager のキー ID を使用している場合に (すべてがゼロ (00000000-0000-0000-0000-000000000000) であることで確認)、このメッセージが表示されます。

    • cinder-backup では、このメッセージは若干異なる大文字を使用します。Migrating Volume [...] または Migrating Backup [...]
  • 各ホストがすべてのボリュームを検査すると、ホストはサマリーステータスメッセージを表示します。

    `No volumes are using the ConfKeyManager's encryption_key_id.`
    `No backups are known to be using the ConfKeyManager's encryption_key_id.`

    以下のエントリーも表示される場合があります。

    There are still %d volume(s) using the ConfKeyManager's all-zeros encryption key ID.There are still %d backup(s) using the ConfKeyManager’s all-zeros encryption key ID.これらのメッセージはいずれも cinder-volume および cinder-backup ログに表示される場合がある点に注意してください。各サービスは独自のエントリーの移行のみを処理しますが、サービスは他のステータスを認識します。これにより、cinder-volumecinder-backup に移行するバックアップがまだあるかどうかを認識し、cinder-backupcinder-volume サービスに移行するボリュームがあるかどうかを認識します。

    各ホストは自身のボリュームのみを移行しますが、概要メッセージは、ボリュームの移行が依然として必要なかどうかについて、グローバルアセスメントに基づいています。これにより、すべてのボリュームの移行が完了しているかどうかを確認できます。確認が終わったら、fixed_key の設定を cinder.conf および nova.conf から削除します。詳細は、Clean up the fixed keys のセクションを参照してください。

5.1.4. 移行プロセスのトラブルシューティング

5.1.4.1. ロール割り当て

barbican シークレットは、要求に creator ロールがある場合にのみ作成できます。これは、cinder サービス自体が作成者ロールが必要なことを意味します。それ以外の場合は、以下のようなログシーケンスが発生します。

  1. Starting migration of ConfKeyManager keys.
  2. Migrating volume <UUID> encryption key to Barbican
  3. Error migrating encryption key: Forbidden: Secret creation attempt not allowed - please review your user/project privileges
  4. There are still %d volume(s) using the ConfKeyManager's all-zeros encryption key ID.

鍵に関するメッセージは、3 番目のSecret creation attempt not allowedです。問題を修正するには、cinder アカウントの権限を更新します。

  1. openstack role add --project service --user cinder creator を実行します。
  2. cinder-volume および cinder-backup サービスを再起動します。

その結果、次の移行試行に成功します。

5.1.5. 固定キーの削除

重要

最近 encryption_key_id は、Queens リリースの一環として、Backup テーブルにのみ追加されました。その結果、暗号化されたボリュームの既存のバックアップが存在する可能性があります。すべてがゼロの encryption_key_id はバックアップ自体に保存されますが、Backup データベースには表示されません。そのため、移行プロセスでは、暗号化されたボリュームのバックアップが存在し、all-zero の ConfKeyMgr キー ID に依存するかを知ることはできません。

キー ID を barbican に移行すると、固定キーが設定ファイル内に残ります。fixed_key の値が .conf ファイルで暗号化されないため、一部のユーザーにセキュリティー上の問題が発生することがあります。これに対処するには、nova および cinder の設定から fixed_key の値を手動で削除します。ただし、最初にログファイルの出力が完了してから、続行する前にログファイルの出力を確認します。この値がまだ依存するディスクにはアクセスできないためです。

  1. 既存の fixed_key の値を確認します。値は、両方のサービスと一致している必要があります。

    crudini --get /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf keymgr fixed_key
    crudini --get /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf keymgr fixed_key
    重要

    既存の fixed_key の値のバックアップを作成します。これにより、何らかの問題が発生した場合や、古い暗号鍵を使用するバックアップを復元する必要がある場合に、値を復元できます。

  2. fixed_key の値を削除します。

    crudini --del /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf keymgr fixed_key
    crudini --del /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf keymgr fixed_key