チェックリスト

Check-Block-01: 設定ファイルのユーザー/グループの所有権が root/cinder に設定されていますか?

Configuration files contain critical parameters and information required for smooth functioning of the component. If an unprivileged user, either intentionally or accidentally, modifies or deletes any of the parameters or the file itself then it would cause severe availability issues resulting in a denial of service to the other end users. Thus user ownership of such critical configuration files must be set to root and group ownership must be set to cinder. Additionally, the containing directory should have the same ownership to ensure that new files are owned correctly.

以下のコマンドを実行します。

$ stat -L -c "%U %G" /etc/cinder/cinder.conf | egrep "root cinder"
$ stat -L -c "%U %G" /etc/cinder/api-paste.ini | egrep "root cinder"
$ stat -L -c "%U %G" /etc/cinder/policy.json | egrep "root cinder"
$ stat -L -c "%U %G" /etc/cinder/rootwrap.conf | egrep "root cinder"
$ stat -L -c "%U %G" /etc/cinder | egrep "root cinder"

成功: これらのすべての設定ファイルのユーザーおよびグループ所有者がそれぞれ root と cinder に設定されている場合。上のコマンドは root cinder を表示します。

失敗: 上のコマンドが、ユーザー所有者とグループ所有者として何も返さない場合。ユーザーが root 以外に、グループが cinder 以外に設定されている可能性があります。

Check-Block-02: 設定ファイルに厳しいパーミッションが設定されていますか?

Similar to the previous check, we recommend setting strict access permissions for such configuration files.

以下のコマンドを実行します。

$ stat -L -c "%a" /etc/cinder/cinder.conf
$ stat -L -c "%a" /etc/cinder/api-paste.ini
$ stat -L -c "%a" /etc/cinder/policy.json
$ stat -L -c "%a" /etc/cinder/rootwrap.conf
$ stat -L -c "%a" /etc/cinder

A broader restriction is also possible: if the containing directory is set to 750, the guarantee is made that newly created files inside this directory would have the desired permissions.

Pass: If permissions are set to 640 or stricter, or the containing directory is set to 750. The permissions of 640/750 translates into owner r/w, group r, and no rights to others i.e. "u=rw,g=r,o=". Note that with Check-Block-01: 設定ファイルのユーザー/グループの所有権が root/cinder に設定されていますか? and permissions set to 640, root has read/write access and cinder has read access to these configuration files. The access rights can also be validated using the following command. This command will only be available on your system if it supports ACLs.

$ getfacl --tabular -a /etc/cinder/cinder.conf
getfacl: Removing leading '/' from absolute path names
# file: etc/cinder/cinder.conf
USER   root  rw-
GROUP  cinder  r--
mask         r--
other        ---

失敗: パーミッションが 640 より緩くなっている場合。

Check-Block-03: 認証に keystone を使用していますか?

注釈

This item only applies to OpenStack releases Rocky and before as auth_strategy was deprecated in Stein.

OpenStack supports various authentication strategies like noauth, keystone etc. If the 'noauth' strategy is used then the users could interact with OpenStack services without any authentication. This could be a potential risk since an attacker might gain unauthorized access to the OpenStack components. Thus we strongly recommend that all services must be authenticated with keystone using their service accounts.

成功: /etc/cinder/cinder.conf の [DEFAULT] にある auth_strategy が keystone に設定されている場合。

失敗: [DEFAULT] にある auth_strategy パラメーターの値が noauth に設定されている場合。

Check-Block-04: 認証に TLS を有効化していますか?

OpenStack のコンポーネントは、さまざまなプロトコルを使用して、相互に通信しています。通信が重要な秘密情報を取り扱っているかもしれません。攻撃者は、秘密情報にアクセスするために、通信経路を盗聴しようとしているかもしれません。そのため、すべてのコンポーネントが、安全な通信プロトコルを使用して、相互に通信する必要があります。

Pass: If value of parameter www_authenticate_uri under [keystone_authtoken] section in /etc/cinder/cinder.conf is set to Identity API endpoint starting with https:// and value of parameter insecure under the same [keystone_authtoken] section in the same /etc/cinder/cinder.conf is set to False.

Fail: If value of parameter www_authenticate_uri under [keystone_authtoken] section in /etc/cinder/cinder.conf is not set to Identity API endpoint starting with https:// or value of parameter insecure under the same [keystone_authtoken] section in the same /etc/cinder/cinder.conf is set to True.

Check-Block-05: cinder が TLS を用いて nova と通信していますか?

OpenStack のコンポーネントは、さまざまなプロトコルを使用して、相互に通信しています。通信が重要な秘密情報を取り扱っているかもしれません。攻撃者は、秘密情報にアクセスするために、通信経路を盗聴しようとしているかもしれません。そのため、すべてのコンポーネントが、安全な通信プロトコルを使用して、相互に通信する必要があります。

成功: /etc/cinder/cinder.conf の [DEFAULT] にある nova_api_insecure が False に設定されている場合。

