Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

4.2. Block Storage (cinder) ボリュームの暗号化

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

手順

  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
    Copy to Clipboard Toggle word wrap

  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                                                                                                                                                         |
+-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    Copy to Clipboard Toggle word wrap

  3. 新しいボリュームを作成して、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     |
+---------------------+--------------------------------------+
    Copy to Clipboard Toggle word wrap

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

    注記

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

  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       |
+------------------------------------------------------------------------------------+------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+
    Copy to Clipboard Toggle word wrap

  5. 新規ボリュームを既存のインスタンスにアタッチします。以下に例を示します。 

    $ openstack server add volume testInstance Encrypted-Test-Volume
    Copy to Clipboard Toggle word wrap

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

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 ボリューム操作に影響を及ぼす可能性があります。たとえば、別のユーザーのボリュームの割り当て、割り当て解除、または削除はできません。

手順

  1. barbican サービスをデプロイします。

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

    #openstack role create creator
#openstack role add --user cinder creator  --project service
    Copy to Clipboard Toggle word wrap

  3. cinder-volume および cinder-backup サービスを再起動します。cinder-volume および cinder-backup サービスは、移行プロセスを自動的に開始します。ログファイルを確認して、移行についてのステータス情報を表示できます。

    • cinder-volume: cinder の Volumes および Snapshots テーブルに保存される鍵を移行します。
    • cinder-backup: Backups テーブルの鍵を移行します。
  4. 移行が完了したことを示すメッセージのログを監視し、ボリュームが ConfKeyManager オールゼロ暗号鍵 ID を使用していないことを確認します。
  5. cinder.conf および nova.conf から fixed_key オプションを削除します。この設定が設定されているノードを判別する必要があります。
  6. 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.`
    Copy to Clipboard Toggle word wrap

  • 次のエントリーも表示できます。

    • 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 サービスに移行するボリュームがあるかどうかを認識します。

各ホストは自身のボリュームのみを移行しますが、概要メッセージは、ボリュームの移行が依然として必要なかどうかについて、グローバルアセスメントに基づいています。これにより、すべてのボリュームの移行が完了しているかどうかを確認できます。

Cleanup

キー ID を barbican に移行すると、固定キーが設定ファイル内に残ります。fixed_key の値が .conf ファイルで暗号化されないため、一部のユーザーにセキュリティー上の問題が発生することがあります。

これに対処するには、nova および cinder の設定から fixed_key の値を手動で削除します。ただし、最初にログファイルの出力が完了してから、続行する前にログファイルの出力を確認します。この値がまだ依存するディスクにはアクセスできないためです。

重要

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

  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
    Copy to Clipboard Toggle word wrap
    重要

    既存の 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
    Copy to Clipboard Toggle word wrap

トラブルシューティング

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 サービスを再起動します。

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

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat