4.2. Block Storage (cinder) ボリュームの暗号化
barbican を使用して Block Storage (cinder) の暗号化キーを管理することができます。この設定は、LUKS を使用して、インスタンスに接続されているディスク (ブートディスクを含む) を暗号化します。キー管理はユーザーに透過的です。暗号化種別として luks
を使用して新規ボリュームを作成すると、cinder はボリュームの対称キーシークレットを生成し、それを barbican に保存します。インスタンスをブート (または暗号化されたボリュームをアタッチ) する場合は、nova はキーを barbican から取得して、そのシークレットをコンピュートノード上の Libvirt シークレットとしてローカルに保存します。
手順
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
暗号化を使用するボリュームテンプレートを作成します。新しいボリュームを作成すると、設定からモデル化できます。
$ 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 | +-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
新しいボリュームを作成して、
LuksEncryptor-Template-256
設定を使用するように指定します。$ 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 バックエンドに自動的にアップロードされます。
注記暗号化されたボリュームを作成するユーザーに、プロジェクトで
creator
barbican ロールがあることを確認します。詳細は、Grant user access to the creator role
セクションを参照してください。Barbican シークレット UUID を取得します。この値は、
encryption_key_id
フィールドに表示されます。$ cinder --os-volume-api-version 3.64 volume show Encrypted-Test-Volume +------------------------------+-------------------------------------+ |Property |Value | +------------------------------+-------------------------------------+ |attached_servers |[] | |attachment_ids |[] | |availability_zone |nova | |bootable |false | |cluster_name |None | |consistencygroup_id |None | |created_at |2022-07-28T17:35:26.000000 | |description |None | |encrypted |True | |encryption_key_id |0944b8a8-de09-4413-b2ed-38f6c4591dd4 | |group_id |None | |id |a0b51b97-0392-460a-abfa-093022a120f3 | |metadata | | |migration_status |None | |multiattach |False | |name |vol | |os-vol-host-attr:host |hostgroup@tripleo_iscsi#tripleo_iscsi| |os-vol-mig-status-attr:migstat|None | |os-vol-mig-status-attr:name_id|None | |os-vol-tenant-attr:tenant_id |a2071ece39b3440aa82395ff7707996f | |provider_id |None | |replication_status |None | |service_uuid |471f0805-072e-4256-b447-c7dd10ceb807 | |shared_targets |False | |size |1 | |snapshot_id |None | |source_volid |None | |status |available | |updated_at |2022-07-28T17:35:26.000000 | |user_id |ba311b5c2b8e438c951d1137333669d4 | |volume_type |LUKS | |volume_type_id |cc188ace-f73d-4af5-bf5a-d70ccc5a401c | +------------------------------+-------------------------------------+
注記encryption_key_id
値を表示するには、Cinder CLI で--os-volume-api-version 3.64
パラメーターを使用する必要があります。同等の OpenStack CLI コマンドはありません。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/0944b8a8-de09-4413-b2ed-38f6c4591dd4 | None | 2018-01-22T02:23:15+00:00 | ACTIVE | {u'default': u'application/octet-stream'} | aes | 256 | symmetric | None | None | +------------------------------------------------------------------------------------+------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+
新規ボリュームを既存のインスタンスにアタッチします。以下に例を示します。
$ openstack server add volume testInstance Encrypted-Test-Volume
その後、ボリュームはゲストオペレーティングシステムに表示され、組み込みツールを使用してマウントできます。
4.2.1. Block Storage ボリュームの OpenStack Key Manager への移行
以前に ConfKeyManager
を使用してディスク暗号化鍵を管理していた場合は、データベースをスキャンして、barbican への移行のスコープ内に encryption_key_id
エントリーの有無を確認し、ボリュームを OpenStack Key Manager に移行できます。各エントリーは新しい barbican キー ID を取得し、既存の ConfKeyManager
シークレットが保持されます。
-
以前は、
ConfKeyManager
を使用して暗号化されたボリュームの所有権を再割り当てすることができました。これは、barbican が管理するキーを持つボリュームにはできません。 -
barbican をアクティベートすると、既存の
keymgr
ボリュームが破損しません。
前提条件
移行前に、Barbican が管理する暗号化ボリュームと、ConfKeyManager
を使用するボリューム間の以下の違いを確認してください。
- 現在、barbican シークレットの所有権を転送することができないため、暗号化されたボリュームの所有権は移動できません。
- barbican は、シークレットの読み取りと削除ができるかより厳しいので、一部の cinder ボリューム操作に影響を及ぼす可能性があります。たとえば、別のユーザーのボリュームの割り当て、割り当て解除、または削除はできません。
手順
- barbican サービスをデプロイします。
creator
ロールを cinder サービスに追加します。以下に例を示します。#openstack role create creator #openstack role add --user cinder creator --project service
cinder-volume
およびcinder-backup
サービスを再起動します。cinder-volume
およびcinder-backup
サービスは、移行プロセスを自動的に開始します。ログファイルを確認して、移行に関するステータス情報を表示できます。-
cinder-volume
: cinder の Volumes および Snapshots テーブルに保存される鍵を移行します。 -
cinder-backup
: Backups テーブルの鍵を移行します。
-
-
移行が完了したことを示すメッセージのログを監視し、ボリュームが
ConfKeyManager
オールゼロ暗号鍵 ID を使用していないことを確認します。 -
cinder.conf
およびnova.conf
からfixed_key
オプションを削除します。この設定が設定されているノードを判別する必要があります。 -
cinder サービスから
creator
ロールを削除します。
検証
プロセスを起動すると、これらのエントリーの 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-volume
はcinder-backup
に移行するバックアップがまだあるかどうかを認識し、cinder-backup
はcinder-volume
サービスに移行するボリュームがあるかどうかを認識します。
-
各ホストは自身のボリュームのみを移行しますが、概要メッセージは、ボリュームの移行が依然として必要なかどうかについて、グローバルアセスメントに基づいています。これにより、すべてのボリュームの移行が完了しているかどうかを確認できます。
クリーンアップ
キー ID を barbican に移行すると、固定キーが設定ファイル内に残ります。fixed_key
の値が .conf
ファイルで暗号化されないため、一部のユーザーにセキュリティー上の問題が発生することがあります。
これに対処するには、nova および cinder の設定から fixed_key
の値を手動で削除します。ただし、最初にログファイルの出力が完了してから、続行する前にログファイルの出力を確認します。この値がまだ依存するディスクにはアクセスできないためです。
最近 encryption_key_id
は、Queens リリースの一環として、Backup
テーブルにのみ追加されました。その結果、暗号化されたボリュームの既存のバックアップが存在する可能性があります。すべてがゼロの encryption_key_id
はバックアップ自体に保存されますが、Backup
データベースには表示されません。そのため、移行プロセスでは、暗号化されたボリュームのバックアップが存在し、all-zero の ConfKeyMgr
キー ID に依存するかを知ることはできません。
既存の
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
の値のバックアップを作成します。これにより、何らかの問題が発生した場合や、古い暗号鍵を使用するバックアップを復元する必要がある場合に、値を復元できます。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
トラブルシューティング
barbican シークレットは、要求に creator
ロールがある場合にのみ作成できます。これは、cinder サービス自体が作成者ロールが必要なことを意味します。それ以外の場合は、以下のようなログシーケンスが発生します。
-
Starting migration of ConfKeyManager keys.
-
Migrating volume <UUID> encryption key to Barbican
-
Error migrating encryption key: Forbidden: Secret creation attempt not allowed - please review your user/project privileges
-
There are still %d volume(s) using the ConfKeyManager's all-zeros encryption key ID.
鍵に関するメッセージは、3 番目の Secret creation attempt not allowed
です。問題を修正するには、cinder
アカウントの権限を更新します。
-
openstack role add --project service --user cinder creator
を実行します。 -
cinder-volume
およびcinder-backup
サービスを再起動します。
その結果、次の移行試行に成功します。