失敗: /etc/cinder/cinder.conf の [DEFAULT] にある nova_api_insecure が True に設定されている場合。

Check-Block-06: cinder が TLS を用いて glance と通信していますか?

Similar to previous check (Check-Block-05: cinder が TLS を用いて nova と通信していますか?), we recommend that all components communicate with each other using a secured communication protocol.

Pass: If value of parameter glance_api_insecure under [DEFAULT] section in /etc/cinder/cinder.conf is set to False and value of parameter glance_api_servers is set to a value starting with https://.

Fail: If value of parameter glance_api_insecure under [DEFAULT] section in /etc/cinder/cinder.conf is set to True or the value of parameter glance_api_servers is set to a value that does not start with https://.

Check-Block-07: NAS が安全な環境で運用されていますか?

Cinder supports an NFS driver which works differently than a traditional block storage driver. The NFS driver does not actually allow an instance to access a storage device at the block level. Instead, files are created on an NFS share and mapped to instances, which emulates a block device. Cinder supports secure configuration for such files by controlling the file permissions when cinder volumes are created. Cinder configuration can also control whether file operations are run as the root user or the current OpenStack process user.

Pass: If value of parameter nas_secure_file_permissions under [DEFAULT] section in /etc/cinder/cinder.conf is set to auto. When set to auto, a check is done during cinder startup to determine if there are existing cinder volumes, no volumes will set the option to True, and use secure file permissions. The detection of existing volumes will set the option to False, and use the current insecure method of handling file permissions. If value of parameter nas_secure_file_operations under [DEFAULT] section in /etc/cinder/cinder.conf is set to auto. When set to "auto", a check is done during cinder startup to determine if there are existing cinder volumes, no volumes will set the option to True, be secure and do NOT run as the root user. The detection of existing volumes will set the option to False, and use the current method of running operations as the root user. For new installations, a "marker file" is written so that subsequent restarts of cinder will know what the original determination had been.

Fail: If value of parameter nas_secure_file_permissions under [DEFAULT] section in /etc/cinder/cinder.conf is set to False and if value of parameter nas_secure_file_operations under [DEFAULT] section in /etc/cinder/cinder.conf is set to False.

Check-Block-08: リクエストのボディーの最大サイズがデフォルト (114688) に設定されていますか?

If the maximum body size per request is not defined, the attacker can craft an arbitrary osapi request of large size causing the service to crash and finally resulting in Denial Of Service attack. Assigning the maximum value ensures that any malicious oversized request gets blocked ensuring continued availability of the service.

成功: /etc/cinder/cinder.conf の [DEFAULT] にある osapi_max_request_body_size が False に設定されている場合、または /etc/cinder/cinder.conf の [oslo_middleware] セクションの下にある max_request_body_size パラメーターの値が 114688 に設定されている場合。

失敗: /etc/cinder/cinder.conf の [DEFAULT] にある osapi_max_request_body_size が False に設定されていない場合、または /etc/cinder/cinder.conf の [oslo_middleware] セクションの下にある max_request_body_size パラメーターの値が 114688 に設定されていない場合。

Check-Block-09: Is the volume encryption feature enabled?

Unencrypted volume data makes volume-hosting platforms especially high-value targets for attackers, as it allows the attacker to read the data for many different VMs. In addition, the physical storage medium could be stolen, remounted, and accessed from a different machine. Encrypting volume data mitigates these risks and provides defense-in-depth to volume-hosting platforms. Block Storage (cinder) is able to encrypt volume data before it is written to disk, and we recommend that the volume encryption feature is enabled. See the Volume Encryption section of the Openstack Cinder Service Configuration documentation for instructions.

Pass: If 1) the value of parameter backend under the [key_manager] section in /etc/cinder/cinder.conf is set, 2) the value of parameter backend under [key_manager] in /etc/nova/nova.conf is set, and 3) if the instructions in the documentation referenced above are properly followed.

To verify further, perform these steps after completing the volume encryption setup and creating the volume-type for LUKS as described in the documentation referenced above.

  1. Create a VM:

    $ openstack server create --image cirros-0.3.1-x86_64-disk --flavor m1.tiny TESTVM

  2. Create an encrypted volume and attach it to your VM:

    $ openstack volume create --size 1 --type LUKS 'encrypted volume'
$ openstack volume list
$ openstack server add volume --device /dev/vdb TESTVM 'encrypted volume'

  3. On the VM, send some text to the newly attached volume and synchronize it:

    # echo "Hello, world (encrypted /dev/vdb)" >> /dev/vdb
# sync && sleep 2

  4. On the system hosting cinder volume services, synchronize to flush the I/O cache then test to see if your string can be found:

    # sync && sleep 2
# strings /dev/stack-volumes/volume-* | grep "Hello"

The search should not return the string written to the encrypted volume.

Fail: If value of parameter backend under [key_manager] section in /etc/cinder/cinder.conf is not set, or if the value of parameter backend under [key_manager] section in /etc/nova/nova.conf is not set, or if the instructions in the documentation referenced above are not properly followed.