Manage Secrets with OpenStack Key Manager
OpenStack Key Manager (Barbican) を OpenStack デプロイメントと統合する方法。
概要
第1章 概要
OpenStack Key Manager (barbican) は Red Hat OpenStack Platform のシークレットマネージャーです。barbican API とコマンドラインを使用して、OpenStack サービスの使用する証明書、キー、パスワードを一元管理することができます。barbican は現在、本書で説明されている以下のユースケースをサポートします。
- 対称暗号鍵: 中でも Block Storage (cinder) ボリュームの暗号化、一時ディスク暗号化、および Object Storage (swift) の暗号化に使用されます。
- 非対称鍵と証明書: glance イメージの署名や検証などに使用されます。
本リリースでは、barbican は Block Storage (cinder) および Compute (nova) コンポーネントとの統合を提供します。
第2章 バックエンドの選択
シークレット (証明書、API キー、パスワードなど) は、暗号化された Blob として barbican データベースに保存することも、セキュアなストレージシステムに直接保存することもできます。
シークレットを暗号化された Blob として barbican データベースに保管するには、以下のオプションを使用することができます。
-
単純な crypto プラグイン： 簡単 な暗号化プラグインはデフォルトで有効で、1 つの対称キーを使用してシークレットの Blob を暗号化します。このキーは、プレーンテキストで
barbican.confファイルに保存されます。
現在、シンプルな crypto プラグインは Red Hat でサポートされる唯一のプラグインです。
- PKCS#11 暗号プラグイン - PKCS#11 暗号化プラグインは、barbican データベースに保存されているプロジェクト固有の鍵暗号鍵(KEK)でシークレットを暗号化します。これらのプロジェクト固有の KEK は、マスター KEK で暗号化され、ハードウェアセキュリティーモジュール(HSM)に保存されます。すべての暗号化および復号化操作は、in-process メモリーではなく、HSM に置かれます。PKCS#11 プラグインは、PKCS#11 プロトコルを使用して HSM と通信します。暗号化はセキュアなハードウェアで行われ、プロジェクトごとに別の KEK が使用されるため、このオプションは単純な crypto プラグインよりも安全です。
または、シークレットをセキュアなストレージシステムに直接保存することもできます。
-
KMIP プラグイン: Key Management Interoperability Protocol(KMIP)プラグインは、HSM などの KIMP が有効になっているデバイスで機能します。シークレットは、barbican データベースではなくデバイスに直接保存されます。プラグインは、ユーザー名とパスワードを使用するか、
barbican.confファイルに保存されているクライアント証明書を使用してデバイスに対して認証することができます。 - Red Hat Certificate System(dogtag) - Red Hat Certificate System は、一般的な基準と、公開鍵インフラストラクチャー(PKI)の様々な側面を管理するための FIPS 認定セキュリティーフレームワークです。Key Recovery Authority(KRA)サブシステムは、シークレットをデータベースに暗号化された Blob として保存します。マスター暗号化キーは、ソフトウェアベースの Network Security Services(NSS)データベースまたは HSM のいずれかに保存されます。Red Hat Certificate System の詳細は、Red Hat Certificate System の製品ドキュメント を参照してください。
高可用性 (HA) オプション： barbican サービスは Apache 内で実行され、高可用性に HAProxy を使用するように director により設定されます。バックエンド層の HA オプションは、使用されているバックエンドによって異なります。たとえば、簡単な暗号化の場合、すべての barbican インスタンスには設定ファイル内に同じ暗号化キーがあり、これにより単純な HA 設定が作成されます。
2.1. バックエンド間の移行
Barbican を使用すると、プロジェクトに異なるバックエンドを定義することができます。プロジェクトにマッピングが存在しない場合は、シークレットはグローバルのデフォルトバックエンドに保存されます。つまり、複数のバックエンドを設定することができますが、少なくとも 1 つのグローバルバックエンドを定義する必要があります。異なるバックエンド用に提供された heat テンプレートには、各バックエンドをデフォルトとして設定するパラメーターが含まれます。
特定のバックエンドにシークレットを保存してから新規バックエンドに移行する場合には、グローバルのデフォルト (またはプロジェクト固有のバックエンド) として新しいバックエンドを有効にする間に、古いバックエンドを利用可能な状態にすることができます。その結果、古いシークレットは古いバックエンドで引き続き利用できます。
第3章 Barbican のインストール
Red Hat OpenStack Platform では、barbican はデフォルトで有効になっていません。以下の手順では、既存の OpenStack デプロイメントに barbican をデプロイする方法について説明します。barbican はコンテナー化されたサービスとして実行されるため、この手順では新しいコンテナーイメージの準備およびアップロード方法についても説明します。
この手順では、barbican が simple_crypto バックエンドを使用するように設定します。PKCS11 や DogTag 等の追加バックエンドが利用できますが、本リリースでは対応していません。
アンダークラウドノードで、barbican の環境ファイルを作成します。これにより、director が barbican をインストールするように指示します（ openstack overcloud deploy […]に含まれる場合）。
$ cat /home/stack/configure-barbican.yaml parameter_defaults: BarbicanSimpleCryptoGlobalDefault: true
-
BarbicanSimpleCryptoGlobalDefault- このプラグインをグローバルのデフォルトプラグインとして設定します。 その他のオプションも設定可能です。
-
BarbicanPassword: barbican サービスアカウントのパスワードを設定します。 -
BarbicanWorkers:barbican::wsgi::apacheのワーカー数を設定します。デフォルトで'%{::processorcount}'を使用します。 -
BarbicanDebug: デバッグを有効にします。 -
BarbicanPolicies: barbican 向けに設定するポリシーを定義します。ハッシュ値を使用します（例:{ barbican-context_is_admin: { key: context_is_admin, value: 'role:admin' } }）。このエントリーは/etc/barbican/policy.jsonに追加されます。ポリシーの詳細は、後のセクションで説明します。 -
BarbicanSimpleCryptoKek: キー暗号化キー(KEK)は、指定がない場合は director によって生成されます。
-
-
このステップでは、barbican 用の新規コンテナーイメージを準備します。
configure-barbican.yamlと関連するすべてのテンプレートファイルを含める必要があります。実際のデプロイメントに合わせて、以下の例を変更します。$ openstack overcloud container image prepare \ --namespace example.lab.local:5000/rhosp15-rhel8 \ --tag latest \ --push-destination 192.168.100.1:8787 \ --output-images-file ~/container-images-with-barbican.yaml \ -e /home/stack/virt/config_lvm.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /home/stack/virt/network/network-environment.yaml \ -e /home/stack/virt/hostnames.yml \ -e /home/stack/virt/nodes_data.yaml \ -e /home/stack/virt/extra_templates.yaml \ -e /home/stack/virt/docker-images.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/barbican.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/barbican-backend-simple-crypto.yaml \ -e /home/stack/configure-barbican.yaml
新しいコンテナーイメージをアンダークラウドレジストリーにアップロードします。
$ openstack overcloud container image upload --debug --config-file container-images-with-barbican.yaml
新たな環境ファイルを準備します。
$ openstack overcloud container image prepare \ --tag latest \ --namespace 192.168.100.1:8787/rhosp15-rhel8 \ --output-env-file ~/container-parameters-with-barbican.yaml \ -e /home/stack/virt/config_lvm.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /home/stack/virt/network/network-environment.yaml \ -e /home/stack/virt/hostnames.yml \ -e /home/stack/virt/nodes_data.yaml \ -e /home/stack/virt/extra_templates.yaml \ -e /home/stack/virt/docker-images.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/barbican.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/barbican-backend-simple-crypto.yaml \ -e /home/stack/configure-barbican.yaml
これらの変更をデプロイメントに適用するには、オーバークラウドを更新し、以前の openstack overcloud deploy […] で使用したすべての heat テンプレートファイルを指定します。以下に例を示します。
$ openstack overcloud deploy \ --timeout 100 \ --templates /usr/share/openstack-tripleo-heat-templates \ --stack overcloud \ --libvirt-type kvm \ --ntp-server clock.redhat.com \ -e /home/stack/virt/config_lvm.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /home/stack/virt/network/network-environment.yaml \ -e /home/stack/virt/hostnames.yml \ -e /home/stack/virt/nodes_data.yaml \ -e /home/stack/virt/extra_templates.yaml \ -e /home/stack/container-parameters-with-barbican.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/barbican.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/barbican-backend-simple-crypto.yaml \ -e /home/stack/configure-barbican.yaml \ --log-file overcloud_deployment_38.log
3.1. オーバークラウドの作成者ロールへのユーザーの追加
ユーザーは、barbican シークレットの作成および編集を 実行するために作成者 ロールのメンバーである必要があります。たとえば、このロールは、それらのシークレットを barbican に保管する暗号化されたボリュームを作成するために必要になります。
creatorという名前の新規ロールを作成します。$ openstack role create creator +-----------+----------------------------------+ | Field | Value | +-----------+----------------------------------+ | domain_id | None | | id | 4e9c560c6f104608948450fbf316f9d7 | | name | creator | +-----------+----------------------------------+
creator
ロールのidを取得します。openstack role show creator +-----------+----------------------------------+ | Field | Value | +-----------+----------------------------------+ | domain_id | None | | id | 4e9c560c6f104608948450fbf316f9d7 | | name | creator | +-----------+----------------------------------+
ユーザーを
creatorロールに割り当て、関連するプロジェクトを指定します。この例では、project_aプロジェクトのuser1という名前のユーザーがcreatorロールに追加されます。openstack role add --user user1 --project project_a 4e9c560c6f104608948450fbf316f9d7
3.1.1. barbican 機能のテスト
本セクションでは、barbican が正常に動作していることをテストする方法を説明します。
テストシークレットを作成します。以下に例を示します。
$ openstack secret store --name testSecret --payload 'TestPayload' +---------------+------------------------------------------------------------------------------------+ | Field | Value | +---------------+------------------------------------------------------------------------------------+ | Secret href | https://192.168.123.163/key-manager/v1/secrets/4cc5ffe0-eea2-449d-9e64-b664d574be53 | | Name | testSecret | | Created | None | | Status | None | | Content types | None | | Algorithm | aes | | Bit length | 256 | | Secret type | opaque | | Mode | cbc | | Expiration | None | +---------------+------------------------------------------------------------------------------------+
作成したシークレットのペイロードを取得します。
openstack secret get https://192.168.123.163/key-manager/v1/secrets/4cc5ffe0-eea2-449d-9e64-b664d574be53 --payload +---------+-------------+ | Field | Value | +---------+-------------+ | Payload | TestPayload | +---------+-------------+
3.2. ポリシーについて
barbican はポリシーを使用して、キーの追加または削除など、シークレットに対してアクションを実行できるユーザーを決定します。これらのコントロールを実装するには、keystone プロジェクトロール(以前に作成した creatorなど)は barbican 内部パーミッションにマッピングされます。その結果、これらのプロジェクトロールに割り当てられるユーザーは、対応する barbican パーミッションを受信します。
3.2.1. デフォルトポリシーの表示
デフォルトのポリシーはコードで定義されるため、通常は修正は必要ありません。デフォルトのポリシーは、barbican ソースコードから生成することで表示できます。
追加のコンポーネントをダウンロードし、インストールできるため、実稼働以外のシステムで以下の手順を実行します。この例では、
queensブランチに切り替わっているので、別のバージョンを使用する場合は、これを調整する必要があります。git clone https://github.com/openstack/barbican cd /home/stack/barbican git checkout origin/stable/queens tox -e genpolicy
このコマンドにより、デフォルト設定が含まれるサブディレクトリーにポリシーファイル(
etc/barbican/policy.yaml.sample)が生成されます。このパスは、システムの/etcディレクトリーではなく、リポジトリー内のサブディレクトリーを参照します。このファイルのコンテンツは、以下の手順で説明します。生成した
policy.yaml.sampleファイルは、barbican で使用されるポリシーを記述します。ポリシーは、ユーザーがシークレットおよびシークレットメタデータと対話する方法を定義する 4 つの異なるロールによって実装されます。ユーザーは、特定のロールに割り当てられているパーミッションを受け取ります。-
Admin: シークレットの削除、作成/編集、および読み取りを行うことができます。 -
creator: シークレットの作成/編集および読み取りが可能です。シークレットを削除できません。 -
observer: データの読み取りのみが可能です。 audit: メタデータのみを読み取ることができます。シークレットを読み取りできません。たとえば、以下のエントリーは、各プロジェクトの
admin、observer、およびcreatorのkeystone ロールを一覧表示します。右側には、role:admin、role:observer、およびrole:creatorパーミッションが割り当てられていることを確認します。# #"admin": "role:admin" # #"observer": "role:observer" # #"creator": "role:creator"
これらのロールは barbican でグループ化することもできます。たとえば、
admin_or_creatorを指定するルールは、rule:adminまたはrule:creatorのメンバーに適用できます。
-
ファイル内では、
secret:putおよびsecret:deleteのアクションがあります。右側には、これらのアクションを実行するパーミッションがあるロールについて確認してください。以下の例では、secret:deleteは、adminおよびcreatorロールメンバーのみがシークレットエントリーを削除できることを意味します。さらに、ルールは、そのプロジェクトのadminまたはcreatorロールのユーザーがそのプロジェクトのシークレットを削除できることを示しています。プロジェクトのマッチは、ポリシーにも定義されるsecret_project_matchルールで定義されます。secret:delete": "rule:admin_or_creator and rule:secret_project_match"
第4章 barbican でのシークレットの管理
4.1. シークレットの一覧表示
シークレットは URI によって識別されます。これは href の値として示されます。以下の例では、直前の手順で作成したシークレットを示しています。
$ 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 |
+------------------------------------------------------------------------------------+------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+4.2. 新規シークレットの追加
テストシークレットを作成します。以下に例を示します。
$ openstack secret store --name testSecret --payload 'TestPayload' +---------------+------------------------------------------------------------------------------------+ | Field | Value | +---------------+------------------------------------------------------------------------------------+ | Secret href | https://192.168.123.163:9311/v1/secrets/ecc7b2a4-f0b0-47ba-b451-0f7d42bc1746 | | Name | testSecret | | Created | None | | Status | None | | Content types | None | | Algorithm | aes | | Bit length | 256 | | Secret type | opaque | | Mode | cbc | | Expiration | None | +---------------+------------------------------------------------------------------------------------+
4.3. シークレットの更新
シークレットのペイロード (シークレットの削除以外) を変更することはできませんが、ペイロードを指定せずにシークレットを作成した場合は、後で update 関数を使用してペイロードを追加することができます。以下に例を示します。
$ openstack secret update https://192.168.123.163:9311/v1/secrets/ca34a264-fd09-44a1-8856-c6e7116c3b16 'TestPayload-updated' $
4.4. シークレットの削除
URI を指定してシークレットを削除できます。以下に例を示します。
$ openstack secret delete https://192.168.123.163:9311/v1/secrets/ecc7b2a4-f0b0-47ba-b451-0f7d42bc1746 $
4.5. 対称鍵の生成
対称鍵は、nova のディスク暗号化や swift オブジェクトの暗号化など、特定のタスクに適しています。
order createを使用して新しい 256 ビットのキーを生成し、barbican に保存します。以下に例を示します。$ openstack secret order create --name swift_key --algorithm aes --mode ctr --bit-length 256 --payload-content-type=application/octet-stream key +----------------+-----------------------------------------------------------------------------------+ | Field | Value | +----------------+-----------------------------------------------------------------------------------+ | Order href | https://192.168.123.173:9311/v1/orders/043383fe-d504-42cf-a9b1-bc328d0b4832 | | Type | Key | | Container href | N/A | | Secret href | None | | Created | None | | Status | None | | Error code | None | | Error message | None | +----------------+-----------------------------------------------------------------------------------+
-
--mode: 生成された鍵は、ctrまたはcbcなどの特定のモードを使用するように設定できます。詳細は、NIST SP 800-38A を参照してください。
-
オーダーの詳細を表示して、生成されたキーの場所を
Secret hrefの値として特定します。$ openstack secret order get https://192.168.123.173:9311/v1/orders/043383fe-d504-42cf-a9b1-bc328d0b4832 +----------------+------------------------------------------------------------------------------------+ | Field | Value | +----------------+------------------------------------------------------------------------------------+ | Order href | https://192.168.123.173:9311/v1/orders/043383fe-d504-42cf-a9b1-bc328d0b4832 | | Type | Key | | Container href | N/A | | Secret href | https://192.168.123.173:9311/v1/secrets/efcfec49-b9a3-4425-a9b6-5ba69cb18719 | | Created | 2018-01-24T04:24:33+00:00 | | Status | ACTIVE | | Error code | None | | Error message | None | +----------------+------------------------------------------------------------------------------------+
シークレットの詳細を取得します。
$ openstack secret get https://192.168.123.173:9311/v1/secrets/efcfec49-b9a3-4425-a9b6-5ba69cb18719 +---------------+------------------------------------------------------------------------------------+ | Field | Value | +---------------+------------------------------------------------------------------------------------+ | Secret href | https://192.168.123.173:9311/v1/secrets/efcfec49-b9a3-4425-a9b6-5ba69cb18719 | | Name | swift_key | | Created | 2018-01-24T04:24:33+00:00 | | Status | ACTIVE | | Content types | {u'default': u'application/octet-stream'} | | Algorithm | aes | | Bit length | 256 | | Secret type | symmetric | | Mode | ctr | | Expiration | None | +---------------+------------------------------------------------------------------------------------+
4.6. バックアップおよびリストアキー
暗号化キーのバックアップおよびリストアのプロセスは、バックエンドのタイプによって異なります。
4.6.1. シンプルな暗号化バックエンドをバックアップおよび復元します。
シンプルな暗号化 バックエンドには、2 つの異なるコンポーネント (KEK とデータベース) のバックアップが必要です。バックアップおよび復元プロセスを定期的にテストすることが推奨されます。
4.6.1.1. KEK のバックアップおよび復元
シンプルな暗号化 バックエンドの場合は、マスター KEK を含む barbican.conf ファイルを作成する必要があります。このファイルは、セキュリティーが強化された場所にバックアップされる必要があります。実際のデータは、次のセクションで説明されているように、Barbican データベースに暗号化された状態に保存されます。
-
バックアップから鍵を復元するには、復元された
barbican.confを既存のbarbican.confにコピーする必要があります。
4.6.1.2. バックエンドデータベースのバックアップおよびリストア
この手順では、簡単な暗号化バックエンド向けに、barbican データベースをバックアップおよび復元する方法を説明します。これは、キーを生成し、シークレットを barbican にアップロードします。その後、barbican データベースのバックアップを作成し、作成したシークレットを削除します。次に、データベースを復元し、先に作成したシークレットが復元されていることを確認します。
これは重要な要件であるため、KEK もバックアップするようにしてください。これは、前のセクションで説明します。
4.6.1.2.1. テストシークレットを作成します。
オーバークラウドで
order createを使用して新しい 256 ビットのキーを生成し、barbican に保存します。以下に例を示します。(overcloud) [stack@undercloud-0 ~]$ openstack secret order create --name swift_key --algorithm aes --mode ctr --bit-length 256 --payload-content-type=application/octet-stream key +----------------+-----------------------------------------------------------------------+ | Field | Value | +----------------+-----------------------------------------------------------------------+ | Order href | http://10.0.0.104:9311/v1/orders/2a11584d-851c-4bc2-83b7-35d04d3bae86 | | Type | Key | | Container href | N/A | | Secret href | None | | Created | None | | Status | None | | Error code | None | | Error message | None | +----------------+-----------------------------------------------------------------------+
テストシークレットを作成します。
(overcloud) [stack@undercloud-0 ~]$ openstack secret store --name testSecret --payload 'TestPayload' +---------------+------------------------------------------------------------------------+ | Field | Value | +---------------+------------------------------------------------------------------------+ | Secret href | http://10.0.0.104:9311/v1/secrets/93f62cfd-e008-401f-be74-bf057c88b04a | | Name | testSecret | | Created | None | | Status | None | | Content types | None | | Algorithm | aes | | Bit length | 256 | | Secret type | opaque | | Mode | cbc | | Expiration | None | +---------------+------------------------------------------------------------------------+
シークレットが作成されたことを確認します。
(overcloud) [stack@undercloud-0 ~]$ openstack secret list +------------------------------------------------------------------------+------------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+ | Secret href | Name | Created | Status | Content types | Algorithm | Bit length | Secret type | Mode | Expiration | +------------------------------------------------------------------------+------------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+ | http://10.0.0.104:9311/v1/secrets/93f62cfd-e008-401f-be74-bf057c88b04a | testSecret | 2018-06-19T18:25:25+00:00 | ACTIVE | {u'default': u'text/plain'} | aes | 256 | opaque | cbc | None | | http://10.0.0.104:9311/v1/secrets/f664b5cf-5221-47e5-9887-608972a5fefb | swift_key | 2018-06-19T18:24:40+00:00 | ACTIVE | {u'default': u'application/octet-stream'} | aes | 256 | symmetric | ctr | None | +------------------------------------------------------------------------+------------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+
4.6.1.2.2. barbican データベースのバックアップ
controller-0 ノードにログインした状態で以下の手順を実行します。
barbican データベースにアクセスできるのは、ユーザー barbican のみです。そのため、barbican ユーザーのパスワードはデータベースをバックアップまたは復元するために必要です。
barbican ユーザーのパスワードを取得します。以下に例を示します。
[heat-admin@controller-0 ~]$ sudo grep -r "barbican::db::mysql::password" /etc/puppet/hieradata /etc/puppet/hieradata/service_configs.json: "barbican::db::mysql::password": "seDJRsMNRrBdFryCmNUEFPPev",
barbican データベースをバックアップします。
[heat-admin@controller-0 ~]$ mysqldump -u barbican -p"seDJRsMNRrBdFryCmNUEFPPev" barbican > barbican_db_backup.sql
データベースのバックアップは /home/heat-adminに保存されます。
[heat-admin@controller-0 ~]$ ll total 36 -rw-rw-r--. 1 heat-admin heat-admin 36715 Jun 19 18:31 barbican_db_backup.sql
4.6.1.2.3. テストシークレットの削除
オーバークラウドで、以前に作成したシークレットを削除し、それらのシークレットが存在しないことを確認します。以下に例を示します。
(overcloud) [stack@undercloud-0 ~]$ openstack secret delete http://10.0.0.104:9311/v1/secrets/93f62cfd-e008-401f-be74-bf057c88b04a (overcloud) [stack@undercloud-0 ~]$ openstack secret delete http://10.0.0.104:9311/v1/secrets/f664b5cf-5221-47e5-9887-608972a5fefb (overcloud) [stack@undercloud-0 ~]$ openstack secret list (overcloud) [stack@undercloud-0 ~]$
4.6.1.2.4. データベースを復元します。
controller-0 ノードにログインした状態で以下の手順を実行します。
コントローラー上に
barbicanユーザーにデータベースを復元するためのアクセスを付与する barbican データベースがあることを確認します。[heat-admin@controller-0 ~]$ mysql -u barbican -p"seDJRsMNRrBdFryCmNUEFPPev" Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 3799 Server version: 10.1.20-MariaDB MariaDB Server Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> SHOW DATABASES; +--------------------+ | Database | +--------------------+ | barbican | | information_schema | +--------------------+ 2 rows in set (0.00 sec) MariaDB [(none)]> exit Bye [heat-admin@controller-0 ~]$
barbicanデータベースにバックアップファイルをリストアします。[heat-admin@controller-0 ~]$ sudo mysql -u barbican -p"seDJRsMNRrBdFryCmNUEFPPev" barbican < barbican_db_backup.sql [heat-admin@controller-0 ~]$
4.6.1.2.5. 復元プロセスの確認
オーバークラウドで、テストシークレットが正常に復元されたことを確認します。
(overcloud) [stack@undercloud-0 ~]$ openstack secret list +------------------------------------------------------------------------+------------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+ | Secret href | Name | Created | Status | Content types | Algorithm | Bit length | Secret type | Mode | Expiration | +------------------------------------------------------------------------+------------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+ | http://10.0.0.104:9311/v1/secrets/93f62cfd-e008-401f-be74-bf057c88b04a | testSecret | 2018-06-19T18:25:25+00:00 | ACTIVE | {u'default': u'text/plain'} | aes | 256 | opaque | cbc | None | | http://10.0.0.104:9311/v1/secrets/f664b5cf-5221-47e5-9887-608972a5fefb | swift_key | 2018-06-19T18:24:40+00:00 | ACTIVE | {u'default': u'application/octet-stream'} | aes | 256 | symmetric | ctr | None | +------------------------------------------------------------------------+------------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+ (overcloud) [stack@undercloud-0 ~]$
第5章 barbican Hardware Security Module(HSM)の統合
OpenStack Key Manager (Barbican) は Red Hat OpenStack Platform のシークレットマネージャーです。Barbican API とコマンドラインを使用して、OpenStack サービスの使用する証明書、キー、パスワードを一元管理することができます。barbican は現在、本書で説明されている以下のユースケースをサポートします。
- 対称暗号鍵: 中でも Block Storage (cinder) ボリュームの暗号化、一時ディスク暗号化、および Object Storage (Swift) の暗号化に使用されます。
- 非対称鍵および証明書: とりわけ glance イメージの署名および検証、octavia TLS 負荷分散
本リリースでは、barbican は Block Storage (cinder)、Networking (neutron) および Compute (nova) コンポーネントとの統合を提供します。
5.1. バックエンドの選択
シークレット (証明書、API キー、パスワードなど) は、Hardware Security Module (HSM) アプライアンスを含め、暗号化された Blob として Barbican データベースに保存することも、セキュアなストレージシステムに直接保存することもできます。
5.2. 暗号化された Blob
シンプルな crypto プラグインはデフォルトで有効になっており、単一の対称キーを使用してシークレットの Blob を暗号化します。このキーは、プレーンテキストで barbican.conf ファイルに保存されます。
5.3. ハードウェアセキュリティーモジュール (HSM) のサポート
PKCS#11 暗号化プラグインを使用して、サードパーティーのベンダーが生成した物理的なラックマウントアプライアンスである Hardware Security Module (HSM) にシークレットを保存できます。これらのシークレットは pKEK を使用して暗号化され、Barbican データベースにも保存されます。pKEK は暗号化され、HMAC 操作は HSM にも保管される MKEK キーおよび HMAC 鍵を使用して適用されます。
このガイドでは、Barbican を Atos および nCipher の特定の HSM アプライアンスと統合する方法を説明します。
以下の方法を使用して HSM と対話できます。
- PKCS#11 暗号プラグイン - PKCS#11 暗号化プラグインは、Barbican データベースに保存されているプロジェクト固有の鍵暗号鍵(KEK)でシークレットを暗号化します。これらのプロジェクト固有の KEK は、マスター KEK によって暗号化されます。PKEK を含む暗号化されたブロブは、HMAC キーによる HMAC 処理を受けます。これは HSM にも保存されます。すべての暗号化および復号化操作は、in-process メモリーではなく、HSM に置かれます。PKCS#11 プラグインは、PKCS#11 プロトコルを使用して HSM と通信します。暗号化はセキュアなハードウェアで実行され、プロジェクトごとに別の KEK が使用されるため、このオプションは単純な crypto プラグインよりも安全です。
-
KMIP プラグイン: Red Hat では、このアプローチに対応していないことに注意してください。Key Management Interoperability Protocol(KMIP)プラグインは、HSM などの KMIP が有効になっているデバイスと連携します。シークレットは、Barbican データベースの代わりにデバイスに直接保存されます。プラグインは、ユーザー名とパスワードを使用するか、
barbican.confファイルに保存されているクライアント証明書を使用してデバイスに対して認証することができます。 - Red Hat Certificate System(dogtag) - Red Hat Certificate System は、一般的な基準と、公開鍵インフラストラクチャー(PKI)の様々な側面を管理するための FIPS 認定セキュリティーフレームワークです。Key Recovery Authority(KRA)サブシステムは、シークレットをデータベースに暗号化された Blob として保存します。マスター暗号化キーは、ソフトウェアベースの Network Security Services(NSS)データベースまたは HSM のいずれかに保存されます。Red Hat Certificate System の詳細は、Red Hat Certificate System の製品ドキュメント を参照してください。
高可用性 (HA) オプション: Barbican サービスは Apache 内で実行され、高可用性に HAProxy を使用するように director により設定されます。バックエンド層の HA オプションは、使用するバックエンドによって異なります。たとえば、簡単な暗号化を使用する場合、すべての Barbican インスタンスには設定ファイル内に同じ暗号化キーがあり、単純な HA 設定が作成されます。
5.4. バックエンド間の移行
Barbican を使用すると、プロジェクトに異なるバックエンドを定義することができます。プロジェクトにマッピングが存在しない場合は、シークレットはグローバルのデフォルトバックエンドに保存されます。つまり、複数のバックエンドを設定することができますが、定義されたグローバルバックエンドは 1 つだけでなければなりません。異なるバックエンド用に提供された heat テンプレートには、各バックエンドをデフォルトとして設定するパラメーターが含まれます。
特定のバックエンドにシークレットを保存してから新規バックエンドに移行する場合には、グローバルのデフォルト (またはプロジェクト固有のバックエンド) として新しいバックエンドを有効にする間に、古いバックエンドを利用可能な状態にすることができます。その結果、古いシークレットは古いバックエンドで引き続き利用できます。
5.5. HSM アプライアンスとの統合
本章では、Red Hat OpenStack Platform デプロイメントを特定の HSM アプライアンスと統合する方法を説明します。また、考慮する必要のある一般的な操作手順についても説明します。
5.6. Barbican と Atos HSM の統合
本セクションでは、PKCS#11 バックエンドを Trustway Proteccio NetHSM アプライアンスに統合する方法を説明します。
5.7. 要件
- Red Hat OpenStack Platform 環境における作業用の Barbican デプロイメント
HSM の統合を計画して、以下の設定を director のデプロイメントに準備できるようにします。これらの値は
barbican-backend-pkcs11-atos.yaml（以下のセクションで説明）に入力されます。-
BarbicanPkcs11CryptoLogin- PKCS#11 ライブラリー(PIN)が使用するパスフレーズ。 インストール前に、ATOS の手順に従ってコントローラーのクライアント証明書を生成する必要があります。オーバークラウドノードがアクセスできる HTTP または FTP サーバーでクライアント証明書、サーバー証明書、および Atos クライアント ISO ファイルをホストします。この資料の一部は（クライアントキーなど）シークレットで、保護する必要があるものもあります。これを行うためにパスワードを使用する場合には、
http://user:pass@locationまたはftp://user:pass@locationとして場所を指定する必要があります。インストールプロセス中、director は Ansible スクリプトを実行してこれらのファイルを取得します。以下の値で使用されるファイルパスは、インストールプロセスでアクセスできる必要があります。-
atos_client_iso_location -
atos_client_cert_location -
atos_client_key_location -
atos_server_cert_location -
atos_client_working_dir -
atos_client_iso_name -
atos_hsm_ip_address
-
-
5.8. コントローラーの設定
この手順では、Ansible ロールを使用して Atos クライアントソフトウェアをコントローラーにダウンロードおよびインストールし、Atos 設定ファイルを変更して、事前定義された HSM IP および認証情報に追加します。
barbican-backend-pkcs11-atos.yamlという名前のOVERCLOUD_TEMPLATESに環境ファイルを作成し、HSM の設定情報を入力します。以下に例を示します。tripleo_heat_templates: - /usr/share/openstack-tripleo-heat-templates/environments/services/barbican.yaml - /usr/share/openstack-tripleo-heat-templates/environments/barbican-backend-pkcs11-atos.yaml custom_templates: parameter_defaults: SwiftEncryptionEnabled: true ComputeExtraConfig: nova::glance::verify_glance_signatures: true nova::compute::verify_glance_signatures: true BarbicanPkcs11CryptoLogin: 'sample string' BarbicanPkcs11CryptoSlotId: 1 BarbicanPkcs11CryptoGlobalDefault: true BarbicanPkcs11CryptoLibraryPath: '/usr/lib64/libnethsm.so' BarbicanPkcs11CryptoEncryptionMechanism: 'CKM_AES_CBC' BarbicanPkcs11CryptoHMACKeyType: 'CKK_GENERIC_SECRET' BarbicanPkcs11CryptoHMACKeygenMechanism: 'CKM_GENERIC_SECRET_KEY_GEN' BarbicanPkcs11CryptoMKEKLabel: 'barbican_mkek_5a' BarbicanPkcs11CryptoMKEKLength: 32 BarbicanPkcs11CryptoHMACLabel: 'barbican_hmac_5a' BarbicanPkcs11CryptoATOSEnabled: true BarbicanPkcs11CryptoEnabled: true ATOSVars: atos_client_working_dir: /tmp/atos_client_install atos_client_iso_location: https://your server/Proteccio1.09.03.iso atos_client_iso_name: Proteccio1.09.03.iso atos_client_cert_location: https://your server/proteccio_client.crt atos_client_key_location: https://your server/proteccio_client.key atos_server_cert_location: https://your server/192_168_11_13.crt atos_hsm_ip_address: 192.168.11.12 resource_registry: OS::TripleO::Services::BarbicanBackendPkcs11Crypto: /home/stack/tripleo-heat-templates/puppet/services/barbican backend-pkcs11-crypto.yaml-
BarbicanPkcs11CryptoGlobalDefaultおよびBarbicanPkcs11CryptoEnabled: これらのオプションは、PKCS#11 をグローバルのデフォルトバックエンドとして設定します。 -
BarbicanPkcs11CryptoMKEKLabel: HSM で生成される mKEK の名前を定義します。director はこのキーを使用して HSM にこのキーを作成します。この名前は新規インストールごとに一意となる必要があります。そうしないと、同じラベル名が使用されると競合が生じる可能性があります。 BarbicanPkcs11CryptoHMACLabel: HSM で生成された HMAC 鍵の名前を定義します。director はこのキーを使用して HSM にこのキーを作成します。注記デフォルトでは、HSM は最大 32 の同時接続を許可します。この数が超過すると、PKCS#11 クライアントからメモリーエラーが発生することが予想されます。以下に示すように、接続数を計算することができます。
-
各コントローラーには
barbican-apiと 1 つのbarbican-workerプロセスがあります。 -
各 Barbican API プロセスは
N個のApache ワーカーで実行されます (Nはデフォルトで CPU の数に設定されます)。 - 各ワーカーには HSM への 1 つの接続があります。
BarbicanWorkers: 各
barbican-workerプロセスにはデータベースへの接続が 1 つあり、この設定により API プロセスごとの Apache ワーカーの数を定義できます。デフォルトでは、これは CPU 数に一致します。この設定は、barbican::wsgi::apache::workers を設定します。Barbican ワーカーの数は、barbican.confのパラメーターqueue/asynchronous_workersによって制御されます。デフォルトは1です。現在、この値を管理する tripleO パラメーターはありません。たとえば、3 つのコントローラーがあり、それぞれに 32 コアがある場合、それぞれのコントローラーの Barbican API は 32 Apache ワーカーを使用します（
BarbicanWorkersはデフォルトで32に設定されます）。そのため、1 つのコントローラーは利用可能な 32 HSM 接続をすべて消費します。この競合を回避するには、各ノードに設定された Barbican Apache ワーカーの数を制限します。この例では、BarbicanWorkersを10に設定すると、3 つのコントローラーはすべて HSM への 10 個の同時接続を行うことができます。-
各コントローラーには
-
-
既存の
openstack overcloud deployコマンドへのパスを追加して、スクリプトを再実行します。
5.8.1. HSM 接続のテスト
テストシークレットを作成します。以下に例を示します。
$ openstack secret store --name testSecret --payload 'TestPayload' +---------------+------------------------------------------------------------------------------------+ | Field | Value | +---------------+------------------------------------------------------------------------------------+ | Secret href | https://192.168.123.163/key-manager/v1/secrets/4cc5ffe0-eea2-449d-9e64-b664d574be53 | | Name | testSecret | | Created | None | | Status | None | | Content types | None | | Algorithm | aes | | Bit length | 256 | | Secret type | opaque | | Mode | cbc | | Expiration | None | +---------------+------------------------------------------------------------------------------------+
作成したシークレットのペイロードを取得します。
openstack secret get https://192.168.123.163/key-manager/v1/secrets/4cc5ffe0-eea2-449d-9e64-b664d574be53 --payload +---------+-------------+ | Field | Value | +---------+-------------+ | Payload | TestPayload | +---------+-------------+
5.9. Barbican と nCipher nShield Connect XC の統合
本セクションでは、PKCS#11 バックエンドを nCipher nShield Connect XC 暗号化バックエンドと統合する方法を説明します。
- Red Hat OpenStack Platform 環境における作業用の Barbican デプロイメント
HSM 統合を計画して、以下の設定を Ansible デプロイメントに準備できるようにします。これらの値は
barbican-backend-pkcs11-thales.yaml（以下のセクションで説明）に入力されます。-
thales_client_working_dirおよびthales_client_tarball_location- nCipher nShield Connect XC クライアントソフトウェアを、インストール時にアクセス可能な場所にマウントする必要があります。これらの値は、ファイルの場所とファイル名によって異なります。 -
thales_client_working_dir- クライアントソフトウェアを展開すると、ソフトウェアの場所がこの値を変更する可能性があります。 -
thales_km_data_locationとthales_km_data_tarball_name: これらはセキュリティー世界のデータを示し、アクセス可能な場所にマウントする必要があります。この資料は秘密であり、保護する必要があります。これを行うためにパスワードを使用する場合には、http://user:pass@locationまたはftp://user:pass@locationとして場所を指定する必要があります。インストールプロセス中、director は Ansible スクリプトを実行してこれらのファイルを取得します。以下の値で使用されるファイルパスは、インストールプロセスでアクセスできる必要があります。 -
thales_rfs_key- RFS サーバーは、設定を更新するコマンドへのログインおよび実行権限を持つユーザーにアクセスできる必要があります。これにより、コントローラーを HSM クライアントとして追加できます。Ansible スクリプトは、提供される秘密鍵を使用して rfs サーバーに ssh を実行します。公開鍵は、最初に認証キーとして rfs サーバーにアップロードする必要があります。
-
5.10. コントローラーの設定
この手順では、Ansible ロールを使用してコントローラーに nCipher クライアントソフトウェアをダウンロードしてインストールし、次に nCipher 設定ファイルを変更して、事前定義された HSM IP および認証情報に追加します。
barbican-backend-pkcs11-thales.yamlという名前のOVERCLOUD_TEMPLATESに環境ファイルを作成し、nCipher nShield Connect XC の設定情報を入力します。以下に例を示します。tripleo_heat_templates: - /usr/share/openstack-tripleo-heat-templates/environments/services/barbican.yaml - /usr/share/openstack-tripleo-heat-templates/environments/barbican-backend-pkcs11-thales.yaml custom_templates: parameter_defaults: SwiftEncryptionEnabled: true ComputeExtraConfig: nova::glance::verify_glance_signatures: true nova::compute::verify_glance_signatures: true BarbicanPkcs11CryptoLogin: 'sample string' BarbicanPkcs11CryptoSlotId: '492971158' BarbicanPkcs11CryptoGlobalDefault: true BarbicanPkcs11CryptoLibraryPath: '/opt/nfast/toolkits/pkcs11/libcknfast.so' BarbicanPkcs11CryptoEncryptionMechanism: 'CKM_AES_CBC' BarbicanPkcs11CryptoHMACKeyType: 'CKK_SHA256_HMAC' BarbicanPkcs11CryptoHMACKeygenMechanism: 'CKM_NC_SHA256_HMAC_KEY_GEN' BarbicanPkcs11CryptoMKEKLabel: 'barbican_mkek_10' BarbicanPkcs11CryptoMKEKLength: '32' BarbicanPkcs11CryptoHMACLabel: 'barbican_hmac_10' BarbicanPkcs11CryptoThalesEnabled: true BarbicanPkcs11CryptoEnabled: true ThalesVars: thales_client_working_dir: /tmp/thales_client_install thales_client_tarball_location: https://your server/CipherTools-linux64-dev-12.40.2.tgz thales_client_tarball_name: CipherTools-linux64-dev-12.40.2.tgz thales_client_path: linux/libc6_11/amd64/nfast thales_client_uid: 42481 thales_client_gid: 42481 thales_km_data_location: https://your server/kmdata_post_card_creation.tar.gz thales_km_data_tarball_name: kmdata_post_card_creation.tar.gz thales_hsm_ip_address: 192.168.10.10 thales_rfs_server_ip_address: 192.168.10.11 thales_hsm_config_location: hsm-C90E-02E0-D947 thales_rfs_user: root thales_rfs_key: | -----BEGIN RSA PRIVATE KEY----- Sample private key -----END RSA PRIVATE KEY----- resource_registry: OS::TripleO::Services::BarbicanBackendPkcs11Crypto: /home/stack/tripleo-heat-templates/puppet/services/barbican-backend-pkcs11-crypto.yaml-
BarbicanPkcs11CryptoGlobalDefaultおよびBarbicanPkcs11CryptoEnabled: これらのオプションは、PKCS#11 をグローバルのデフォルトバックエンドとして設定します。 -
BarbicanPkcs11CryptoMKEKLabel: HSM で生成される mKEK の名前を定義します。director はこのキーを使用して HSM にこのキーを作成します。 BarbicanPkcs11CryptoHMACLabel: HSM で生成された HMAC 鍵の名前を定義します。director はこのキーを使用して HSM にこのキーを作成します。-
既存の
openstack overcloud deployコマンドへのパスを追加して、スクリプトを再実行します。
-
既存の
-
5.10.1. HSM 接続のテスト
テストシークレットを作成します。以下に例を示します。
$ openstack secret store --name testSecret --payload 'TestPayload' +---------------+------------------------------------------------------------------------------------+ | Field | Value | +---------------+------------------------------------------------------------------------------------+ | Secret href | https://192.168.123.163/key-manager/v1/secrets/4cc5ffe0-eea2-449d-9e64-b664d574be53 | | Name | testSecret | | Created | None | | Status | None | | Content types | None | | Algorithm | aes | | Bit length | 256 | | Secret type | opaque | | Mode | cbc | | Expiration | None | +---------------+------------------------------------------------------------------------------------+
作成したシークレットのペイロードを取得します。
openstack secret get https://192.168.123.163/key-manager/v1/secrets/4cc5ffe0-eea2-449d-9e64-b664d574be53 --payload +---------+-------------+ | Field | Value | +---------+-------------+ | Payload | TestPayload | +---------+-------------+
5.11. Barbican と HSM 間の TLS アクティビティーの確認
barbican は、ベンダーが提供する PKCS#11 ライブラリーを介して HSM と通信します。たとえば、ATOS Proteccio HSM の場合、proteccio.rc ファイルを設定することで、HSM クライアントが TLS を使用して HSM と通信するように設定できます。
Atos HSM の場合、CA、サーバー証明書、およびキーを含むファイルがコントローラーにあり、barbican ユーザーによって所有されます。barbican ユーザーはコントローラー上に存在せず、Barbican コンテナーで定義される barbican ユーザーであることに注意してください。これにより、これはファイルに数字の識別子として示されます。ファイルは barbican ユーザーの読み取り可能でなければなりません(0400)。これらのファイルは、Barbican コンテナーによってバインドマウントされます。
nCipher nShield Connect XC については、HSM とクライアントソフトウェア間の pkcs#11 トランザクションの追加ログを表示するには、/opt/nfast/cknfastrc に以下のエントリーを追加します。
CKNFAST_DEBUG=9 CKNFAST_DEBUGFILE=/tmp/hsm_log.txt
5.12. キーストレージに関する考慮事項
Barbican MKEK および HMAC キーは、ベンダーの PKCS#11 ライブラリーを使用して HSM と通信する Barbican ユーティリティーを使用して生成されます。したがって、MKEK キーおよび HMAC キーは HSM で生成され、HSM が残されることはありません。
director ベースのデプロイメントでは、これらのユーティリティーは最初のコントローラー上のコンテナー内で実行されます。アンダークラウドはこのプロセスには関与しません。
5.13. キーのローテーション
director の更新を使用して、MKEK キーおよび HMAC キーをローテーションできます。
MKEK と HMAC には同じキータイプです。これは Barbican の制限であり、現時点では後で対処されることが予想されます。
キーをローテーションするには、デプロイメントの環境ファイルに以下のパラメーターを追加します。
BarbicanPkcs11CryptoRewrapKeys: true
たとえば、ラベルが以下のようであれば、MKEK キーおよび HMAC 鍵のラベルを変更します。
BarbicanPkcs11CryptoMKEKLabel: 'barbican_mkek_10' BarbicanPkcs11CryptoHMACLabel: 'barbican_hmac_10'値をインクリメントしてラベルを変更できます。
BarbicanPkcs11CryptoMKEKLabel: 'barbican_mkek_11' BarbicanPkcs11CryptoHMACLabel: 'barbican_hmac_11'注記HMAC 鍵タイプは変更しないでください。
-
director を使用して再デプロイし、更新を適用します。director は、MKEK および HMAC のラベルが付けられたキーが存在するかどうかを確認してから、作成します。また、
BarbicanPkcs11CryptoRewrapKeysパラメーターがTrueに設定されていると、director はbarbican-manage hsm pkek_rewrapを呼び出して、既存のすべての pKEK を再度ラップします。
5.14. Barbican および HSM 向けバックアップのプランニング
このセクションでは、Barbican および HSM バックアップストラテジーを計画する際に考慮すべきコンポーネントについて説明します。
- barbican シークレット: これらはデータベースに保存され、定期的にバックアップする必要があります。
- MKEK キーおよび HMAC キー: これらは HSM に保存されます。推奨されるプラクティスについては、HSM ベンダーについて確認してください。
- HSM クライアント証明書およびキー： これらはコントローラーにあり、コントローラーのファイルバックアップ手順に含める必要があります。これらのファイルは機密の認証情報である点に注意してください。
- barbican 設定ファイル
第6章 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変更は、コンテナーを再起動した後に適用されます。
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設定を使用するように指定します。注記暗号化されたボリュームを作成するユーザーに、プロジェクトで
creatorbarbican ロールがあることを確認します。詳細は、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 バックエンドに自動的にアップロードされます。
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 | +------------------------------------------------------------------------------------+------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+新規ボリュームを既存のインスタンスにアタッチします。以下に例を示します。
$ openstack server add volume testInstance Encrypted-Test-Volume
その後、ボリュームはゲストオペレーティングシステムに表示され、組み込みツールを使用してマウントできます。
6.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 テーブルの鍵を移行します。
6.1.1. 移行手順の概要
- barbican サービスをデプロイします。
creatorロールを cinder サービスに追加します。以下に例を示します。#openstack role create creator #openstack role add --user cinder creator --project service
-
cinder-volumeおよびcinder-backupサービスを再起動します。 -
cinder-volumeおよびcinder-backupは、移行プロセスを自動的に開始します。 -
移行が完了したことを示すメッセージのログを監視し、ボリュームが
ConfKeyManagerオールゼロ暗号鍵 ID を使用していないことを確認します。 -
cinder.confおよびnova.confからfixed_keyオプションを削除します。この設定が設定されているノードを判別する必要があります。 -
cinder サービスから
creatorロールを削除します。
6.1.2. 動作の違い
barbican が管理する暗号化ボリュームは、ConfKeyManager を使用するボリュームとは異なる動作をします。
- 現在、barbican シークレットの所有権を転送することができないため、暗号化されたボリュームの所有権は移動できません。
- barbican は、シークレットの読み取りと削除ができるかより厳しいので、一部の cinder ボリューム操作に影響を及ぼす可能性があります。たとえば、別のユーザーのボリュームの割り当て、割り当て解除、または削除はできません。
6.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-volumeはcinder-backupに移行するバックアップがまだあるかどうかを認識し、cinder-backupはcinder-volumeサービスに移行するボリュームがあるかどうかを認識します。各ホストは自身のボリュームのみを移行しますが、概要メッセージは、ボリュームの移行が依然として必要なかどうかについて、グローバルアセスメントに基づいています。これにより、すべてのボリュームの移行が完了しているかどうかを確認できます。確認が終わったら、
fixed_keyの設定をcinder.confおよびnova.confから削除します。詳細は、Clean up the fixed keys のセクションを参照してください。
6.1.4. 移行プロセスのトラブルシューティング
6.1.4.1. ロール割り当て
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サービスを再起動します。
その結果、次の移行試行に成功します。
6.1.5. 固定キーの削除
最近 encryption_key_id は、Queens リリースの一環として、Backup テーブルにのみ追加されました。その結果、暗号化されたボリュームの既存のバックアップが存在する可能性があります。すべてがゼロの encryption_key_id はバックアップ自体に保存されますが、Backup データベースには表示されません。そのため、移行プロセスでは、暗号化されたボリュームのバックアップが存在し、all-zero の ConfKeyMgr キー ID に依存するかを知ることはできません。
キー ID を barbican に移行すると、固定キーが設定ファイル内に残ります。fixed_key の値が .conf ファイルで暗号化されないため、一部のユーザーにセキュリティー上の問題が発生することがあります。これに対処するには、nova および cinder の設定から fixed_key の値を手動で削除します。ただし、最初にログファイルの出力が完了してから、続行する前にログファイルの出力を確認します。この値がまだ依存するディスクにはアクセスできないためです。
既存の
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
第7章 保存されている swift オブジェクトの暗号化
デフォルトでは、オブジェクトストレージにアップロードされるオブジェクトは暗号化されずに保存されます。したがって、ファイルシステムからオブジェクトに直接アクセスすることが可能です。このため、ディスクを破棄する前に適切に消去しなかった場合には、セキュリティーリスクとなってしまいます。barbican を有効にすると、Object Storage サービス (swift) は、保管されている (at-rest) オブジェクトを透過的に暗号化および復号化できます。at-rest 暗号化は、in-transit 暗号化とは異なり、ディスクに保管されている間にオブジェクトが暗号化されることを指します。
Swift はこれらの暗号化タスクを透過的に実行し、オブジェクトは swift にアップロードされる際には自動的に暗号化され、ユーザーに提供される際には自動的に復号化されます。この暗号化と復号化は、Barbican に保管されている同じ (対称) キーを使用して処理されます。
データが暗号化された状態で保存されているので、暗号化を有効にし、swift クラスターにデータを追加した後には暗号化を無効にすることはできません。その結果、同じキーで暗号化を再度有効にするまで、暗号化が無効になっている場合は、データは読み取りできなくなります。
7.1. swift 用の at-rest 暗号化の有効化
-
環境ファイルに
SwiftEncryptionEnabled: Trueを追加し、/home/stack/overcloud_deploy.shを使用してopenstack overcloud deployを再実行することで、swift 暗号化機能を有効にすることができます。「Barbican のインストール」の章で説明されているように、barbican を有効にする必要があります。 swift が at-rest 暗号化を使用するように設定されていることを確認します。
$ crudini --get /var/lib/config-data/puppet-generated/swift/etc/swift/proxy-server.conf pipeline-main pipeline pipeline = catch_errors healthcheck proxy-logging cache ratelimit bulk tempurl formpost authtoken keystone staticweb copy container_quotas account_quotas slo dlo versioned_writes kms_keymaster encryption proxy-logging proxy-server
結果には、
encryptionのエントリーが含まれている必要があります。
第8章 glance イメージの検証
Barbican を有効にした後に、Image サービス (glance) を設定して、アップロードしたイメージが改ざんされていないことを確認できます。この実装では、イメージは最初に barbican に保管されるキーで署名されます。その後、イメージは、付随する署名情報と共に glance にアップロードされます。その結果、各使用前にイメージの署名が検証され、署名が一致しない場合、インスタンスのビルドプロセスに失敗しています。
barbican と glance の統合とは、openssl コマンドを秘密鍵と共に使用してアップロードする前に glance イメージを署名できることを意味します。
8.1. glance イメージ検証の有効化
環境ファイルで、VerifyGlanceSignatures: True の設定でイメージの検証を有効にします。この設定を有効にするには、openstack overcloud deploy コマンドを再実行する必要があります。
glance イメージの検証が有効化されていることを確認するには、オーバークラウドのコンピュートノードで以下のコマンドを実行します。
$ sudo crudini --get /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf glance verify_glance_signatures
イメージおよび Compute サービスのバックエンドに Ceph を使用する場合、CoW クローンが作成されます。したがって、イメージ署名の検証は実行できません。
8.2. イメージの検証
検証用の glance イメージを設定するには、以下の手順を実施します。
glance が barbican を使用するように設定されていることを確認します。
$ sudo crudini --get /var/lib/config-data/puppet-generated/glance_api/etc/glance/glance-api.conf key_manager backend castellan.key_manager.barbican_key_manager.BarbicanKeyManager
秘密鍵を生成して、必要な形式に変換します。
openssl genrsa -out private_key.pem 1024 openssl rsa -pubout -in private_key.pem -out public_key.pem openssl req -new -key private_key.pem -out cert_request.csr openssl x509 -req -days 14 -in cert_request.csr -signkey private_key.pem -out x509_signing_cert.crt
barbican のシークレットストアにキーを追加します。
$ source ~/overcloudrc $ openstack secret store --name signing-cert --algorithm RSA --secret-type certificate --payload-content-type "application/octet-stream" --payload-content-encoding base64 --payload "$(base64 x509_signing_cert.crt)" -c 'Secret href' -f value https://192.168.123.170:9311/v1/secrets/5df14c2b-f221-4a02-948e-48a61edd3f5b
注記後のステップで使用するために、生成された UUID を記録します。以下の例では、証明書の UUID は
5df14c2b-f221-4a02-948e-48a61edd3f5bです。private_key.pemを使用してイメージに署名し、.signatureファイルを生成します。以下に例を示します。$ openssl dgst -sha256 -sign private_key.pem -sigopt rsa_padding_mode:pss -out cirros-0.4.0.signature cirros-0.4.0-x86_64-disk.img
作成される
.signatureファイルを base64 形式に変換します。$ base64 -w 0 cirros-0.4.0.signature > cirros-0.4.0.signature.b64
後続のコマンドで base64 値を変数に読み込みます。
$ cirros_signature_b64=$(cat cirros-0.4.0.signature.b64)
署名付きイメージを glance にアップロードします。
img_signature_certificate_uuidの場合、前のステップで barbican にアップロードした署名キーの UUID を指定する必要があります。openstack image create \ --container-format bare --disk-format qcow2 \ --property img_signature="$cirros_signature_b64" \ --property img_signature_certificate_uuid="5df14c2b-f221-4a02-948e-48a61edd3f5b"\ --property img_signature_hash_method="SHA-256" \ --property img_signature_key_type="RSA-PSS" cirros_0_4_0_signed \ --file cirros-0.4.0-x86_64-disk.img +--------------------------------+----------------------------------------------------------------------------------+ | Property | Value | +--------------------------------+----------------------------------------------------------------------------------+ | checksum | None | | container_format | bare | | created_at | 2018-01-23T05:37:31Z | | disk_format | qcow2 | | id | d3396fa0-2ea2-4832-8a77-d36fa3f2ab27 | | img_signature | lcI7nGgoKxnCyOcsJ4abbEZEpzXByFPIgiPeiT+Otjz0yvW00KNN3fI0AA6tn9EXrp7fb2xBDE4UaO3v | | | IFquV/s3mU4LcCiGdBAl3pGsMlmZZIQFVNcUPOaayS1kQYKY7kxYmU9iq/AZYyPw37KQI52smC/zoO54 | | | zZ+JpnfwIsM= | | img_signature_certificate_uuid | ba3641c2-6a3d-445a-8543-851a68110eab | | img_signature_hash_method | SHA-256 | | img_signature_key_type | RSA-PSS | | min_disk | 0 | | min_ram | 0 | | name | cirros_0_4_0_signed | | owner | 9f812310df904e6ea01e1bacb84c9f1a | | protected | False | | size | None | | status | queued | | tags | [] | | updated_at | 2018-01-23T05:37:31Z | | virtual_size | None | | visibility | shared | +--------------------------------+----------------------------------------------------------------------------------+
glance のイメージ検証のアクティビティーを Compute ログで表示することができます。
/var/log/containers/nova/nova-compute.logたとえば、インスタンスの起動時に以下のエントリーが表示されるはずです。2018-05-24 12:48:35.256 1 INFO nova.image.glance [req-7c271904-4975-4771-9d26-cbea6c0ade31 b464b2fd2a2140e9a88bbdacf67bdd8c a3db2f2beaee454182c95b646fa7331f - default default] Image signature verification succeeded for image d3396fa0-2ea2-4832-8a77-d36fa3f2ab27
第9章 ボリュームの作成に使用されるイメージの検証
Block Storage サービス (cinder) は、イメージの作成時に、ダウンロードされたイメージの署名を自動的に検証します。署名は、イメージがボリュームに書き込まれる前に検証されます。
パフォーマンスを向上させるために、Block Storage Image-Volume キャッシュを使用して、新規ボリュームを作成するための検証済みイメージを保存できます。詳細は、『 ストレージガイド 』の「 Image-Volume キャッシュの設定および有効化 」を参照してください。
cinder イメージの署名の検証は、Red Hat Ceph Storage または RBD ボリュームでは動作しません。
9.1. 新規ボリュームでイメージ署名の検証
この手順では、署名済みイメージから作成されたボリューム署名を検証する方法を説明します。
- コントローラーノードにログインします。
Volumeログ/var/log/containers/cinder/cinder-volume.logで cinder のイメージ検証アクティビティーを表示します。たとえば、インスタンスの起動時に以下のエントリーが表示されるはずです。
2018-05-24 12:48:35.256 1 INFO cinder.image.image_utils [req-7c271904-4975-4771-9d26-cbea6c0ade31 b464b2fd2a2140e9a88bbdacf67bdd8c a3db2f2beaee454182c95b646fa7331f - default default] Image signature verification succeeded for image d3396fa0-2ea2-4832-8a77-d36fa3f2ab27
別の方法では、openstack volume list および cinder volume show コマンドを使用できます。
-
openstack volume listコマンドを使用して、ボリューム ID を見つけます。 コンピュートノードで
cinder volume showコマンドを実行します。cinder volume show <VOLUME_ID>
volume_image_metadataセクションでsignature verified : Trueの行を探します。$ cinder show d0db26bb-449d-4111-a59a-6fbb080bb483 +--------------------------------+-------------------------------------------------+ | Property | Value | +--------------------------------+-------------------------------------------------+ | attached_servers | [] | | attachment_ids | [] | | availability_zone | nova | | bootable | true | | consistencygroup_id | None | | created_at | 2018-10-12T19:04:41.000000 | | description | None | | encrypted | True | | id | d0db26bb-449d-4111-a59a-6fbb080bb483 | | metadata | | | migration_status | None | | multiattach | False | | name | None | | os-vol-host-attr:host | centstack.localdomain@nfs#nfs | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | 1a081dd2505547f5a8bb1a230f2295f4 | | replication_status | None | | size | 1 | | snapshot_id | None | | source_volid | None | | status | available | | updated_at | 2018-10-12T19:05:13.000000 | | user_id | ad9fe430b3a6416f908c79e4de3bfa98 | | volume_image_metadata | checksum : f8ab98ff5e73ebab884d80c9dc9c7290 | | | container_format : bare | | | disk_format : qcow2 | | | image_id : 154d4d4b-12bf-41dc-b7c4-35e5a6a3482a | | | image_name : cirros-0.3.5-x86_64-disk | | | min_disk : 0 | | | min_ram : 0 | | | signature_verified : False | | | size : 13267968 | | volume_type | nfs | +--------------------------------+-------------------------------------------------+
