システムデザインガイド


Red Hat Enterprise Linux 8

RHEL 8 システムの設計

Red Hat Customer Content Services

概要

このコンテンツでは、Red Hat Enterprise Linux 8 の使用を開始する方法について説明します。Red Hat Enterprise Linux テクノロジーの機能と制限については、https://access.redhat.com/articles/rhel-limits を参照してください。

Red Hat ドキュメントへのフィードバック (英語のみ)

Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。

Jira からのフィードバック送信 (アカウントが必要)

  1. Jira の Web サイトにログインします。
  2. 上部のナビゲーションバーで Create をクリックします。
  3. Summary フィールドにわかりやすいタイトルを入力します。
  4. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
  5. ダイアログの下部にある Create をクリックします。

パート I. インストールの設計

第1章 RHEL システムイメージのカスタマイズ

1.1. RHEL Image Builder の説明

システムをデプロイするには、システムイメージを作成します。RHEL システムイメージを作成するには、RHEL Image Builder ツールを使用します。RHEL Image Builder を使用することで、RHEL のカスタマイズされたシステムイメージを作成できます。これには、クラウドプラットフォームへのデプロイメント用に準備されたシステムイメージが含まれます。RHEL Image Builder は、各出力タイプのセットアップの詳細を自動的に処理するため、手動でイメージを作成する方法よりも使いやすく、作業が高速です。RHEL Image Builder の機能には、composer-cli ツールのコマンドラインインターフェイス、または RHEL Web コンソールのグラフィカルユーザーインターフェイスを使用してアクセスできます。

注記

RHEL 8.3 以降では、osbuild-composer バックエンドが lorax-composer に取って代わります。新しいサービスには、イメージビルド向けの REST API が含まれます。

1.1.1. RHEL Image Builder の用語

RHEL Image Builder は次の概念を使用します。

ブループリント

ブループリントは、カスタマイズされたシステムイメージの説明です。システムの一部となるパッケージとカスタマイズが一覧表示されます。ブループリントをカスタマイズして編集し、特定のバージョンとして保存できます。ブループリントからシステムイメージを作成すると、イメージは RHEL Image Builder インターフェイスでブループリントに関連付けられます。

ブループリントは TOML 形式で作成します。

Compose
コンポーズは、特定のブループリントの特定のバージョンに基づいた、システムイメージの個別のビルドです。用語としての Compose は、システムイメージと、その作成、入力、メタデータ、およびそのプロセス自体のログを指します。
カスタマイズ
カスタマイズは、パッケージではないイメージの仕様です。これには、ユーザー、グループ、および SSH 鍵が含まれます。

1.1.2. RHEL Image Builder の出力形式

RHEL Image Builder は、次の表に示す複数の出力形式でイメージを作成できます。

表1.1 RHEL Image Builder の出力形式
説明CLI 名ファイル拡張子

QEMU イメージ

qcow2

.qcow2

ディスクアーカイブ

tar

.tar

Amazon Web Services

raw

.raw

Microsoft Azure

vhd

.vhd

Google Cloud Platform

gce

.tar.gz

VMware vSphere

vmdk

.vmdk

VMware vSphere

ova

.ova

Openstack

openstack

.qcow2

RHEL for Edge Commit

edge-commit

.tar

RHEL for Edge Container

edge-container

.tar

RHEL for Edge Installer

edge-installer

.iso

RHEL for Edge Raw イメージ

edge-raw-image

.raw.xz

RHEL for Edge Simplified Installer

edge-simplified-installer

.iso

RHEL for Edge AMI

edge-ami

.ami

RHEL for Edge VMDK

edge-vsphere

.vmdk

RHEL インストーラー

image-installer

.iso

Oracle Cloud Infrastructure

.oci

.qcow2

サポートされているタイプを確認するには、次のコマンドを実行します。

# composer-cli compose types

1.1.3. イメージビルドでサポートされているアーキテクチャー

RHEL Image Builder は、次のアーキテクチャーのイメージのビルドをサポートしています。

  • AMD および Intel 64 ビット (x86_64)
  • ARM64 (aarch64)
  • IBM Z (s390x)
  • IBM POWER システム

ただし、RHEL Image Builder はマルチアーキテクチャービルドをサポートしていません。実行しているのと同じシステムアーキテクチャーのイメージのみをビルドします。たとえば、RHEL Image Builder が x86_64 システムで実行している場合は、x86_64 アーキテクチャーのイメージのみをビルドできます。

1.1.4. 関連情報

1.2. RHEL Image Builder のインストール

RHEL Image Builder は、カスタムのシステムイメージを作成するツールです。RHEL Image Builder を使用する前に、RHEL Image Builder をインストールする必要があります。

1.2.1. RHEL Image Builder のシステム要件

RHEL Image Builder を実行するホストは、次の要件を満たしている必要があります。

表1.2 RHEL Image Builder のシステム要件
パラメーター最低要求値

System type

専用のホストまたは仮想マシン。RHEL Image Builder は、Red Hat Universal Base Images (UBI) などのコンテナーではサポートされていないことに注意してください。

プロセッサー

2 コア

メモリー

4 GiB

ディスク領域

`/var/cache/` ファイルシステムに 20 GiB の空き領域

アクセス権限

root

ネットワーク

Red Hat コンテンツ配信ネットワーク (CDN) へのインターネット接続

注記

インターネットに接続できない場合は、分離されたネットワークで RHEL Image Builder を使用してください。そのためには、Red Hat コンテンツ配信ネットワーク (CDN) に接続しないように、ローカルリポジトリーを参照するようにデフォルトのリポジトリーをオーバーライドする必要があります。コンテンツが内部でミラーリングされていることを確認するか、Red Hat Satellite を使用してください。

1.2.2. RHEL Image Builder のインストール

RHEL Image Builder をインストールして、osbuild-composer パッケージのすべての機能にアクセスできるようにします。

前提条件

  • RHEL Image Builder をインストールする RHEL ホストにログインしている。
  • ホストが Red Hat Subscription Manager (RHSM) または Red Hat Satellite にサブスクライブしている。
  • RHEL Image Builder パッケージをインストールできるように、BaseOS リポジトリーおよび AppStream リポジトリーを有効化している。

手順

  1. RHEL Image Builder とその他の必要なパッケージをインストールします。

    # yum install osbuild-composer composer-cli cockpit-composer
    • osbuild-composer - カスタマイズした RHEL オペレーティングシステムイメージをビルドするサービス。
    • composer-cli - このパッケージにより、CLI インターフェイスへのアクセスが可能になります。
    • cockpit-composer - このパッケージにより、Web UI インターフェイスへのアクセスが可能になります。Web コンソールは、cockpit-composer パッケージの依存関係としてインストールされます。
  2. RHEL Image Builder ソケットを有効にして起動します。

    # systemctl enable --now osbuild-composer.socket
  3. Web コンソールで RHEL Image Builder を使用する場合は、それを有効にして起動します。

    # systemctl enable --now cockpit.socket

    osbuild-composer サービスと cockpit サービスは、最初のアクセス時に自動的に起動します。

  4. ログアウトおよびログインしなくても composer-cli コマンドのオートコンプリート機能がすぐに動作するように、シェル設定スクリプトをロードします。

    $ source /etc/bash_completion.d/composer-cli
  5. RHEL ホストで実行中の osbuild-composer サービスを再起動します。

    # systemctl restart osbuild-composer
重要

osbuild-composer パッケージは、Red Hat Enterprise Linux 8.3 以降の新機能すべてに焦点を当てた新しいバックエンドエンジンで、デフォルト設定として推奨されています。以前のバックエンドの lorax-composer は非推奨となり、Red Hat Enterprise Linux 8 ライフサイクルの残りの期間、一部の修正のみを受信し、今後のメジャーリリースから削除される予定です。osbuild-composer を優先するには、lorax-composer のアンインストールを推奨します。

検証

  • composer-cli を実行して、インストールが動作することを確認します。

    # composer-cli status show

トラブルシューティング

システムジャーナルを使用して、RHEL Image Builder のアクティビティーを追跡できます。さらに、ファイル内のログメッセージを見つけることができます。

  • トレースバックのジャーナル出力を見つけるには、次のコマンドを実行します。

    $ journalctl | grep osbuild
  • リモートワーカーとローカルワーカーの両方を表示するには:

    $ journalctl -u osbuild-worker*
  • 実行中のサービスを表示するには:

    $ journalctl -u osbuild-composer.service

1.2.3. lorax-composer RHEL Image Builder バックエンドに戻す手順

osbuild-composer バックエンドは、はるかに拡張性が高くなっていますが、現時点では以前の lorax-composer バックエンドとの機能パリティーがありません。

以前のバックエンドに戻すには、以下の手順に従います。

前提条件

  • osbuild-composer パッケージがインストールされている。

手順

  1. osbuild-composer バックエンドを削除します。

    # yum remove osbuild-composer
    # yum remove weldr-client
  2. /etc/yum.conf ファイルで、osbuild-composer パッケージの除外エントリーを追加します。

    # cat /etc/yum.conf
    [main]
    gpgcheck=1
    installonly_limit=3
    clean_requirements_on_remove=True
    best=True
    skip_if_unavailable=False
    exclude=osbuild-composer weldr-client
  3. lorax-composer パッケージをインストールします。

    # yum install lorax-composer composer-cli
  4. lorax-composer サービスを有効にして開始し、再起動するたびに開始します。

    # systemctl enable --now lorax-composer.socket
    # systemctl start lorax-composer

1.3. RHEL Image Builder CLI を使用したシステムイメージの作成

RHEL Image Builder は、カスタムのシステムイメージを作成するツールです。RHEL Image Builder を制御し、カスタムシステムイメージを作成するには、コマンドラインインターフェイス (CLI) または Web コンソールインターフェイスを使用できます。

1.3.1. RHEL Image Builder コマンドラインインターフェイスの紹介

RHEL Image Builder コマンドラインインターフェイス (CLI) を使用してブループリントを作成するには、適切なオプションとサブコマンドを指定して composer-cli コマンドを実行します。

コマンドラインインターフェイスのワークフローの概要は次のようになります。

  1. ブループリントを作成するか、既存のブループリント定義をプレーンテキストファイルにエクスポート (保存) します。
  2. テキストエディターでこのファイルを編集します。
  3. ブループリントテキストファイルを Image Builder にインポートします。
  4. Compose を実行して、ブループリントからイメージをビルドします。
  5. イメージファイルをエクスポートしてダウンロードします。

composer-cli コマンドには、ブループリントを作成する基本的なサブコマンドとは別に、設定したブループリントと Compose の状態を調べるための多くのサブコマンドが用意されています。

1.3.2. RHEL Image Builder を非 root ユーザーとして使用する

非 root として composer-cli コマンドを実行するには、ユーザーが weldr グループに属している必要があります。

前提条件

  • ユーザーを作成している。

手順

  • ユーザーを weldr または root グループに追加するには、次のコマンドを実行します:

    $ sudo usermod -a -G weldr user
    $ newgrp weldr

1.3.3. コマンドラインインターフェイスを使用したブループリントの作成

RHEL Image Builder のコマンドラインインターフェイス (CLI) を使用して、新しいブループリントを作成できます。ブループリントには、最終的なイメージと、パッケージやカーネルのカスタマイズなどのそのカスタマイズが記述されています。

前提条件

  • root ユーザーまたは weldr グループのメンバーであるユーザーとしてログインしている。

手順

  1. 次の内容のプレーンテキストファイルを作成します。

    name = "BLUEPRINT-NAME"
    description = "LONG FORM DESCRIPTION TEXT"
    version = "0.0.1"
    modules = []
    groups = []

    BLUEPRINT-NAME および LONG FORM DESCRIPTION TEXT は、ブループリントの名前および説明に置き換えます。

    0.0.1 は、セマンティックバージョニングスキームに従ってバージョン番号に置き換えます。

  2. ブループリントに含まれるすべてのパッケージに、次の行をファイルに追加します。

    [[packages]]
    name = "package-name"
    version = "package-version"

    package-name は、httpdgdb-doccoreutils などのパッケージ名に置き換えます。

    必要に応じて、package-version を使用するバージョンに置き換えます。このフィールドは、dnf バージョンの指定に対応します。

    • 特定のバージョンについては、8.7.0 などの正確なバージョン番号を使用してください。
    • 利用可能な最新バージョンについては、アスタリスク * を使用してください。
    • 最新のマイナーバージョンを指定する場合は、8.* などの形式を使用してください。
  3. ニーズに合わせてブループリントをカスタマイズします。たとえば、Simultaneous Multi Threading (SMT) を無効にするには、ブループリントファイルに次の行を追加します。

    [customizations.kernel]
    append = "nosmt=force"

    その他に利用できるカスタマイズについては、サポートされているイメージのカスタマイズ を参照してください。

    [][[]] は TOML で表現される異なるデータ構造であることに注意してください。

    • [customizations.kernel] ヘッダーは、キーと各値のペアの集合によって定義される単一のテーブルを表します (例: append = "nosmt=force")。
    • [[packages]] ヘッダーはテーブルの配列を表します。最初のインスタンスで、配列とその最初のテーブル要素を定義します (例: name = "package-name"version = "package-version")。後続の各インスタンスで、指定の順序で、その配列内に新しいテーブル要素を作成して定義します。
  4. たとえば、ファイルを BLUEPRINT-NAME.toml として保存し、テキストエディターを閉じます。
  5. ブループリントをプッシュします。

    # composer-cli blueprints push BLUEPRINT-NAME.toml

    BLUEPRINT-NAME は、前の手順で使用した値に置き換えます。

    注記

    composer-cli を非 root として使用してイメージを作成するには、ユーザーを weldr または root グループに追加します。

    # usermod -a -G weldr user
    $ newgrp weldr

検証

  • ブループリントがプッシュされ存在していることを確認するには、既存のブループリントを一覧表示します。

    # composer-cli blueprints list
  • 追加したばかりのブループリント設定を表示します。

    # composer-cli blueprints show BLUEPRINT-NAME
  • ブループリントに記載されているコンポーネントおよびバージョンと、その依存関係が有効かどうかを確認します。

    # composer-cli blueprints depsolve BLUEPRINT-NAME

    RHEL Image Builder がカスタムリポジトリーのパッケージの依存関係を解決できない場合は、osbuild-composer キャッシュを削除します。3

    $ sudo rm -rf /var/cache/osbuild-composer/*
    $ sudo systemctl restart osbuild-composer

1.3.4. コマンドラインインターフェイスを使用したブループリントの編集

コマンドライン (CLI) インターフェイスで既存のブループリントを編集して、たとえば、新しいパッケージを追加したり、新しいグループを定義したり、カスタマイズしたイメージを作成したりできます。そのためには、以下の手順に従います。

前提条件

  • ブループリントを作成している。

手順

  1. 既存のブループリントをリストします。

    # composer-cli blueprints list
  2. ブループリントをローカルテキストファイルに保存します。

    # composer-cli blueprints save BLUEPRINT-NAME
  3. BLUEPRINT-NAME .toml ファイルをテキストエディターで編集し、変更を加えます。
  4. 編集を完了する前に、ファイルが有効なブループリントであることを確認します。

    1. ブループリントに次の行が存在する場合は、それを削除します。

      packages = []
    2. たとえば、バージョン番号を 0.0.1 から 0.1.0 に増やします。RHEL Image Builder のブループリントバージョンでは、セマンティックバージョニングスキームを使用する必要があります。また、バージョンを変更しない場合、パッチバージョンコンポーネントが自動的に増加することにも注意してください。
  5. ファイルを保存し、テキストエディターを閉じます。
  6. ブループリントを RHEL Image Builder にプッシュして戻します。

    # composer-cli blueprints push BLUEPRINT-NAME.toml
    注記

    ブループリントを RHEL Image Builder にインポートして戻すには、.toml 拡張子を含むファイル名を指定しますが、他のコマンドではブループリント名のみを使用します。

検証

  1. RHEL Image Builder にアップロードした内容が編集内容と一致することを確認するには、ブループリントの内容をリストします。

    # composer-cli blueprints show BLUEPRINT-NAME
  2. ブループリントに記載されているコンポーネントおよびバージョンと、その依存関係が有効かどうかを確認します。

    # composer-cli blueprints depsolve BLUEPRINT-NAME

1.3.5. RHEL Image Builder コマンドラインインターフェイスでのシステムイメージの作成

RHEL Image Builder のコマンドラインインターフェイスを使用して、カスタマイズした RHEL イメージをビルドできます。そのためには、ブループリントとイメージタイプを指定する必要があります。必要に応じて、ディストリビューションを指定することもできます。ディストリビューションを指定しない場合は、ホストシステムと同じディストリビューションとバージョンが使用されます。アーキテクチャーもホストのアーキテクチャーと同じになります。

前提条件

手順

  1. オプション: 作成できるイメージ形式をリストします。

    # composer-cli compose types
  2. Compose を起動します。

    # composer-cli compose start BLUEPRINT-NAME IMAGE-TYPE

    BLUEPRINT-NAME をブループリントの名前に、IMAGE-TYPE をイメージのタイプに置き換えます。使用可能な値は、composer-cli compose types コマンドの出力を参照してください。

    作成プロセスはバックグラウンドで開始され、作成者の Universally Unique Identifier (UUID) が表示されます。

  3. イメージの作成が完了するまでに最大 10 分かかる場合があります。

    Compose のステータスを確認するには、以下のコマンドを実行します。

    # composer-cli compose status

    Compose が完了すると、ステータスが FINISHED になります。リスト内の Compose を識別するには、その UUID を使用します。

  4. Compose プロセスが完了したら、作成されたイメージファイルをダウンロードします。

    # composer-cli compose image UUID

    UUID は、前の手順で示した UUID 値に置き換えます。

検証

イメージを作成したら、次のコマンドを使用してイメージ作成の進行状況を確認できます。

  • イメージのメタデータをダウンロードして、Compose 用のメタデータの .tar ファイルを取得します。

    $ sudo composer-cli compose metadata UUID
  • イメージのログをダウンロードします。

    $ sudo composer-cli compose logs UUID

    このコマンドは、イメージ作成のログを含む .tar ファイルを作成します。ログが空の場合は、ジャーナルを確認できます。

  • ジャーナルを確認してください。

    $ journalctl | grep osbuild
  • イメージのマニフェストを確認します。

    $ sudo cat /var/lib/osbuild-composer/jobs/job_UUID.json

    ジャーナルで job_UUID .json を見つけることができます。

関連情報

1.3.6. RHEL Image Builder コマンドラインの基本的なコマンド

RHEL Image Builder コマンドラインインターフェイスでは、以下のサブコマンドを利用できます。

ブループリント操作

利用可能なブループリント一覧の表示
# composer-cli blueprints list
TOML 形式でブループリントの内容の表示
# composer-cli blueprints show <BLUEPRINT-NAME>
TOML 形式のブループリントの内容を BLUEPRINT-NAME.toml ファイルに保存 (エクスポート)
# composer-cli blueprints save <BLUEPRINT-NAME>
ブループリントの削除
# composer-cli blueprints delete <BLUEPRINT-NAME>
TOML 形式のブループリントファイルを RHEL Image Builder へプッシュ (インポート)
# composer-cli blueprints push <BLUEPRINT-NAME>

ブループリントでイメージの設定

利用可能なイメージタイプをリスト表示します。
# composer-cli compose types
Compose の起動
# composer-cli compose start <BLUEPRINT> <COMPOSE-TYPE>
Compose のリスト表示
# composer-cli compose list
Compose、およびそのステータスのリスト表示
# composer-cli compose status
実行中の Compose のキャンセル
# composer-cli compose cancel <COMPOSE-UUID>
完了した Compose の削除
# composer-cli compose delete <COMPOSE-UUID>
Compose の詳細情報の表示
# composer-cli compose info <COMPOSE-UUID>
Compose のイメージファイルのダウンロード
# composer-cli compose image <COMPOSE-UUID>
サブコマンドとオプションをもっと見る
# composer-cli help

関連情報

  • システムの composer-cli(1) の man ページ

1.3.7. RHEL Image Builder のブループリント形式

RHEL Image Builder のブループリントは、TOML 形式のプレーンテキストとしてユーザーに表示されます。

一般的なブループリントファイルの要素には、次のものが含まれます。

ブループリントのメタデータ
name = "<BLUEPRINT-NAME>"
description = "<LONG FORM DESCRIPTION TEXT>"
version = "<VERSION>"

BLUEPRINT-NAME および LONG FORM DESCRIPTION TEXT フィールドは、ブループリントの名前と説明です。

VERSION は、セマンティックバージョニングスキームに従ったバージョン番号であり、ブループリントファイル全体で 1 つだけ存在するものです。

イメージに追加するグループ
[[groups]]
name = "group-name"

group エントリーは、イメージにインストールするパッケージのグループを説明します。グループは、次のパッケージカテゴリーを使用します。

  • 必須
  • デフォルト
  • 任意

    group-name は、anaconda-toolswidgetwheel または users などのグループの名前です。ブループリントは、必須パッケージとデフォルトパッケージをインストールします。オプションパッケージを選択するメカニズムはありません。

イメージに追加するパッケージ
[[packages]]
name = "<package-name>"
version = "<package-version>"

package-name は、httpdgdb-doc、または coreutils などのパッケージの名前です。

package-version は使用するバージョンです。このフィールドは、dnf バージョンの指定に対応します。

  • 特定のバージョンについては、8.7.0 などの正確なバージョン番号を使用してください。
  • 利用可能な最新バージョンを指定する場合は、アスタリスク (*) を使用します。
  • 最新のマイナーバージョンの場合は、8.* などの形式を使用します。

    追加するすべてのパッケージにこのブロックを繰り返します。

注記

RHEL Image Builder ツールのパッケージとモジュールの間に違いはありません。どちらも RPM パッケージの依存関係として扱われます。

1.3.8. サポートされているイメージのカスタマイズ

ブループリントに次のようなカスタマイズを追加することで、イメージをカスタマイズできます。

  • RPM パッケージの追加
  • サービスの有効化
  • カーネルコマンドラインパラメーターのカスタマイズ

とりわけ、ブループリント内ではいくつかのイメージのカスタマイズを使用できます。カスタマイズを使用すると、デフォルトのパッケージでは使用できないパッケージやグループをイメージに追加できます。これらのオプションを使用するには、ブループリントでカスタマイズを設定し、それを RHEL Image Builder にインポート (プッシュ) します。

関連情報

1.3.8.1. ディストリビューションの選択

distro フィールドを使用して、イメージを作成するときやブループリント内の依存関係を解決するときに使用するディストリビューションを選択できます。distro が空白のままの場合、ホストのディストリビューションが使用されます。ディストリビューションを指定しない場合、ブループリントはホストディストリビューションを使用します。ホストオペレーティングシステムをアップグレードする場合、ディストリビューションが設定されていないブループリントでは、新しいオペレーティングシステムのバージョンを使用してイメージがビルドされます。RHEL Image Builder ホストとは異なるオペレーティングシステムイメージをビルドすることはできません。

  • 指定の RHEL イメージを常にビルドするように、RHEL ディストリビューションを使用してブループリントをカスタマイズします。

    name = "blueprint_name"
    description = "blueprint_version"
    version = "0.1"
    distro = "different_minor_version"

    以下に例を示します。

    name = "tmux"
    description = "tmux image with openssh"
    version = "1.2.16"
    distro = "rhel-9.5"

別のマイナーバージョンをビルドするには、"different_minor_version" を置き換えます。たとえば、RHEL 8.10 イメージをビルドする場合は、distro = "rhel-810" を使用します。RHEL 8.10 イメージでは、RHEL 8.9 以前のリリースなどのマイナーバージョンをビルドできます。

1.3.8.2. パッケージグループの選択

パッケージグループを使用してブループリントをカスタマイズします。イメージにインストールするパッケージのグループを、groups リストに記述します。パッケージグループはリポジトリーのメタデータで定義されます。各グループには、主にユーザーインターフェイスでの表示に使用されるわかりやすい名前と、キックスタートファイルでよく使用される ID があります。この場合、ID を使用してグループをリストする必要があります。グループでは、必須、デフォルト、任意の 3 つの方法でパッケージを分類できます。ブループリントには、必須パッケージとデフォルトパッケージのみがインストールされます。任意のパッケージを選択することはできません。

name 属性は、必須の文字列であり、リポジトリー内のパッケージグループ ID と正確に一致する必要があります。

注記

現在、osbuild-composer のパッケージとモジュールの間に違いはありません。どちらも RPM パッケージの依存関係として扱われます。

  • パッケージを使用してブループリントをカスタマイズします。

    [[groups]]
    name = "group_name"

    group_name は、グループの名前に置き換えます。たとえば、anaconda-tools です。

    [[groups]]
    name = "anaconda-tools"
1.3.8.3. コンテナーの埋め込み

ブループリントをカスタマイズして、最新の RHEL コンテナーを埋め込むことができます。ソースを含むオブジェクトと、必要に応じて tls-verify 属性をコンテナーリストに含めます。

イメージに埋め込むコンテナーイメージを、コンテナーリストのエントリーに記述します。

  • source - 必須フィールド。これは、レジストリーにあるコンテナーイメージへの参照です。この例では、registry.access.redhat.com レジストリーを使用します。タグのバージョンを指定できます。デフォルトのタグバージョンは latest です。
  • name - ローカルレジストリー内のコンテナーの名前。
  • tls-verify - ブールフィールド。tls-verify ブールフィールドは、Transport Layer Security を制御します。デフォルト値は true です。

埋め込まれたコンテナーは自動的に起動しません。これを起動するには、systemd ユニットファイルまたは quadlets を作成し、ファイルをカスタマイズします。

  • registry.access.redhat.com/ubi9/ubi:latest のコンテナーとホストのコンテナーを埋め込むには、ブループリントに次のカスタマイズを追加します。

    [[containers]]
    source = "registry.access.redhat.com/ubi9/ubi:latest"
    name =  "local-name"
    tls-verify = true
    
    [[containers]]
    source = "localhost/test:latest"
    local-storage = true

containers-auth.json ファイルを使用して、保護されたコンテナーリソースにアクセスできます。コンテナーレジストリーの認証情報 を参照してください。

1.3.8.4. イメージのホスト名の設定

customizations.hostname は、最終イメージのホスト名を設定するために使用できるオプションの文字列です。このカスタマイズはオプションであり、設定しない場合、ブループリントはデフォルトのホスト名を使用します。

  • ブループリントをカスタマイズしてホスト名を設定します。

    [customizations]
    hostname = "baseimage"
1.3.8.5. 追加ユーザーの指定

ユーザーをイメージに追加し、必要に応じて SSH キーを設定します。このセクションのフィールドは、name を除いてすべてオプションです。

手順

  • ブループリントをカスタマイズして、イメージにユーザーを追加します。

    [[customizations.user]]
    name = "USER-NAME"
    description = "USER-DESCRIPTION"
    password = "PASSWORD-HASH"
    key = "PUBLIC-SSH-KEY"
    home = "/home/USER-NAME/"
    shell = "/usr/bin/bash"
    groups = ["users", "wheel"]
    uid = NUMBER
    gid = NUMBER
    [[customizations.user]]
    name = "admin"
    description = "Administrator account"
    password = "$6$CHO2$3rN8eviE2t50lmVyBYihTgVRHcaecmeCk31L..."
    key = "PUBLIC SSH KEY"
    home = "/srv/widget/"
    shell = "/usr/bin/bash"
    groups = ["widget", "users", "wheel"]
    uid = 1200
    gid = 1200
    expiredate = 12345

    GID はオプションであり、イメージにすでに存在している必要があります。GID は、必要に応じて、パッケージによって作成されるか、ブループリントによって [[customizations.group]] エントリーを使用して作成されます。

    PASSWORD-HASH は、実際の password hash に置き換えます。password hash を生成するには、次のようなコマンドを使用します。

    $ python3 -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())'

    その他のプレースホルダーを、適切な値に置き換えます。

    name の値を入力し、不要な行は省略します。

    追加するすべてのユーザーにこのブロックを繰り返します。

1.3.8.6. 追加グループの指定

作成されるシステムイメージのグループを指定します。name 属性と gid 属性は両方とも必須です。

  • グループを使用してブループリントをカスタマイズします。

    [[customizations.group]]
    name = "GROUP-NAME"
    gid = NUMBER

    追加するすべてのグループにこのブロックを繰り返します。以下に例を示します。

    [[customizations.group]]
    name = "widget"
    gid = 1130
1.3.8.7. 既存ユーザーの SSH キーの設定

customizations.sshkey を使用して、最終イメージ内の既存ユーザーの SSH キーを設定できます。user 属性と key 属性は両方とも必須です。

  • 既存ユーザーの SSH キーを設定してブループリントをカスタマイズします。

    [[customizations.sshkey]]
    user = "root"
    key = "PUBLIC-SSH-KEY"

    以下に例を示します。

    [[customizations.sshkey]]
    user = "root"
    key = "SSH key for root"
    注記

    既存ユーザーに対してのみ、customizations.sshkey カスタマイズを設定できます。ユーザーを作成して SSH キーを設定するには、追加ユーザーの指定 のカスタマイズを参照してください。

1.3.8.8. カーネル引数の追加

ブートローダーのカーネルコマンドラインに引数を追加できます。デフォルトでは、RHEL Image Builder はデフォルトのカーネルをイメージにビルドします。ただし、ブループリントでカーネルを設定することでカーネルをカスタマイズできます。

  • デフォルト設定にカーネルの起動パラメーターオプションを追加します。

    [customizations.kernel]
    append = "KERNEL-OPTION"

    以下に例を示します。

    [customizations.kernel]
    name = "kernel-debug"
    append = "nosmt=force"
1.3.8.9. リアルタイムカーネルを使用した RHEL イメージのビルド

リアルタイムカーネル (kernel-rt) を使用して RHEL イメージをビルドするには、デフォルトカーネルとして kernel-rt が正しく選択されたイメージをビルドできるように、リポジトリーをオーバーライドする必要があります。/usr/share/osbuild-composer/repositories/ ディレクトリーの .json を使用してください。その後、ビルドしたイメージをシステムにデプロイし、リアルタイムカーネル機能を使用できます。

注記

リアルタイムカーネルは、Red Hat Enterprise Linux の動作認定を受けた AMD64 および Intel 64 サーバープラットフォームで動作します。

前提条件

手順

  1. 以下のディレクトリーを作成します。

    # mkdir /etc/osbuild-composer/repositories/
  2. /usr/share/osbuild-composer/repositories/rhel-8.version.json ファイルの内容を新しいディレクトリーにコピーします。

    # cp /usr/share/osbuild-composer/repositories/rhel-8.version.json /etc/osbuild-composer/repositories
  3. /etc/osbuild-composer/repositories/rhel-8.version.json ファイルを編集して、RT カーネルリポジトリーを含めます。

    # grep -C 6 kernel-rt /etc/osbuild-composer/repositories/rhel-8.version.json
          "baseurl": "https://cdn.redhat.com/content/dist/rhel8/8.version/x86_64/appstream/os",
          "gpgkey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\nm………..=\n=UZd/\n-----END PGP PUBLIC KEY BLOCK-----\n",
          "rhsm": true,
          "check_gpg": true
        },
        {
          "name": "kernel-rt",
          "baseurl": "https://cdn.redhat.com/content/dist/rhel8/8.version/x86_64/rt/os",
          "gpgkey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\nmQINBEr………fg==\n=UZd/\n-----END PGP PUBLIC KEY BLOCK-----\n",
          "rhsm": true,
          "check_gpg": true
        },
  4. サービスを再起動します。

    # systemctl restart osbuild-composer
  5. kernel-rt.json ファイルに含まれていることを確認します。

    # composer-cli sources list
    # composer-cli sources info kernel-rt

    以前に設定した URL が表示されます。

  6. ブループリントを作成します。ブループリントに、"[customizations.kernel]" カスタマイズを追加します。以下は、ブループリントに "[customizations.kernel]" を追加した例です。

    name = "rt-kernel-image"
    description = ""
    version = "2.0.0"
    modules = []
    groups = []
    distro = "rhel-8_version_"
    [[customizations.user]]
    name = "admin"
    password = "admin"
    groups = ["users", "wheel"]
    [customizations.kernel]
    name = "kernel-rt"
    append = ""
  7. ブループリントをサーバーにプッシュします。

    # composer-cli blueprints push rt-kernel-image.toml
  8. 作成したブループリントからイメージをビルドします。次の例では、(.qcow2) イメージをビルドします。

    # composer-cli compose start rt-kernel-image qcow2
  9. ビルドしたイメージを、リアルタイムカーネル機能を使用するシステムにデプロイします。

検証

  • イメージから仮想マシンを起動した後、デフォルトのカーネルとして kernel-rt が正しく選択されたイメージがビルドされていることを確認します。

    $ cat /proc/cmdline
    BOOT_IMAGE=(hd0,got3)/vmlinuz-5.14.0-362.24.1..el8_version_.x86_64+rt...
1.3.8.10. タイムゾーンと NTP の設定

ブループリントをカスタマイズして、タイムゾーンと Network Time Protocol (NTP) を設定できます。timezone 属性と ntpservers 属性は両方ともオプションの文字列です。タイムゾーンをカスタマイズしない場合、システムは 協定世界時 (UTC) を使用します。NTP サーバーを設定しない場合、システムはデフォルトのディストリビューションを使用します。

  • 必要な timezonentpservers を使用してブループリントをカスタマイズします。

    [customizations.timezone]
    timezone = "TIMEZONE"
    ntpservers = "NTP_SERVER"

    以下に例を示します。

    [customizations.timezone]
    timezone = "US/Eastern"
    ntpservers = ["0.north-america.pool.ntp.org", "1.north-america.pool.ntp.org"]
    注記

    Google Cloud などの一部のイメージタイプには、すでに NTP サーバーがセットアップされています。そのようなイメージでは、選択されている環境で NTP サーバーを起動する必要があるため、これをオーバーライドすることはできません。ただし、ブループリントでタイムゾーンをカスタマイズできます。

1.3.8.11. ロケール設定のカスタマイズ

作成されるシステムイメージのロケール設定をカスタマイズできます。language 属性と keyboard 属性は両方とも必須です。他の多くの言語を追加できます。最初に追加する言語はプライマリー言語で、他の言語はセカンダリー言語です。

手順

  • ロケール設定を行います。

    [customizations.locale]
    languages = ["LANGUAGE"]
    keyboard = "KEYBOARD"

    以下に例を示します。

    [customizations.locale]
    languages = ["en_US.UTF-8"]
    keyboard = "us"
  • 言語でサポートされている値を一覧表示するには、以下のコマンドを実行します。

    $ localectl list-locales
  • キーボードでサポートされている値を一覧表示するには、以下のコマンドを実行します。

    $ localectl list-keymaps
1.3.8.12. ファイアウォールのカスタマイズ

生成されたシステムイメージのファイアウォールを設定します。デフォルトでは、ファイアウォールは、sshd など、ポートを明示的に有効にするサービスを除き、着信接続をブロックします。

[customizations.firewall] または [customizations.firewall.services] を使用したくない場合は、属性を削除するか、空のリスト [] に設定します。デフォルトのファイアウォールセットアップのみを使用する場合は、ブループリントからカスタマイズを省略できます。

注記

Google および OpenStack テンプレートは、環境のファイアウォールを明示的に無効にします。ブループリントを設定してこの動作をオーバーライドすることはできません。

手順

  • 他のポートとサービスを開くには、次の設定を使用してブループリントをカスタマイズします。

    [customizations.firewall]
    ports = ["PORTS"]

    ここで、ports は、ポート、または開くポートとプロトコルの範囲を含む文字列のオプションのリストです。port:protocol 形式を使用してポートを設定できます。portA-portB:protocol 形式を使用してポート範囲を設定できます。以下に例を示します。

    [customizations.firewall]
    ports = ["22:tcp", "80:tcp", "imap:tcp", "53:tcp", "53:udp", "30000-32767:tcp", "30000-32767:udp"]

    /etc/services の数値ポートまたはその名前を使用して、ポートリストを有効または無効にすることができます。

  • customizations.firewall.service セクションで、どのファイアウォールサービスを有効または無効にするかを指定します。

    [customizations.firewall.services]
    enabled = ["SERVICES"]
    disabled = ["SERVICES"]
  • 利用可能なファイアウォールサービスを確認できます。

    $ firewall-cmd --get-services

    以下に例を示します。

    [customizations.firewall.services]
    enabled = ["ftp", "ntp", "dhcp"]
    disabled = ["telnet"]
    注記

    firewall.services にリストされているサービスは、/etc/services ファイルで使用可能な service-names とは異なります。

1.3.8.13. サービスの有効化または無効化

システムの起動時に有効にするサービスを制御することができます。一部のイメージタイプでは、イメージが正しく機能するようにすでにサービスが有効または無効になっており、このセットアップをオーバーライドすることができません。ブループリントの [customizations.services] 設定はこれらのサービスを置き換えるものではありませんが、イメージテンプレートにすでに存在するサービスのリストにサービスを追加します。

  • 起動時に有効にするサービスをカスタマイズします。

    [customizations.services]
    enabled = ["SERVICES"]
    disabled = ["SERVICES"]

    以下に例を示します。

    [customizations.services]
    enabled = ["sshd", "cockpit.socket", "httpd"]
    disabled = ["postfix", "telnetd"]
1.3.8.14. パーティションモードの指定

ビルドするディスクイメージをパーティション設定する方法を選択するには、partitioning_mode 変数を使用します。サポートされている次のモードでイメージをカスタマイズできます。

  • auto-lvm: 1 つ以上のファイルシステムのカスタマイズがない限り、RAW パーティションモードを使用します。ある場合は、LVM パーティションモードを使用します。
  • lvm: 追加のマウントポイントがない場合でも、常に LVM パーティションモードを使用します。
  • raw: マウントポイントが 1 つ以上ある場合でも、RAW パーティションを使用します。
  • 次のカスタマイズを使用して、partitioning_mode 変数を使用してブループリントをカスタマイズできます。

    [customizations]
    partitioning_mode = "lvm"
1.3.8.15. カスタムファイルシステム設定の指定

ブループリントでカスタムファイルシステム設定を指定できるため、デフォルトのレイアウト設定ではなく、特定のディスクレイアウトでイメージを作成できます。ブループリントでデフォルト以外のレイアウト設定を使用すると、次の利点が得られます。

  • セキュリティーベンチマークへの準拠
  • ディスク外エラーに対する保護
  • パフォーマンスの向上
  • 既存のセットアップとの整合性
注記

OSTree イメージには読み取り専用などの独自のマウントルールがあるため、OSTree システムではファイルシステムのカスタマイズはサポートされません。次のイメージタイプはサポートされません。

  • image-installer
  • edge-installer
  • edge-simplified-installer

さらに、次のイメージタイプはパーティション設定されたオペレーティングシステムイメージを作成しないため、ファイルシステムのカスタマイズをサポートしません。

  • edge-commit
  • edge-container
  • tar
  • container

ただし、次のイメージタイプではファイルシステムのカスタマイズがサポートされています。

  • simplified-installer
  • edge-raw-image
  • edge-ami
  • edge-vsphere

OSTree システムの一部例外を除き、ファイルシステムの /root レベルで任意のディレクトリー名を選択できます (例: `/local`、`/mypartition`、/$PARTITION)。論理ボリュームでは、これらの変更は LVM パーティションシステム上で行われます。別の論理ボリューム上の /var、`/var/log`、および /var/lib/containers ディレクトリーがサポートされています。root レベルでの例外は次のとおりです。

  • "/home": {Deny: true},
  • "/mnt": {Deny: true},
  • "/opt": {Deny: true},
  • "/ostree": {Deny: true},
  • "/root": {Deny: true},
  • "/srv": {Deny: true},
  • "/var/home": {Deny: true},
  • "/var/mnt": {Deny: true},
  • "/var/opt": {Deny: true},
  • "/var/roothome": {Deny: true},
  • "/var/srv": {Deny: true},
  • "/var/usrlocal": {Deny: true},

RHEL 8.10 および 9.5 より前のリリースディストリビューションの場合、ブループリントは次の mountpoints とそのサブディレクトリーをサポートしています。

  • / - ルートマウントポイント
  • /var
  • /home
  • /opt
  • /srv/
  • /usr
  • /app
  • /data
  • /tmp

RHEL 9.5 および 8.10 以降のリリースディストリビューションでは、オペレーティングシステム用に予約されている特定のパスを除き、任意のカスタムマウントポイントを指定できます。

次のマウントポイントとそのサブディレクトリーに任意のカスタムマウントポイントを指定することはできません。

  • /bin
  • /boot/efi
  • /dev
  • /etc
  • /lib
  • /lib64
  • /lost+found
  • /proc
  • /run
  • /sbin
  • /sys
  • /sysroot
  • /var/lock
  • /var/run

ブループリントで /usr カスタムマウントポイントのファイルシステムはカスタマイズできますが、そのサブディレクトリーはカスタマイズできません。

注記

マウントポイントのカスタマイズは、RHEL 8.5 ディストリビューション以降、CLI を使用した場合のみサポートされます。以前のディストリビューションでは、root パーティションをマウントポイントとして指定し、size 引数をイメージ size のエイリアスとして指定することしかできません。RHEL 8.6 以降、osbuild-composer-46.1-1.el8 RPM 以降のバージョンでは、物理パーティションは使用できなくなり、ファイルシステムのカスタマイズによって論理ボリュームが作成されます。

カスタマイズされたイメージに複数のパーティションがある場合、LVM でカスタマイズされたファイルシステムパーティションを使用してイメージを作成し、実行時にそれらのパーティションのサイズを変更できます。これを行うには、ブループリントでカスタマイズされたファイルシステム設定を指定して、必要なディスクレイアウトでイメージを作成します。デフォルトのファイルシステムレイアウトは変更されません。ファイルシステムをカスタマイズせずにプレーンイメージを使用すると、cloud-init によってルートパーティションのサイズが変更されます。

ブループリントは、ファイルシステムのカスタマイズを LVM パーティションに自動的に変換します。

カスタムファイルブループリントのカスタマイズを使用して、新しいファイルを作成したり、既存のファイルを置き換えたりできます。指定するファイルの親ディレクトリーが存在している必要があります。存在しない場合、イメージのビルドが失敗します。[[customizations.directories]] のカスタマイズで親ディレクトリーを指定して、親ディレクトリーが存在することを確認してください。

警告

ファイルのカスタマイズを他のブループリントのカスタマイズと組み合わせると、他のカスタマイズの機能に影響が生じたり、現在のファイルのカスタマイズがオーバーライドされる可能性があります。

1.3.8.15.1. カスタマイズされたファイルをブループリントで指定する

[[customizations.files]] ブループリントのカスタマイズを使用すると、次のことが可能になります。

  • 新しいテキストファイルを作成する。
  • 既存のファイルを変更する。警告: これにより、既存のコンテンツが上書きされる可能性があります。
  • 作成するファイルのユーザーとグループの所有権を設定する。
  • モード許可を 8 進数形式で設定する。

以下のファイルは作成または置き換えることはできません。

  • /etc/fstab
  • /etc/shadow
  • /etc/passwd
  • /etc/group

[[customizations.files]] および [[customizations.directories]] ブループリントのカスタマイズを使用して、イメージ内にカスタマイズされたファイルとディレクトリーを作成できます。これらのカスタマイズは、/etc ディレクトリーでのみ使用できます。

注記

これらのブループリントのカスタマイズは、OSTree コミットをデプロイするイメージタイプ (edge-raw-imageedge-installeredge-simplified-installer など) を除く、すべてのイメージタイプでサポートされます。

警告

modeuser、または group がすでに設定されているイメージ内にすでに存在するディレクトリーパスで customizations.directories を使用すると、イメージビルドで既存のディレクトリーの所有権または権限の変更を防ぐことができません。

1.3.8.15.2. カスタマイズされたディレクトリーをブループリントで指定する

[[customizations.directories]] ブループリントのカスタマイズを使用すると、以下を行うことができます。

  • 新しいディレクトリーを作成する。
  • 作成するディレクトリーのユーザーとグループの所有権を設定する。
  • ディレクトリーモードのパーミッションを 8 進数形式で設定する。
  • 必要に応じて親ディレクトリーを作成する。

[[customizations.files]] ブループリントのカスタマイズを使用すると、次のことが可能になります。

  • 新しいテキストファイルを作成する。
  • 既存のファイルを変更する。警告: これにより、既存のコンテンツが上書きされる可能性があります。
  • 作成するファイルのユーザーとグループの所有権を設定する。
  • モード許可を 8 進数形式で設定する。
注記

以下のファイルは作成または置き換えることはできません。

  • /etc/fstab
  • /etc/shadow
  • /etc/passwd
  • /etc/group

以下のカスタマイズが可能です。

  • ブループリントのファイルシステム設定をカスタマイズします。

    [[customizations.filesystem]]
    mountpoint = "MOUNTPOINT"
    minsize = MINIMUM-PARTITION-SIZE

    MINIMUM-PARTITION-SIZE 値には、デフォルトのサイズ形式はありません。ブループリントのカスタマイズでは、kB から TB、および KiB から TiB の値と単位がサポートされています。たとえば、マウントポイントのサイズをバイト単位で定義できます。

    [[customizations.filesystem]]
    mountpoint = "/var"
    minsize = 1073741824
  • 単位を使用してマウントポイントのサイズを定義します。以下に例を示します。

    [[customizations.filesystem]]
    mountpoint = "/opt"
    minsize = "20 GiB"
    [[customizations.filesystem]]
    mountpoint = "/boot"
    minsize = "1 GiB"
  • minsize を設定して最小パーティションを定義します。以下に例を示します。

    [[customizations.filesystem]]
    mountpoint = "/var"
    minsize = 2147483648
  • [[customizations.directories]] を使用して、イメージ用にカスタマイズされたディレクトリーを /etc ディレクトリーの下に作成します。

    [[customizations.directories]]
    path = "/etc/directory_name"
    mode = "octal_access_permission"
    user = "user_string_or_integer"
    group = "group_string_or_integer"
    ensure_parents = boolean

    ブループリントの各エントリーを説明します。

    • path - 必須 - 作成するディレクトリーへのパスを入力します。/etc ディレクトリー下の絶対パスである必要があります。
    • mode - オプション - ディレクトリーのアクセスパーミッションを 8 進数形式で設定します。パーミッションを指定しない場合、デフォルトで 0755 に設定されます。先頭のゼロは任意です。
    • user - オプション - ユーザーをディレクトリーの所有者として設定します。ユーザーを指定しない場合は、デフォルトで root に設定されます。ユーザーは文字列または整数として指定できます。
    • group - オプション - グループをディレクトリーの所有者として設定します。グループを指定しない場合は、デフォルトで root になります。グループは文字列または整数として指定できます。
    • ensure_parents - オプション - 必要に応じて親ディレクトリーを作成するかどうかを指定します。値を指定しない場合は、デフォルトで false に設定されます。
  • [[customizations.directories]] を使用して、イメージ用にカスタマイズされたファイルを /etc ディレクトリーの下に作成します。

    [[customizations.files]]
    path = "/etc/directory_name"
    mode = "octal_access_permission"
    user = "user_string_or_integer"
    group = "group_string_or_integer"
    data = "Hello world!"

    ブループリントの各エントリーを説明します。

    • path - 必須 - 作成するファイルへのパスを入力します。/etc ディレクトリー下の絶対パスである必要があります。
    • mode - オプション - ファイルのアクセスパーミッションを 8 進数形式で設定します。パーミッションを指定しない場合、デフォルトで 0644 に設定されます。先頭のゼロは任意です。
    • user - オプション - ユーザーをファイルの所有者として設定します。ユーザーを指定しない場合は、デフォルトで root に設定されます。ユーザーは文字列または整数として指定できます。
    • group - オプション - グループをファイルの所有者として設定します。グループを指定しない場合は、デフォルトで root になります。グループは文字列または整数として指定できます。
    • data - オプション - プレーンテキストファイルの内容を指定します。コンテンツを指定しない場合は、空のファイルが作成されます。

1.3.9. RHEL Image Builder によってインストールされるパッケージ

RHEL Image Builder を使用してシステムイメージを作成すると、システムは一連のベースパッケージグループをインストールします。

注記

ブループリントにコンポーネントを追加する場合は、追加したコンポーネント内のパッケージが他のパッケージコンポーネントと競合しないようにしてください。そうしないと、システムは依存関係を解決できず、カスタマイズされたイメージの作成に失敗します。次のコマンドを実行して、パッケージ間に競合がないかどうかを確認できます。

# composer-cli blueprints depsolve BLUEPRINT-NAME

デフォルトでは、RHEL Image Builder は Core グループをパッケージの基本リストとして使用します。

表1.3 イメージタイプの作成をサポートするデフォルトパッケージ
イメージタイプデフォルトパッケージ

ami

checkpolicy、chrony、cloud-init、cloud-utils-growpart、@Core、dhcp-client、gdisk、insights-client、kernel、langpacks-en、net-tools、NetworkManager、redhat-release、redhat-release-eula、rng-tools、rsync、selinux-policy-targeted、tar、yum-utils

openstack

@core、langpacks-en

qcow2

@core, chrony, dnf, kernel, yum, nfs-utils, dnf-utils, cloud-init, python3-jsonschema, qemu-guest-agent, cloud-utils-growpart, dracut-norescue, tar, tcpdump, rsync, dnf-plugin-spacewalk, rhn-client-tools, rhnlib, rhnsd, rhn-setup, NetworkManager, dhcp-client, cockpit-ws, cockpit-system, subscription-manager-cockpit, redhat-release, redhat-release-eula, rng-tools, insights-client

tar

policycoreutils、selinux-policy-targeted

vhd

@core、langpacks-en

vmdk

@core、chrony、cloud-init、firewalld、langpacks-en、open-vm-tools、selinux-policy-targeted

edge-commit

redhat-releaseglibcglibc-minimal-langpacknss-altfilesdracut-config-genericdracut-networkbasesystembashplatform-pythonshadow-utilschronysetupshadow-utilssudosystemdcoreutilsutil-linuxcurlvim-minimalrpmrpm-ostreepolkitlvm2cryptsetuppinentrye2fsprogsdosfstoolskeyutilsgnupg2attrxzgzipfirewalldiptablesNetworkManagerNetworkManager-wifiNetworkManager-wwanwpa_supplicanttraceroutehostnameiprouteiputilsopenssh-clientsprocps-ngrootfilesopenssh-serverpasswdpolicycoreutilspolicycoreutils-python-utilsselinux-policy-targetedsetools-consolelesstarrsyncusbguardbash-completiontmuxima-evm-utilsauditpodmancontainernetworking-pluginscontainer-selinuxskopeocriuslirp4netnsfuse-overlayfsclevisclevis-dracutclevis-luksgreenbootgreenboot-default-health-checksfdo-clientfdo-owner-clisos

edge-container

dnf、dosfstools、e2fsprogs、glibc、lorax-templates-generic、lorax-templates-rhel、lvm2、policycoreutils、python36、python3-iniparse、qemu-img、selinux-policy-targeted、systemd、tar、xfsprogs、xz

edge-installer

aajohan-comfortaa-fonts、abattis-cantarell-fonts、alsa-firmware、alsa-tools-firmware、anaconda、anaconda-install-env-deps、anaconda-widgets、audit、bind-utils、bitmap-fangsongti-fonts、bzip2、cryptsetup、dbus-x11、dejavu-sans-fonts、dejavu-sans-mono-fonts、device-mapper-persistent-data、dnf、dump、ethtool、fcoe-utils、ftp、gdb-gdbserver、gdisk、gfs2-utils、glibc-all-langpacks、google-noto-sans-cjk-ttc-fonts、gsettings-desktop-schemas、hdparm、hexedit、initscripts、ipmitool、iwl3945-firmware、iwl4965-firmware、iwl6000g2a-firmware、iwl6000g2b-firmware、jomolhari-fonts、kacst-farsi-fonts、kacst-qurn-fonts、kbd、kbd-misc、kdump-anaconda-addon、khmeros-base-fonts、libblockdev-lvm-dbus、libertas-sd8686-firmware、libertas-sd8787-firmware、libertas-usb8388-firmware、libertas-usb8388-olpc-firmware、libibverbs、libreport-plugin-bugzilla、libreport-plugin-reportuploader、libreport-rhel-anaconda-bugzilla、librsvg2、linux-firmware、lklug-fonts、lldpad、lohit-assamese-fonts、lohit-bengali-fonts、lohit-devanagari-fonts、lohit-gujarati-fonts、lohit-gurmukhi-fonts、lohit-kannada-fonts、lohit-odia-fonts、lohit-tamil-fonts、lohit-telugu-fonts、lsof、madan-fonts、metacity、mtr、mt-st、net-tools、nmap-ncat、nm-connection-editor、nss-tools、openssh-server、oscap-anaconda-addon、pciutils、perl-interpreter、pigz、python3-pyatspi、rdma-core、redhat-release-eula、rpm-ostree、rsync、rsyslog、sg3_utils、sil-abyssinica-fonts、sil-padauk-fonts、sil-scheherazade-fonts、smartmontools、smc-meera-fonts、spice-vdagent、strace、system-storage-manager、thai-scalable-waree-fonts、tigervnc-server-minimal、tigervnc-server-module、udisks2、udisks2-iscsi、usbutils、vim-minimal、volume_key、wget、xfsdump、xorg-x11-drivers、xorg-x11-fonts-misc、xorg-x11-server-utils、xorg-x11-server-Xorg、xorg-x11-xauth

edge-simplified-installer

attr、basesystem、binutils、bsdtar、clevis-dracut、clevis-luks、cloud-utils-growpart、coreos-installer、coreos-installer-dracut、coreutils、device-mapper-multipath、dnsmasq、dosfstools、dracut-live、e2fsprogs、fcoe-utils、fdo-init、gzip、ima-evm-utils、iproute、iptables、iputils、iscsi-initiator-utils、keyutils、lldpad、lvm2、passwd、policycoreutils、policycoreutils-python-utils、procps-ng、rootfiles、setools-console、sudo、traceroute、util-linux

image-installer

aajohan-comfortaa-fontsabattis-cantarell-fontsalsa-firmwarealsa-tools-firmwareanacondaanaconda-dracutanaconda-install-env-depsanaconda-widgetsauditbind-utilsbitmap-fangsongti-fontsbzip2cryptsetupcurldbus-x11dejavu-sans-fontsdejavu-sans-mono-fontsdevice-mapper-persistent-datadmidecodednfdracut-config-genericdracut-networkefibootmgrethtoolfcoe-utilsftpgdb-gdbservergdiskglibc-all-langpacksgnome-kioskgoogle-noto-sans-cjk-ttc-fontsgrub2-toolsgrub2-tools-extragrub2-tools-minimalgrubbygsettings-desktop-schemashdparmhexedithostnameinitscriptsipmitooliwl1000-firmwareiwl100-firmwareiwl105-firmwareiwl135-firmwareiwl2000-firmwareiwl2030-firmwareiwl3160-firmwareiwl5000-firmwareiwl5150-firmwareiwl6000g2a-firmwareiwl6000g2b-firmwareiwl6050-firmwareiwl7260-firmwarejomolhari-fontskacst-farsi-fontskacst-qurn-fontskbdkbd-misckdump-anaconda-addonkernelkhmeros-base-fontslesslibblockdev-lvm-dbuslibibverbslibreport-plugin-bugzillalibreport-plugin-reportuploaderlibrsvg2linux-firmwarelklug-fontslldpadlohit-assamese-fontslohit-bengali-fontslohit-devanagari-fontslohit-gujarati-fontslohit-gurmukhi-fontslohit-kannada-fontslohit-odia-fontslohit-tamil-fontslohit-telugu-fontslsofmadan-fontsmtrmt-stnet-toolsnfs-utilsnmap-ncatnm-connection-editornss-toolsopenssh-clientsopenssh-serveroscap-anaconda-addonostreepciutilsperl-interpreterpigzplymouthprefixdevnamepython3-pyatspirdma-coreredhat-release-eularng-toolsrpcbindrpm-ostreersyncrsyslogselinux-policy-targetedsg3_utilssil-abyssinica-fontssil-padauk-fontssil-scheherazade-fontssmartmontoolssmc-meera-fontsspice-vdagentstracesystemdtarthai-scalable-waree-fontstigervnc-server-minimaltigervnc-server-moduleudisks2,udisks2-iscsi,usbutils,vim-minimalvolume_keywgetxfsdumpxfsprogsxorg-x11-driversxorg-x11-fonts-miscxorg-x11-server-utilsxorg-x11-server-Xorgxorg-x11-xauthxz

edge-raw-image

dnf、dosfstools、e2fsprogs、glibc、lorax-templates-generic、lorax-templates-rhel、lvm2、policycoreutils、python36、python3-iniparse、qemu-img、selinux-policy-targeted、systemd、tar、xfsprogs、xz

gce

@core、langpacks-en、acpid、dhcp-client、dnf-automatic、net-tools、python3、rng-tools、tar、vim

1.3.10. カスタムイメージで有効なサービス

Image Builder を使用してカスタムイメージを設定する場合、イメージが使用するデフォルトのサービスは次のように決定されます。

  • osbuild-composer ユーティリティーを使用する RHEL リリース
  • イメージの種類

たとえば、ami イメージタイプは、デフォルトで sshdchronyd、および cloud-init サービスを有効にします。これらのサービスが有効になっていない場合、カスタムイメージは起動しません。

表1.4 イメージタイプの作成をサポートするために有効になっているサービス
イメージタイプデフォルトで有効化されているサービス

ami

sshd, cloud-init, cloud-init-local, cloud-config, cloud-final

openstack

sshd, cloud-init, cloud-init-local, cloud-config, cloud-final

qcow2

cloud-init

rhel-edge-commit

デフォルトでは、追加のサービスは有効になりません。

tar

デフォルトでは、追加のサービスは有効になりません。

vhd

sshd, chronyd, waagent, cloud-init, cloud-init-local, cloud-config, cloud-final

vmdk

sshd、chronyd、vmtoolsd、cloud-init

注記:システムの起動時に有効にするサービスをカスタマイズできます。ただし、カスタマイズは、前述のイメージタイプに対してデフォルトで有効になっているサービスを上書きしません。

1.4. RHEL Image Builder Web コンソールインターフェイスを使用したシステムイメージの作成

RHEL Image Builder は、カスタムのシステムイメージを作成するツールです。RHEL Image Builder を制御してカスタムシステムイメージを作成する場合は、Web コンソールインターフェイスを使用できます。ただし、コマンドラインインターフェイスの方が提供している機能が多いため、コマンドラインインターフェイスを使用することが推奨されます。

1.4.1. RHEL Web コンソールでの RHEL Image Builder ダッシュボードへのアクセス

RHEL Web コンソール用の cockpit-composer プラグインを使用すると、グラフィカルインターフェイスを使用して Image Builder のブループリントと設定を管理できます。

前提条件

  • システムへの root アクセス権限がある。
  • RHEL Image Builder がインストールされている。
  • cockpit-composer パッケージがインストールされている。

手順

  1. ホスト上で、Web ブラウザーで https://<_localhost_>:9090/ を開きます。
  2. root ユーザーとして Web コンソールにログインします。
  3. RHEL Image Builder のコントロールを表示するには、ウィンドウの左上隅にある Image Builder ボタンをクリックします。

    RHEL Image Builder ダッシュボードが開き、既存のブループリントがあればそれがリストされます。

1.4.2. Web コンソールインターフェイスでのブループリントの作成

カスタマイズした RHEL システムイメージをビルドするには、ブループリントを作成する必要があります。利用可能なカスタマイズはすべて任意です。次の方法を使用して、カスタマイズしたブループリントを作成できます。

注記

これらのブループリントのカスタマイズは、Red Hat Enterprise Linux 9.2 以降のバージョンおよび Red Hat Enterprise Linux 8.8 以降のバージョンで利用できます。

前提条件

手順

  1. 右上隅にある Create Blueprint をクリックします。

    ブループリントの名前と説明のフィールドを含むダイアログウィザードが開きます。

  2. Details ページで以下を行います。

    1. ブループリントの名前と、必要に応じてその説明を入力します。
    2. Next をクリックします。
  3. オプション: Packages ページで以下を行います。

    1. Available packages の検索で、パッケージ名を入力します。
    2. > ボタンをクリックして Chosen packages フィールドに移動します。
    3. 前の手順を繰り返して、必要な数のパッケージを検索して含めます。
    4. Next をクリックします。

      注記

      特に指定がない限り、これらのカスタマイズはすべてオプションです。

  4. Kernel ページで、カーネル名とコマンドライン引数を入力します。
  5. File system ページで、お使いのイメージファイルシステムに合わせて Use automatic partitioning または Manually configure partitions を選択します。パーティションを手動で設定するには、次の手順を実行します。

    1. Manually configure partitions ボタンをクリックします。

      Configure partitions セクションが開き、Red Hat 標準およびセキュリティーガイドに基づく設定が表示されます。

    2. ドロップダウンメニューから、パーティションを設定するための詳細を入力します。

      1. Mount point フィールドに、以下のマウントポイントタイプオプションのいずれかを選択します。

        • / - ルートマウントポイント
        • /app
        • /boot
        • /data
        • /home
        • /opt
        • /srv/
        • /usr
        • /usr/local
        • /var

          /tmp などの追加のパスを Mount point に追加することもできます。例: 接頭辞 /var と、追加パス /tmp で、/var/tmp になります。

          注記

          選択した Mount point のタイプに応じて、ファイルシステムのタイプが xfs に変わります。

      2. ファイルシステムの Minimum size partition フィールドに、必要な最小パーティションサイズを入力します。Minimum size ドロップダウンメニューでは、GiBMiBKiB などの一般的なサイズ単位を使用できます。デフォルトの単位は GiB です。

        注記

        Minimum size とは、作業用イメージの作成には小さすぎる場合にも RHEL Image Builder がパーティションサイズを増加できるという意味です。

    3. さらにパーティションを追加するには、Add partition ボタンをクリックします。以下のエラーメッセージが表示された場合は、以下を行います。Duplicate partitions:Only one partition at each mount point can be created.

      1. Remove ボタンをクリックして、重複したパーティションを削除します。
      2. 作成するパーティションの新しいマウントポイントを選択します。
    4. パーティションの設定が完了したら、Next をクリックします。
  6. Services ページで、サービスを有効または無効にします。

    1. 有効または無効にするサービス名をコンマまたはスペースで区切るか、Enter キーを押して入力します。Next をクリックします。
    2. Enabled services を入力します。
    3. Disabled services を入力します。
  7. Firewall ページで、ファイアウォールを設定します。

    1. Ports と、有効または無効にするファイアウォールサービスを入力します。
    2. Add zone ボタンをクリックして、各ゾーンのファイアウォールルールを個別に管理します。Next をクリックします。
  8. Users ページで、以下の手順に従ってユーザーを追加します。

    1. Add user をクリックします。
    2. UsernamePassword、および SSH key を入力します。Server administrator チェックボックスをクリックして、ユーザーを特権ユーザーとしてマークすることもできます。Next をクリックします。
  9. Groups ページで、次の手順を実行してグループを追加します。

    1. Add groups ボタンをクリックします。

      1. Group nameGroup ID を入力します。グループをさらに追加できます。Next をクリックします。
  10. SSH keys ページで、キーを追加します。

    1. Add key ボタンをクリックします。

      1. SSH キーを入力します。
      2. User を入力します。Next をクリックします。
  11. Timezone ページで、タイムゾーンを設定します。

    1. Timezone フィールドに、システムイメージに追加するタイムゾーンを入力します。たとえば、次のタイムゾーン形式を追加します。"US/Eastern"。

      タイムゾーンを設定しない場合、システムはデフォルトとして協定世界時 (UTC) を使用します。

    2. NTP servers を入力します。Next をクリックします。
  12. Locale ページで、以下の手順を実行します。

    1. Keyboard 検索フィールドに、システムイメージに追加するパッケージ名を入力します。たとえば、["en_US.UTF-8"] と入力します。
    2. Languages 検索フィールドに、システムイメージに追加するパッケージ名を入力します。たとえば、"us" と入力します。Next をクリックします。
  13. Others ページで、次の手順を実行します。

    1. Hostname フィールドに、システムイメージに追加するホスト名を入力します。ホスト名を追加しない場合、オペレーティングシステムによってホスト名が決定されます。
    2. Simplifier Installer イメージでのみ必須:Installation Devices フィールドに、システムイメージの有効なノードを入力します。たとえば、dev/sda1 と入力します。Next をクリックします。
  14. FDO 用のイメージをビルドする場合にのみ必須: FIDO device onboarding ページで、次の手順を実行します。

    1. Manufacturing server URL フィールドに、次の情報を入力します。

      1. DIUN public key insecure フィールドに、セキュアでない公開鍵を入力します。
      2. DIUN public key hash フィールドに、公開鍵ハッシュを入力します。
      3. DIUN public key root certs フィールドに、公開鍵ルート証明書を入力します。Next をクリックします。
  15. OpenSCAP ページで、次の手順を実行します。

    1. Datastream フィールドに、システムイメージに追加する datastream 修復手順を入力します。
    2. Profile ID フィールドに、システムイメージに追加する profile_id セキュリティープロファイルを入力します。Next をクリックします。
  16. Ignition を使用するイメージをビルドする場合にのみ必須: Ignition ページで、次の手順を実行します。

    1. Firstboot URL フィールドに、システムイメージに追加するパッケージ名を入力します。
    2. Embedded Data フィールドに、ファイルをドラッグまたはアップロードします。Next をクリックします。
  17. .Review ページで、ブループリントの詳細を確認します。Create をクリックします。

RHEL Image Builder ビューが開き、既存のブループリントのリストが表示されます。

1.4.3. RHEL Image Builder Web コンソールインターフェイスでのブループリントのインポート

既存のブループリントをインポートして使用できます。システムがすべての依存関係を自動的に解決します。

前提条件

  • ブラウザーの Web コンソールから RHEL Image Builder アプリケーションを開いている。
  • RHEL Image Builder Web コンソールインターフェイスで使用するためにインポートするブループリントがある。

手順

  1. RHEL Image Builder ダッシュボードで、Import blueprint をクリックします。Import blueprint が開きます。
  2. Upload フィールドから、既存のブループリントをドラッグまたはアップロードします。TOMLJSON のどちらかの形式のブループリントを使用できます。
  3. Import をクリックします。ダッシュボードに、インポートしたブループリントがリストされます。

検証

インポートしたブループリントをクリックすると、インポートしたブループリントのすべてのカスタマイズを含むダッシュボードにアクセスできます。

  • インポートしたブループリント用に選択されているパッケージを確認するには、Packages タブに移動します。

    • すべてのパッケージの依存関係を一覧表示するには、All をクリックします。リストは検索可能で、並べ替えることもできます。

次のステップ

  • オプション: カスタマイズを変更するには、以下を実行します。

    • Customizations ダッシュボードから、変更するカスタマイズをクリックします。必要に応じて、Edit blueprint をクリックして、利用可能なすべてのカスタマイズオプションに移動できます。

1.4.4. RHEL Image Builder Web コンソールインターフェイスからのブループリントのエクスポート

ブループリントをエクスポートして、別のシステムでカスタマイズを使用できます。ブループリントは TOML または JSON 形式でエクスポートできます。どちらの形式も CLI だけでなく API インターフェイスでも使用できます。

前提条件

  • ブラウザーの Web コンソールから RHEL Image Builder アプリケーションを開いている。
  • エクスポートするブループリントがある。

手順

  1. Image Builder ダッシュボードで、エクスポートするブループリントを選択します。
  2. Export blueprint をクリックします。Export blueprint が開きます。
  3. Export ボタンをクリックしてブループリントをファイルとしてダウンロードするか、Copy ボタンをクリックしてブループリントをクリップボードにコピーします。

    1. オプション: Copy ボタンをクリックしてブループリントをコピーします。

検証

  • エクスポートしたブループリントをテキストエディターで開き、検査して確認します。

1.4.5. Web コンソールインターフェイスで RHEL Image Builder を使用してシステムイメージを作成する

次の手順を実行すると、ブループリントからカスタマイズされた RHEL システムイメージを作成できます。

前提条件

  • ブラウザーの Web コンソールから RHEL Image Builder アプリケーションを開いている。
  • ブループリントを作成している。

手順

  1. RHEL Image Builder ダッシュボードで、blueprint タブをクリックします。
  2. ブループリントのテーブルで、イメージをビルドするブループリントを見つけます。
  3. 選択したブループリントの右側で、Create Image をクリックします。Create image ダイアログウィザードが開きます。
  4. Image output ページで、次の手順を実行します。

    1. Select a blueprint リストから、必要なイメージのタイプを選択します。
    2. Image output type リストから、必要なイメージの出力タイプを選択します。

      選択したイメージの種類に応じて、さらに詳細を追加する必要があります。

  5. Next をクリックします。
  6. Review ページで、イメージの作成に関する詳細を確認し、Create image をクリックします。

    イメージのビルドが開始され、完了するまでに最大 20 分かかります。

検証

イメージのビルドが完了したら、次のことが可能になります。

  • イメージをダウンロードします。

    • RHEL Image Builder ダッシュボードで、Node options (⫶) メニューをクリックし、Download image を選択します。
  • イメージのログをダウンロードして要素を検査し、問題がないかどうかを確認します。

    • RHEL Image Builder ダッシュボードで、Node options (⫶) メニューをクリックし、Download logs を選択します。

1.5. RHEL Image Builder を使用したクラウドイメージの準備とアップロード

RHEL Image Builder は、さまざまなクラウドプラットフォームですぐに使用できるカスタムシステムイメージを作成できます。カスタマイズした RHEL システムイメージをクラウドで使用するには、指定の出力タイプを使用して RHEL Image Builder でシステムイメージを作成し、イメージをアップロードするようにシステムを設定し、クラウドアカウントへイメージをアップロードします。RHEL Web コンソールの Image Builder アプリケーションを介して、カスタマイズされたイメージクラウドをプッシュできます。これは、AWSMicrosoft Azure クラウドなど、Red Hat サポート対象のサービスプロバイダーの一部で利用できます。AWS Cloud AMI に直接イメージを作成して自動的にアップロードする および Microsoft Azure クラウドに直接 VHD イメージを作成して自動的にアップロードする を参照してください。

1.5.1. AMI イメージの準備と AWS へのアップロード

RHEL Image Builder を使用してカスタムイメージを作成し、そのイメージを手動または自動で AWS クラウドにアップロードできます。

1.5.1.1. AWS AMI イメージを手動でアップロードする準備

AWS AMI イメージをアップロードする前に、イメージをアップロードするためのシステムを設定する必要があります。

前提条件

手順

  1. Python 3 および pip ツールをインストールします。

    # yum install python3 python3-pip
  2. pipAWS コマンドラインツール をインストールします。

    # pip3 install awscli
  3. プロファイルを設定します。ターミナルで、認証情報、リージョン、および出力形式を指定するように求められます。

    $ aws configure
    AWS Access Key ID [None]:
    AWS Secret Access Key [None]:
    Default region name [None]:
    Default output format [None]:
  4. バケットの名前を定義し、バケットを作成します。

    $ BUCKET=bucketname
    $ aws s3 mb s3://$BUCKET

    bucketname は、実際のバケット名に置き換えます。この名前は、グローバルで一意となるように指定する必要があります。上記で、バケットが作成されます。

  5. S3 バケットへのアクセス許可を付与するには、AWS Identity and Access Management (IAM) で vmimport S3 ロールを作成します (まだ作成していない場合)。

    1. 信頼ポリシーの設定で、JSON 形式で trust-policy.json ファイルを作成します。以下に例を示します。

      {
          "Version": "2022-10-17",
          "Statement": [{
              "Effect": "Allow",
              "Principal": {
                  "Service": "vmie.amazonaws.com"
              },
              "Action": "sts:AssumeRole",
              "Condition": {
                  "StringEquals": {
                      "sts:Externalid": "vmimport"
                  }
              }
          }]
      }
    2. ロールポリシーの設定を含む role-policy.json ファイルを JSON 形式で作成します。以下に例を示します。

      {
          "Version": "2012-10-17",
          "Statement": [{
              "Effect": "Allow",
              "Action": ["s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket"],
              "Resource": ["arn:aws:s3:::%s", "arn:aws:s3:::%s/"] }, { "Effect": "Allow", "Action": ["ec2:ModifySnapshotAttribute", "ec2:CopySnapshot", "ec2:RegisterImage", "ec2:Describe"],
              "Resource": "*"
          }]
      }
      $BUCKET $BUCKET
    3. trust-policy.json ファイルを使用して、Amazon Web Services アカウントのロールを作成します。

      $ aws iam create-role --role-name vmimport --assume-role-policy-document file://trust-policy.json
    4. role-policy.json ファイルを使用して、インラインポリシードキュメントを埋め込みます。

      $ aws iam put-role-policy --role-name vmimport --policy-name vmimport --policy-document file://role-policy.json
1.5.1.2. CLI を使用して AMI イメージを AWS に手動でアップロードする

RHEL Image Builder を使用して ami イメージをビルドし、CLI を使用して Amazon AWS Cloud サービスプロバイダーに直接手動でアップロードすることができます。

前提条件

  • AWS IAM アカウントマネージャーに Access Key ID を設定している。
  • 書き込み可能な S3 バケット を準備している。
  • 定義済みの青写真がある。

手順

  1. テキストエディターを使用して、次の内容の設定ファイルを作成します。

    provider = "aws"
    [settings]
    accessKeyID = "AWS_ACCESS_KEY_ID"
    secretAccessKey = "AWS_SECRET_ACCESS_KEY"
    bucket = "AWS_BUCKET"
    region = "AWS_REGION"
    key = "IMAGE_KEY"

    フィールドの値を accessKeyIDsecretAccessKeybucket、および region の認証情報に置き換えます。IMAGE_KEY 値は、EC2 にアップロードする仮想マシンイメージの名前です。

  2. ファイルを CONFIGURATION-FILE.toml として保存し、テキストエディターを閉じます。
  3. Compose を開始して AWS にアップロードします。

    # composer-cli compose start blueprint-name image-type image-key configuration-file.toml

    以下を置き換えます。

    • blueprint-name は、作成したブループリントの名前に置き換えます。
    • image-type は、ami イメージタイプに置き換えます。
    • image-key は、EC2 にアップロードする仮想マシンイメージの名前に置き換えます。
    • configuration-file.toml は、クラウドプロバイダーの設定ファイルの名前に置き換えます。

      注記

      カスタマイズしたイメージの送信先となるバケットの正しい AWS Identity and Access Management (IAM) 設定が必要です。イメージをアップロードする前にバケットにポリシーを設定しておく必要があります。

  4. イメージビルドのステータスを確認します。

    # composer-cli compose status

    イメージのアップロードプロセスが完了すると、"FINISHED" ステータスが表示されます。

検証

イメージのアップロードが成功したことを確認するには、以下を行います。

  1. メニューで EC2 にアクセスし、AWS コンソールで正しいリージョンを選択します。イメージが正常にアップロードされたことを示すには、イメージが available ステータスになっている必要があります。
  2. Dashboard でイメージを選択し、起動 をクリックします。
1.5.1.3. イメージを作成して AWS Cloud AMI に自動的にアップロードする

RHEL Image Builder を使用して (.raw) イメージを作成し、Upload to AWS チェックボックスをオンにして、作成した出力イメージを Amazon AWS Cloud AMI サービスプロバイダーに直接自動的にプッシュすることができます。

前提条件

手順

  1. RHEL Image Builder のダッシュボードで、以前に作成した ブループリント名 をクリックします。
  2. Images タブを選択します。
  3. Create Image をクリックして、カスタマイズしたイメージを作成します。

    Create Image ウィンドウが開きます。

    1. Type ドロップダウンメニューから、Amazon Machine Image Disk (.raw) を選択します。
    2. イメージを AWS Cloud にアップロードするには、Upload to AWS チェックボックスをオンして、Next をクリックします。
    3. AWS へのアクセスを認証するには、対応するフィールドに AWS access key ID および AWS secret access key を入力します。Next をクリックします。

      注記

      新規アクセスキー ID を作成する場合にのみ、AWS シークレットアクセスキーを表示できます。秘密鍵が分からない場合は、新しいアクセスキー ID を生成します。

    4. Image name フィールドにイメージ名を、Amazon S3 bucket name フィールドに Amazon バケット名を入力して、カスタマイズイメージを追加するバケットの AWS region フィールドを入力します。Next をクリックします。
    5. 情報を確認し、Finish をクリックします。

      必要に応じて、Back をクリックして誤った情報を変更します。

      注記

      カスタマイズイメージを送信するバケットの正しい IAM 設定が必要です。この手順では IAM のインポートとエクスポートを使用するため、バケットにイメージをアップロードする前にバケットに ポリシー を設定する必要があります。詳細は、IAM ユーザーの必要なパーミッション を参照してください。

  4. 右上のポップアップで、保存の進行状況が通知されます。イメージ作成の開始、イメージ作成の進捗、およびその後の AWS Cloud にアップロードに関する情報も通知されます。

    プロセスが完了すると、Image build complete のステータスが表示されます。

  5. ブラウザーで、Service→EC2 にアクセスします。

    1. AWS コンソールのダッシュボードメニューで、正しいリージョン を選択します。イメージのステータスは、アップロードされていることを示す Available でなければなりません。
    2. AWS ダッシュボードでイメージを選択し、Launch をクリックします。
  6. 新しいウィンドウが開きます。イメージを開始するために必要なリソースに応じて、インスタンスタイプを選択します。Review and Launch をクリックします。
  7. インスタンスの開始の詳細を確認します。変更が必要な場合は、各セクションを編集できます。起動 をクリックします。
  8. インスタンスを起動する前に、インスタンスにアクセスするための公開鍵を選択します。

    既存のキーペアを使用するか、キーペアーを新規作成します。

    次の手順に従って、EC2 で新規キーペアを作成し、新規インスタンスにアタッチします。

    1. ドロップダウンメニューリストから、Create a new key pair を選択します。
    2. 新しいキーペアに名前を入力します。新しいキーペアが生成されます。
    3. Download Key Pair をクリックして、新しいキーペアをローカルシステムに保存します。
  9. Launch Instance をクリックしてインスタンスを起動します。

    Initializing と表示されるインスタンスのステータスを確認できます。

  10. インスタンスのステータスが running になると、Connect ボタンが有効になります。
  11. Connect をクリックします。ウィンドウが表示され、SSH を使用して接続する方法の説明が表示されます。

    1. 優先する接続方法として スタンドアロン SSH クライアント を選択し、ターミナルを開きます。
    2. 秘密鍵を保存する場所で、SSH が機能するために鍵が公開されていることを確認してください。これには、以下のコマンドを実行します。

      $ chmod 400 <_your-instance-name.pem_>
    3. パブリック DNS を使用してインスタンスに接続します。

      $ ssh -i <_your-instance-name.pem_> ec2-user@<_your-instance-IP-address_>
    4. yes と入力して、接続の続行を確定します。

      その結果、SSH 経由でインスタンスに接続されます。

検証

  • SSH でインスタンスに接続している間にアクションが実行できるかどうかを確認します。

1.5.2. VHD イメージを準備して Microsoft Azure にアップロードする

RHEL Image Builder を使用すると、カスタムイメージを作成し、そのイメージを手動または自動で Microsoft Azure クラウドにアップロードできます。

1.5.2.1. Microsoft Azure VHD イメージを手動でアップロードする準備

Microsoft Azure クラウドに手動でアップロードできる VHD イメージを作成するには、RHEL Image Builder を使用できます。

前提条件

  • Microsoft Azure リソースグループとストレージアカウントがある。
  • Python がインストールされている。AZ CLI ツールは Python に依存しています。

手順

  1. Microsoft リポジトリーキーをインポートします。

    # rpm --import https://packages.microsoft.com/keys/microsoft.asc
  2. 次の情報を使用して、ローカルの azure-cli.repo リポジトリーを作成します。azure-cli.repo リポジトリーを /etc/yum.repos.d/ に保存します。

    [azure-cli]
    name=Azure CLI
    baseurl=https://packages.microsoft.com/yumrepos/vscode
    enabled=1
    gpgcheck=1
    gpgkey=https://packages.microsoft.com/keys/microsoft.asc
  3. Microsoft Azure CLI をインストールします。

    # yumdownloader azure-cli
    # rpm -ivh --nodeps azure-cli-2.0.64-1.el7.x86_64.rpm
    注記

    Microsoft Azure CLI パッケージのダウンロードバージョンは、現在利用可能なバージョンによって異なる場合があります。

  4. Microsoft Azure CLI を実行します。

    $ az login

    ターミナルに次のメッセージが表示されます。Note, we have launched a browser for you to login.For old experience with device code, use "az login --use-device-code次に、ターミナルは、ログインできる場所から https://microsoft.com/devicelogin へのリンクのあるブラウザーを開きます。

    注記

    リモート (SSH) セッションを実行している場合、ログインページのリンクはブラウザーで開きません。この場合、リンクをブラウザーにコピーしてログインし、リモートセッションを認証できます。サインインするには、Web ブラウザーを使用してページ https://microsoft.com/devicelogin を開き、デバイスコードを入力して認証します。

  5. Microsoft Azure のストレージアカウントのキーをリスト表示します。

    $ az storage account keys list --resource-group <resource_group_name> --account-name <storage_account_name>

    resource-group-name を Microsoft Azure リソースグループの名前に置き換え、storage-account-name を Microsoft Azure ストレージアカウントの名前に置き換えます。

    注記

    次のコマンドを使用して、使用可能なリソースを一覧表示できます。

    $ az resource list

    上記のコマンドの出力にある値 key1 をメモします。

  6. ストレージコンテナーを作成します。

    $ az storage container create --account-name <storage_account_name>\
    --account-key <key1_value> --name <storage_account_name>

    storage-account-name は、ストレージアカウント名に置き換えます。

関連情報

1.5.2.2. VHD イメージを Microsoft Azure クラウドに手動でアップロードする

カスタマイズした VHD イメージを作成したら、それを手動で Microsoft Azure クラウドにアップロードできます。

前提条件

  • Microsoft Azure VHD イメージをアップロードするようにシステムを設定している。Microsoft Azure VHD イメージのアップロードの準備 を参照してください。
  • RHEL Image Builder で Microsoft Azure VHD イメージを作成している。

    • GUI で、Azure Disk Image (.vhd) イメージタイプを使用します。
    • CLI で、vhd 出力タイプを使用します。

手順

  1. イメージを Microsoft Azure にプッシュし、そこからインスタンスを作成します。

    $ az storage blob upload --account-name <_account_name_> --container-name <_container_name_> --file <_image_-disk.vhd> --name <_image_-disk.vhd> --type page
    ...
  2. Microsoft Azure Blob ストレージへのアップロードが完了したら、そこから Microsoft Azure イメージを作成します。

    $ az image create --resource-group <_resource_group_name_> --name <_image_>-disk.vhd --os-type linux --location <_location_> --source https://$<_account_name_>.blob.core.windows.net/<_container_name_>/<_image_>-disk.vhd
     - Running ...
    注記

    RHEL Image Builder で作成するイメージは、V1 = BIOS と V2 = UEFI の両方のインスタンスタイプをサポートするハイブリッドイメージを生成するため、--hyper-v-generation 引数を指定できます。デフォルトのインスタンスタイプは V1 です。

検証

  1. Microsoft Azure ポータル、または以下のようなコマンドを使用して、インスタンスを作成します。

    $ az vm create --resource-group <_resource_group_name_> --location <_location_> --name <_vm_name_> --image <_image_>-disk.vhd --admin-username azure-user --generate-ssh-keys
     - Running ...
  2. 秘密鍵を使用して、SSH 経由で、作成されたインスタンスにアクセスします。azure-user としてログインします。このユーザー名は前の手順で設定したものです。

関連情報

1.5.2.3. VHD イメージを作成して Microsoft Azure クラウドに自動的にアップロードする

RHEL Image Builder を使用して .vhd イメージを作成すると、Microsoft Azure クラウドサービスプロバイダーの Blob Storage に自動的にアップロードされます。

前提条件

手順

  1. RHEL Image Builder ダッシュボードで、使用するブループリントを選択します。
  2. Images タブをクリックします。
  3. Create Image をクリックして、カスタマイズした .vhd イメージを作成します。

    Create image ウィザードが開きます。

    1. Type ドロップダウンメニューリストから Microsoft Azure (.vhd) を選択します。
    2. イメージを Microsoft Azure クラウドにアップロードするには、Upload to Azure チェックボックスをオンします。
    3. Image Size を入力し、Next をクリックします。
  4. Upload to Azure ページで、次の情報を入力します。

    1. 認証ページで、次のように入力します。

      1. Storage account の名前。これは、Microsoft Azure portalStorage account ページにあります。
      2. Storage access key:これは、Access Key ストレージページにあります。
      3. Next をクリックします。
    2. Authentication ページで、次のように入力します。

      1. イメージ名
      2. Storage container。これは、イメージのアップロード先の Blob コンテナーです。Microsoft Azure portalBlob service セクションにあります。
      3. Next をクリックします。
  5. Review ページで Create をクリックします。RHEL Image Builder が起動し、アップロードプロセスが開始します。

    Microsoft Azure Cloud にプッシュしたイメージにアクセスします。

  6. Microsoft Azure ポータル にアクセスします。
  7. 検索バーに "storage account" と入力し、リストから Storage accounts をクリックします。
  8. 検索バーに "Images" と入力し、Services の下にある最初のエントリーを選択します。Image Dashboard にリダイレクトされます。
  9. ナビゲーションパネルで、Containers をクリックします。
  10. 作成したコンテナーを見つけます。コンテナー内には、RHEL Image Builder を使用して作成およびプッシュした .vhd ファイルがあります。

検証

  1. 仮想マシンイメージを作成して起動できることを確認します。

    1. 検索バーに images account と入力し、リストから Images をクリックします。
    2. +Create をクリックします。
    3. ドロップダウンリストから、前に使用したリソースグループを選択します。
    4. イメージの名前を入力します。
    5. OS typeLinux を選択します。
    6. VM generationGen 2 を選択します。
    7. Storage BlobBrowse をクリックし、VHD ファイルに到達するまでストレージアカウントとコンテナーをクリックします。
    8. ページの最後にある Select をクリックします。
    9. Account Type を選択します (例: Standard SSD)
    10. Review + Create をクリックし、Create をクリックします。イメージが作成されるまでしばらく待機します。
  2. 仮想マシンを起動するには、次の手順に従います。

    1. Go to resource をクリックします。
    2. ヘッダーのメニューバーから + Create VM をクリックします。
    3. 仮想マシンの名前を入力します。
    4. Size セクションと Administrator account セクションに入力します。
    5. Review + Create をクリックし、Create をクリックします。デプロイメントの進行状況を確認できます。

      デプロイメントが完了したら、仮想マシン名をクリックしてインスタンスのパブリック IP アドレスを取得し、SSH を使用して接続します。

    6. ターミナルを開いて SSH 接続を作成し、仮想マシンに接続します。
1.5.2.4. VMDK イメージのアップロードと vSphere での RHEL 仮想マシンの作成

RHEL Image Builder を使用すると、カスタマイズした VMware vSphere システムイメージを Open virtualization format (.ova) または Virtual disk (.vmdk) 形式で作成できます。これらのイメージを VMware vSphere クライアントにアップロードできます。govc import.vmdk CLI ツールを使用して、.vmdk または .ova イメージを VMware vSphere にアップロードできます。作成した vmdk には、インストール済みの cloud-init パッケージが含まれています。このパッケージを使用して、たとえばユーザーデータを使用してユーザーをプロビジョニングできます。

注記

VMware vSphere GUI を使用した vmdk イメージのアップロードはサポートされていません。

前提条件

  • ユーザー名とパスワードをカスタマイズしたブループリントを作成している。
  • RHEL Image Builder を使用して VMware vSphere イメージを .ova または .vmdk 形式で作成し、ホストシステムにダウンロードしている。
  • govc CLI ツールをインストールして設定し、import.vmdk コマンドが使用可能である。

手順

  1. GOVC 環境変数を使用して、ユーザー環境で次の値を設定します。

    GOVC_URL
    GOVC_DATACENTER
    GOVC_FOLDER
    GOVC_DATASTORE
    GOVC_RESOURCE_POOL
    GOVC_NETWORK
  2. VMware vSphere イメージをダウンロードしたディレクトリーに移動します。
  3. 次の手順に従って、vSphere で VMware vSphere イメージを起動します。

    1. VMware vSphere イメージを vSphere にインポートします。

      $ govc import.vmdk ./composer-api.vmdk foldername

      .ova 形式の場合:

      $ govc import.ova ./composer-api.ova foldername
    2. 電源をオンにせずに vSphere に仮想マシンを作成します。

      govc vm.create \
      -net.adapter=vmxnet3 \
      -m=4096 -c=2 -g=rhel8_64Guest \
      -firmware=efi -disk=”foldername/composer-api.vmdk” \
      -disk.controller=scsi -on=false \
       vmname

      .ova 形式の場合は、行 -firmware=efi -disk=”foldername/composer-api.vmdk” \ を `-firmware=efi -disk=”foldername/composer-api.ova” \ に置き換えます。

    3. 仮想マシンの電源をオンにします。

      govc vm.power -on vmname
    4. 仮想マシンの IP アドレスを取得します。

      govc vm.ip vmname
    5. ブループリントで指定したユーザー名とパスワードで、SSH を使用して、仮想マシンにログインします。

      $ ssh admin@<_ip_address_of_the_vm_>
      注記

      govc datastore.upload コマンドを使用してローカルホストから宛先に .vmdk イメージをコピーしても、コピーして作成したイメージを使用することはできません。vSphere GUI には import.vmdk コマンドを使用するオプションがないため、vSphere GUI は直接アップロードをサポートしません。そのため、.vmdk イメージを vSphere GUI から使用することはできません。

1.5.2.5. Image Builder GUI を使用して VMDK イメージを作成し、vSphere に自動的にアップロードする

RHEL Image Builder GUI ツールを使用して VMware イメージをビルドし、そのイメージを vSphere インスタンスに直接自動的にプッシュできます。これにより、イメージファイルをダウンロードして手動でプッシュする必要がなくなります。作成した vmdk には、インストール済みの cloud-init パッケージが含まれています。このパッケージを使用して、たとえばユーザーデータを使用してユーザーをプロビジョニングできます。RHEL Image Builder を使用して .vmdk イメージをビルドし、vSphere インスタンスサービスプロバイダーに直接プッシュするには、次の手順に従います。

前提条件

手順

  1. 作成したブループリントの Images タブをクリックします。
  2. Create Image をクリックして、カスタマイズしたイメージを作成します。

    イメージタイプウィンドウが開きます。

  3. Image type ウィンドウで、以下を実行します。

    1. ドロップダウンメニューから、タイプ VMware vSphere (.vmdk) を選択します。
    2. Upload to VMware チェックボックスをチェックして、イメージを vSphere にアップロードします。
    3. オプション: インスタンス化するイメージのサイズを設定します。最小のデフォルトサイズは 2 GB です。
    4. Next をクリックします。
  4. Upload to VMware ウィンドウの Authentication の下に以下の情報を入力します。

    1. ユーザー名: vSphere アカウントのユーザー名。
    2. パスワード: vSphere アカウントのパスワード。
  5. Upload to VMware ウィンドウの Destination の下に、イメージのアップロード先に関する以下の情報を入力します。

    1. Image name: イメージの名前。
    2. Host: VMware vSphere の URL。
    3. Cluster: クラスターの名前。
    4. Data center:データセンターの名前。
    5. Data store: データストアの名前。
    6. Next をクリックします。
  6. 確認 ウィンドウで、イメージ作成の詳細を確認し、Finish をクリックします。

    Back をクリックして、誤った情報を変更できます。

    RHEL Image Builder は、RHEL vSphere イメージの Compose をキューに追加し、指定した vSphere インスタンスのクラスターにイメージを作成してアップロードします。

    注記

    イメージビルドおよびアップロードプロセスの完了には数分かかります。

    プロセスが完了すると、Image build complete のステータスが表示されます。

検証

イメージステータスのアップロードが正常に完了したら、アップロードしたイメージから仮想マシン (VM) を作成し、ログインできます。改善点を報告する場合は、以下のように行います。

  1. VMware vSphere クライアントにアクセスします。
  2. 指定した vSphere インスタンスのクラスターでイメージを検索します。
  3. アップロードしたイメージを選択します。
  4. 選択したイメージを右クリックします。
  5. New Virtual Machine をクリックします。

    New Virtual Machine ウィンドウが開きます。

    New Virtual Machine ウィンドウで、以下の詳細を指定します。

    1. New Virtual Machine を選択します。
    2. 仮想マシンの名前とフォルダーを選択します。
    3. コンピューターリソースの選択: この操作の宛先コンピューターリソースを選択します
    4. ストレージを選択:たとえば、NFS-Node1 を選択します。
    5. 互換性を選択:イメージは BIOS のみである必要があります。
    6. ゲストオペレーティングシステムを選択します。たとえば、Linux および Red Hat Fedora (64-bit) を選択します。
    7. ハードウェアのカスタマイズ:仮想マシンを作成する場合は、右上の Device Configuration ボタンでデフォルトの New Hard Disk を削除し、ドロップダウンを使用して Existing Hard Disk ディスクイメージを選択します。
    8. 完了する準備ができました:詳細を確認し、Finish をクリックしてイメージを作成します。
  6. VMs タブに移動します。

    1. リストから、作成した仮想マシンを選択します。
    2. パネルから Start ボタンをクリックします。仮想マシンイメージを読み込み中であることを示す新しいウィンドウが表示されます。
    3. ブループリント用に作成した認証情報を使用してログインします。
    4. ブループリントに追加したパッケージがインストールされていることを確認できます。以下に例を示します。

      $ rpm -qa | grep firefox

1.5.3. カスタム GCE イメージの準備と GCP へのアップロードする

RHEL Image Builder を使用してカスタムイメージを作成し、そのイメージを Oracle Cloud Infrastructure (OCI) インスタンスに自動的にアップロードできます。

1.5.3.1. RHEL Image Builder を使用した GCP へのイメージのアップロード

RHEL Image Builder を使用すると、gce イメージをビルドし、ユーザーまたは GCP サービスアカウントの認証情報を指定して、gce イメージを GCP 環境に直接アップロードできます。

1.5.3.1.1. CLI を使用して gce イメージを設定して GCP にアップロードする

RHEL Image Builder CLI を使用して、gce イメージを GCP にアップロードするための認証情報を含む設定ファイルを設定します。

警告

イメージが起動しなくなるため、gce イメージを GCP に手動でインポートすることはできません。アップロードするには、gcloud または RHEL Image Builder を使用する必要があります。

前提条件

  • イメージを GCP にアップロードするための有効な Google アカウントと認証情報がある。認証情報は、ユーザーアカウントまたはサービスアカウントから取得できます。認証情報に関連付けられたアカウントには、少なくとも次の IAM ロールが割り当てられている必要があります。

    • roles/storage.admin - ストレージオブジェクトの作成と削除
    • roles/compute.storageAdmin - 仮想マシンイメージの Compute Engine へのインポート
  • 既存の GCP バケットがあります。

手順

  1. テキストエディターを使用して、次の内容の gcp-config.toml 設定ファイルを作成します。

    provider = "gcp"
    [settings]
    bucket = "GCP_BUCKET"
    region = "GCP_STORAGE_REGION"
    object = "OBJECT_KEY"
    credentials = "GCP_CREDENTIALS"
    • GCP_BUCKET は既存のバケットを指します。アップロード中のイメージの中間ストレージオブジェクトを格納するために使用されます。
    • GCP_STORAGE_REGION は、通常の Google ストレージリージョンであり、デュアルまたはマルチリージョンです。
    • OBJECT_KEY は、中間ストレージオブジェクトの名前です。アップロード前に存在してはならず、アップロードプロセスが完了すると削除されます。オブジェクト名が .tar.gz で終わらない場合、拡張子がオブジェクト名に自動的に追加されます。
    • GCP_CREDENTIALS は、GCP からダウンロードした認証情報 JSON ファイルの Base64 エンコードされたスキームです。認証情報によって、GCP がイメージをアップロードするプロジェクトが決まります。

      注記

      GCP での認証に別のメカニズムを使用する場合、gcp-config.toml ファイルでの GCP_CREDENTIALS の指定は任意です。他の認証方法は、Authenticating with GCP を参照してください。

  2. GCP からダウンロードした JSON ファイルから GCP_CREDENTIALS を取得します。

    $ sudo base64 -w 0 cee-gcp-nasa-476a1fa485b7.json
  3. 追加のイメージ名とクラウドプロバイダープロファイルを使用して Compose を作成します。

    $ sudo composer-cli compose start BLUEPRINT-NAME gce IMAGE_KEY gcp-config.toml

    イメージビルド、アップロード、およびクラウド登録プロセスは、完了に最大 10 分かかる場合があります。

検証

  • イメージのステータスが FINISHED であることを確認します。

    $ sudo composer-cli compose status
1.5.3.1.2. RHEL Image Builder によるさまざまな GCP 認証情報の認証順序の並べ替え

RHEL Image Builder でいくつかの異なる種類の認証情報を使用して、GCP で認証できます。複数の認証情報セットを使用して GCP で認証するように RHEL Image Builder が設定されている場合、次の優先順位で認証情報が使用されます。

  1. 設定ファイルで composer-cli コマンドで指定された認証情報。
  2. osbuild-composer ワーカー設定で設定された認証情報。
  3. 次の方法で認証方法を自動的に見つけようとする、Google GCP SDK ライブラリーからの Application Default Credentials

    1. GOOGLE_APPLICATION_CREDENTIALS 環境変数が設定されている場合、Application Default Credentials は、変数が指すファイルから認証情報を読み込んで使用しようとします。
    2. Application Default Credentials は、コードを実行しているリソースに関連付けられたサービスアカウントを使用して認証を試みます。たとえば、Google Compute Engine 仮想マシンです。

      注記

      イメージをアップロードする GCP プロジェクトを決定するには、GCP 認証情報を使用する必要があります。したがって、すべてのイメージを同じ GCP プロジェクトにアップロードする場合を除き、composer-cli コマンドを使用して gcp-config.toml 設定ファイルに認証情報を指定する必要があります。

1.5.3.1.2.1. composer-cli コマンドで GCP 認証情報を指定する

アップロードターゲット設定の gcp-config.toml ファイルで、GCP 認証情報を指定できます。時間を節約するために、Google アカウント認証情報の JSON ファイルの Base64 エンコードスキームを使用します。

手順

  1. GOOGLE_APPLICATION_CREDENTIALS 環境変数に保存されているパスを使用して、Google アカウント認証情報ファイルのエンコードされたコンテンツを取得するには、次のコマンドを実行します。

    $ base64 -w 0 "${GOOGLE_APPLICATION_CREDENTIALS}"
  2. アップロードターゲット設定の gcp-config.toml ファイルで、認証情報を設定します。

    provider = "gcp"
    
    [settings]
    provider = "gcp"
    
    [settings]
    credentials = "GCP_CREDENTIALS"
1.5.3.1.2.2. osbuild-composer ワーカー設定で認証情報を指定する

すべてのイメージビルドでグローバルに GCP に使用される GCP 認証認証情報を設定できます。このようにして、イメージを同じ GCP プロジェクトにインポートする場合、GCP へのすべてのイメージのアップロードに同じ認証情報を使用できます。

手順

  • /etc/osbuild-worker/osbuild-worker.toml ワーカー設定で、次の認証情報の値を設定します。

    [gcp]
    credentials = "PATH_TO_GCP_ACCOUNT_CREDENTIALS"

1.5.4. カスタムイメージの準備と OCI への直接アップロード

RHEL Image Builder を使用してカスタムイメージを作成し、そのイメージを Oracle Cloud Infrastructure (OCI) インスタンスに自動的にアップロードできます。

1.5.4.1. カスタムイメージを作成して OCI に自動的にアップロードする

RHEL Image Builder を使用すると、カスタマイズしたイメージをビルドし、そのイメージを Oracle Cloud Infrastructure (OCI) インスタンスに直接自動的にプッシュできます。その後、OCI ダッシュボードからイメージインスタンスを開始できます。

前提条件

  • システムに対して root または weldr グループのユーザーアクセスがある。
  • Oracle Cloud アカウントを持っている。
  • 管理者によって OCI ポリシー でセキュリティーアクセスが許可されている必要があります。
  • 選択した OCI_REGION に OCI バケットを作成しました。

手順

  1. ブラウザーで Web コンソールの RHEL Image Builder インターフェイスを開きます。
  2. Create blueprint をクリックします。Create blueprint ウィザードが開きます。
  3. Details ページで、ブループリントの名前を入力し、必要に応じて説明を入力します。Next をクリックします。
  4. Packages ページで、イメージに含めるコンポーネントとパッケージを選択します。Next をクリックします。
  5. Customizations ページで、ブループリントに必要なカスタマイズを設定します。Next をクリックします。
  6. Review ページで Create をクリックします。
  7. イメージを作成するには、Create Image をクリックします。Create image ウィザードが開きます。
  8. Image output ページで、次の手順を実行します。

    1. "Select a blueprint" ドロップダウンメニューから、必要なブループリントを選択します。
    2. "Image output type" ドロップダウンメニューから、Oracle Cloud Infrastructure (.qcow2) を選択します。
    3. イメージを OCI にアップロードするには、Upload OCI チェックボックスをオンにします。
    4. "image size" を入力します。Next をクリックします。
  9. Upload to OCI - Authentication ページで、次の必須の詳細を入力します。

    1. ユーザー OCID: ユーザーの詳細を表示するページのコンソールで確認できます。
    2. 秘密鍵
  10. Upload to OCI - Destination ページで、次の必須の詳細を入力し、Next をクリックします。

    1. イメージ名: アップロードするイメージの名前。
    2. OCI バケット
    3. バケット namespace
    4. バケットリージョン
    5. バケットコンパートメント
    6. バケットテナンシー
  11. ウィザードの詳細を確認し、Finish をクリックします。

RHEL Image Builder が、RHEL .qcow2 イメージの Compose をキューに追加します。

検証

  1. OCI ダッシュボード → カスタムイメージにアクセスします。
  2. イメージに指定した Compartment を選択し、Import image テーブルでイメージを見つけます。
  3. イメージ名をクリックして、イメージ情報を確認します。

1.5.5. カスタマイズした QCOW2 イメージを準備して OpenStack に直接アップロードする

RHEL Image Builder を使用してカスタムの .qcow2 イメージを作成し、OpenStack クラウドデプロイメントに手動でアップロードできます。

1.5.5.1. OpenStack への QCOW2 イメージのアップロード

RHEL Image Builder ツールを使用すると、OpenStack クラウドデプロイメントにアップロードし、そこでインスタンスを起動するのに適した、カスタマイズした .qcow2 イメージを作成できます。RHEL Image Builder は QCOW2 フォーマットでイメージを作成しますが、OpenStack に固有の変更がさらに加えられています。

警告

RHEL Image Builder を OpenStack イメージタイプで使用して作成する一般的な QCOW2 イメージタイプの出力フォーマットを間違えないでください。これも QCOW2 フォーマットですが、OpenStack に固有の変更がさらに含まれています。

前提条件

  • ブループリントを作成している。

手順

  1. QCOW2 イメージの作成を開始します。

    # composer-cli compose start blueprint_name openstack
  2. ビルドの状態を確認します。

    # composer-cli compose status

    イメージのビルドが完了したら、イメージをダウンロードできます。

  3. QCOW2 イメージをダウンロードします。

    # composer-cli compose image UUID
  4. OpenStack ダッシュボードにアクセスし、+Create Image をクリックします。
  5. 左側のメニューで、Admin タブを選択します。
  6. System Panel から Image をクリックします。

    Create An Image ウィザードが開きます。

  7. Create An Image ウィザードで、以下を行います。

    1. イメージの名前を入力します。
    2. Browse をクリックして QCOW2 イメージをアップロードします。
    3. Format ドロップダウンリストから、QCOW2 - QEMU Emulator を選択します。
    4. Create Image をクリックします。

      composer openstack upload image

  8. 左側のメニューで Project タブを選択します。

    1. Compute メニューから Instances を選択します。
    2. Launch Instance ボタンをクリックします。

      インスタンスの Launch Instance が開きます。

    3. Details ページで、インスタンスの名前を入力します。Next をクリックします。
    4. Source ページで、アップロードしたイメージの名前を選択します。Next をクリックします。
    5. Flavor ページで、ニーズに最適なマシンリソースを選択します。Launch をクリックします。

      composer openstack start instance

  9. イメージから任意のメカニズム (CLI または OpenStack Web UI) を使用して、イメージインスタンスを実行できます。秘密鍵を使用して、SSH 経由で、作成されたインスタンスにアクセスします。cloud-user としてログインします。

1.5.6. カスタマイズした RHEL イメージを準備して Alibaba Cloud にアップロードする

RHEL Image Builder で作成した、カスタマイズしれた .ami イメージを Alibaba Cloud にアップロードできます。

1.5.6.1. カスタマイズされた RHEL イメージを Alibaba Cloud にアップロードする準備

カスタマイズされた RHEL イメージを Alibaba Cloud にデプロイするには、まずカスタマイズされたイメージを検証する必要があります。Alibaba Cloud は、イメージを使用する前に特定の要件を満たすようにカスタムイメージを要求するため、イメージが正常に起動するように特別な設定が必要になります。

注記

RHEL Image Builder は、Alibaba の要件に準拠したイメージを生成します。ただし、Red Hat は、Alibaba image_check ツール を使用して、イメージのフォーマット準拠を確認することも推奨します。

前提条件

  • RHEL Image Builder を使用して Alibaba イメージを作成している。

手順

  1. Alibaba の image_check ツールを使用して、チェックするイメージを含むシステムに接続します。
  2. image_check ツールをダウンロードします。

    $ curl -O https://docs-aliyun.cn-hangzhou.oss.aliyun-inc.com/assets/attach/73848/cn_zh/1557459863884/image_check
  3. イメージのコンプライアンスツールのファイルパーミッションを変更します。

    # chmod +x image_check
  4. 次のコマンドを実行して、イメージコンプライアンスツールのチェックを起動します。

    # ./image_check

    このツールは、システム設定を検証し、画面に表示されるレポートを生成します。image_check ツールは、イメージのコンプライアンスツールが実行されているフォルダーにこのレポートを保存します。

トラブルシューティング

いずれかの 検出項目 が失敗した場合は、ターミナルの指示に従って修正してください。

関連情報

1.5.6.2. カスタマイズされた RHEL イメージを Alibaba にアップロードする

RHEL Image Builder で作成した、カスタマイズした AMI イメージを Object Storage Service (OSS) にアップロードできます。

前提条件

手順

  1. OSS コンソール にログインします。
  2. 左側のバケットメニューで、イメージをアップロードするバケットを選択します。
  3. 右上のメニューで、Files タブをクリックします。
  4. Upload をクリックします。右側のダイアログウィンドウが開きます。以下を設定します。

    • アップロード先:これを選択すると、現在 のディレクトリーまたは 指定した ディレクトリーにファイルをアップロードします。
    • ファイル ACL:アップロードしたファイルのパーミッションのタイプを選択します。
  5. Upload をクリックします。
  6. OSS コンソールにアップロードするイメージを選択します。
  7. Open をクリックします。
1.5.6.3. Alibaba Cloud へのイメージのインポート

RHEL Image Builder で作成した、カスタマイズした Alibaba RHEL イメージを Elastic Compute Service (ECS) にインポートするには、次の手順に従います。

前提条件

手順

  1. ECS コンソール にログインします。

    1. 左側のメニューで、images をクリックします。
    2. 右上にある Import Image をクリックします。ダイアログウィンドウが開きます。
    3. イメージが含まれる正しいリージョンを設定していることを確認します。以下の情報を入力します。

      1. OSS Object Address:OSS Object Address の取得方法を参照してください。
      2. Image Name
      3. オペレーティングシステム
      4. System Disk Size
      5. システムアーキテクチャー
      6. プラットフォーム:Red Hat
    4. オプション: 以下の情報を指定します。

      1. Image Format - アップロードしたイメージの形式に応じて qcow2 または ami
      2. Image Description
      3. Add Images of Data Disks

        アドレスは、OSS 管理コンソールで確認できます。左側のメニューで必要なバケットを選択した後:

  2. Files セクションを選択します。
  3. 適切なイメージの右側にある Details リンクをクリックします。

    画面右側にウィンドウが表示され、イメージの詳細が表示されます。OSS オブジェクトアドレスは URL ボックスにあります。

  4. OK をクリックします。

    注記

    インポートプロセスの時間は、イメージのサイズによって異なります。

カスタマイズされたイメージが ECS コンソールにインポートされます。

1.5.6.4. Alibaba Cloud を使用したカスタマイズされた RHEL イメージのインスタンスの作成

Alibaba ECS コンソールを使用して、カスタマイズされた RHEL イメージのインスタンスを作成できます。

前提条件

  • OSS をアクティベートして、カスタムイメージをアップロードしている。
  • イメージを ECS コンソールに正常にインポートしている。Alibaba へのイメージのインポート を参照してください。

手順

  1. ECS コンソール にログインします。
  2. 左側のメニューで、インスタンス を選択します。
  3. 右上隅にある インスタンスの作成 をクリックします。新しいウィンドウにリダイレクトされます。
  4. 必要な情報をすべて完了します。詳細は、Creating an instance by using the wizard を参照してください。
  5. Create Instance をクリックして、順番を確認します。

    注記

    サブスクリプションによっては、Create Instance ではなく Create Order が表示されます。

その結果、アクティブなインスタンスを Alibaba ECS Console からデプロイする準備が整いました。

第2章 キックスタートを使用した自動インストールの実行

第3章 高度な設定オプション

第4章 キックスタートの参照

パート II. セキュリティーの設計

第5章 インストール中およびインストール直後の RHEL の保護

セキュリティーへの対応は、Red Hat Enterprise Linux をインストールする前にすでに始まっています。最初からシステムのセキュリティーを設定することで、追加のセキュリティー設定を実装することがより簡単になります。

5.1. ディスクパーティション設定

ディスクパーティション設定の推奨プラクティスは、ベアメタルマシンへのインストールと、インストール済みオペレーティングシステムを含む仮想ディスクハードウェアおよびファイルシステムの調整をサポートする仮想化環境またはクラウド環境とでは異なります。

ベアメタルインストール でデータの分離と保護を確実に行うには、/boot//home/tmp/var/tmp/ ディレクトリー用に個別のパーティションを作成します。

/boot
このパーティションは、システムの起動時にシステムが最初に読み込むパーティションです。Red Hat Enterprise Linux 8 でシステムを起動するのに使用するブートローダーとカーネルイメージはこのパーティションに保存されます。このパーティションは暗号化しないでください。このパーティションが /` に含まれており、そのパーティションが暗号化されているなどの理由で利用できなくなると、システムを起動できなくなります。
/home
ユーザーデータ (/home) が別のパーティションではなく / に保存されていると、このパーティションが満杯になり、オペレーティングシステムが不安定になる可能性があります。また、システムを、Red Hat Enterprise Linux 8 の次のバージョンにアップグレードする際に、/home パーティションにデータを保存できると、このデータはインストール時に上書きされないため、アップグレードが非常に簡単になります。root パーティション (/) が破損すると、データが完全に失われます。したがって、パーティションを分けることが、データ損失に対する保護につながります。また、このパーティションを、頻繁にバックアップを作成する対象にすることも可能です。
/tmp および /var/tmp/
/tmp ディレクトリーおよび /var/tmp/ ディレクトリーは、どちらも長期保存の必要がないデータを保存するのに使用されます。しかし、このいずれかのディレクトリーでデータがあふれると、ストレージ領域がすべて使用されてしまう可能性があります。このディレクトリーは / に置かれているため、こうした状態が発生すると、システムが不安定になり、クラッシュする可能性があります。そのため、このディレクトリーは個別のパーティションに移動することが推奨されます。

仮想マシンまたはクラウドインスタンス の場合、/boot/home/tmp、および /var/tmp パーティションの分離は任意です。/ パーティションがいっぱいになり始めたら、仮想ディスクのサイズとそのパーティションを拡張できるためです。/ パーティションがいっぱいにならないように、その使用状況を定期的にチェックするモニタリングを設定してから、仮想ディスクのサイズを適宜拡張してください。

注記

インストールプロセス時に、パーティションを暗号化するオプションがあります。パスフレーズを入力する必要があります。これは、パーティションのデータを保護するのに使用されるバルク暗号鍵を解除する鍵として使用されます。

5.2. インストールプロセス時のネットワーク接続の制限

Red Hat Enterprise Linux 8 をインストールする際に使用するインストールメディアは、特定のタイミングで作成されたスナップショットです。そのため、セキュリティー修正が最新のものではなく、このインストールメディアで設定するシステムが公開されてから修正された特定の問題に対して安全性に欠ける場合があります。

脆弱性が含まれる可能性のあるオペレーティングシステムをインストールする場合には、必ず、公開レベルを、必要最小限のネットワークゾーンに限定してください。最も安全な選択肢は、インストールプロセス時にマシンをネットワークから切断した状態にするネットワークなしのゾーンです。インターネット接続からのリスクが最も高く、一方で LAN またはイントラネット接続で十分な場合もあります。セキュリティーのベストプラクティスに従い、ネットワークから Red Hat Enterprise Linux 8 をインストールする場合は、お使いのリポジトリーに最も近いゾーンを選択するようにしてください。

5.3. 必要なパッケージの最小限のインストール

コンピューターの各ソフトウェアには脆弱性が潜んでいる可能性があるため、実際に使用するパッケージのみをインストールすることがベストプラクティスになります。インストールを DVD から行う場合は、インストールしたいパッケージのみを選択するようにします。その他のパッケージが必要になる場合は、後でいつでもシステムに追加できます。

5.4. インストール後の手順

以下は、Red Hat Enterprise Linux 8 のインストール直後に実行する必要があるセキュリティー関連の手順です。

  • システムを更新します。root で以下のコマンドを実行します。

    # yum update
  • ファイアウォールサービスの firewalld は、Red Hat Enterprise Linux のインストールによって自動的に有効になりますが、キックスタート設定などで明示的に無効になっている場合があります。このような場合は、ファイアウォールを再度有効にしてください。

    firewalld を開始するには、root で次のコマンドを実行します。

    # systemctl start firewalld
    # systemctl enable firewalld
  • セキュリティーを強化するために、不要なサービスは無効にしてください。たとえば、コンピューターにプリンターがインストールされていない場合は、次のコマンドを使用して、cups サービスを無効にします。

    # systemctl disable cups

    アクティブなサービスを確認するには、次のコマンドを実行します。

    $ systemctl list-units | grep service

5.5. Web コンソールを使用して CPU のセキュリティーの問題を防ぐために SMT を無効化する手順

CPU SMT (Simultaneous Multi Threading) を悪用する攻撃が発生した場合に SMT を無効にします。SMT を無効にすると、L1TF や MDS などのセキュリティー脆弱性を軽減できます。

重要

SMT を無効にすると、システムパフォーマンスが低下する可能性があります。

前提条件

手順

  1. RHEL 8 Web コンソールにログインします。

    詳細は、Web コンソールへのログイン を参照してください。

  2. Overview タブで、System information フィールドを見つけて、View hardware details をクリックします。
  3. CPU Security 行で、Mitigations をクリックします。

    このリンクがない場合は、システムが SMT に対応していないため、攻撃を受けません。

  4. CPU Security Toggles テーブルで、Disable simultaneous multithreading (nosmt) オプションに切り替えます。
  5. Save and reboot ボタンをクリックします。

システムの再起動後、CPU は SMT を使用しなくなりました。

第6章 システム全体の暗号化ポリシーの使用

システム全体の暗号化ポリシーは、コア暗号化サブシステムを設定するシステムコンポーネントで、TLS、IPsec、SSH、DNSSec、および Kerberos の各プロトコルに対応します。これにより、管理者が選択できる小規模セットのポリシーを提供します。

6.1. システム全体の暗号化ポリシー

システム全体のポリシーを設定すると、RHEL のアプリケーションはそのポリシーに従い、ポリシーを満たしていないアルゴリズムやプロトコルを使用するように明示的に要求されない限り、その使用を拒否します。つまり、システムが提供した設定で実行する際に、デフォルトのアプリケーションの挙動にポリシーを適用しますが、必要な場合は上書きできます。

RHEL 8 には、以下の定義済みポリシーが含まれています。

デフォルト
デフォルトのシステム全体の暗号化ポリシーレベルで、現在の脅威モデルに対して安全なものです。TLS プロトコルの 1.2 と 1.3、IKEv2 プロトコル、および SSH2 プロトコルが使用できます。RSA 鍵と Diffie-Hellman パラメーターは長さが 2048 ビット以上であれば許容されます。
LEGACY
Red Hat Enterprise Linux 5 以前との互換性を最大限に確保します。攻撃対象領域が増えるため、セキュリティーが低下します。DEFAULT レベルでのアルゴリズムとプロトコルに加えて、TLS プロトコル 1.0 および 1.1 を許可します。アルゴリズム DSA、3DES、および RC4 が許可され、RSA 鍵と Diffie-Hellman パラメーターの長さが 1023 ビット以上であれば許容されます。
FUTURE

将来の潜在的なポリシーをテストすることを目的とした、より厳格な将来を見据えたセキュリティーレベル。このポリシーでは、署名アルゴリズムでの SHA-1 の使用は許可されません。TLS プロトコルの 1.2 と 1.3、IKEv2 プロトコル、および SSH2 プロトコルが使用できます。RSA 鍵と Diffie-Hellman パラメーターは、ビット長が 3072 以上だと許可されます。システムが公共のインターネット上で通信する場合、相互運用性の問題が発生する可能性があります。

重要

カスタマーポータル API の証明書が使用する暗号化鍵は FUTURE のシステム全体の暗号化ポリシーが定義する要件を満たさないので、現時点で redhat-support-tool ユーティリティーは、このポリシーレベルでは機能しません。

この問題を回避するには、カスタマーポータル API への接続中に DEFAULT 暗号化ポリシーを使用します。

FIPS

FIPS 140 要件に準拠します。RHEL システムを FIPS モードに切り替える fips-mode-setup ツールは、このポリシーを内部的に使用します。FIPS ポリシーに切り替えても、FIPS 140 標準への準拠は保証されません。また、システムを FIPS モードに設定した後、すべての暗号キーを再生成する必要があります。多くのシナリオでは、これは不可能です。

また、RHEL はシステム全体のサブポリシー FIPS:OSPP を提供します。これには、Common Criteria (CC) 認証に必要な暗号化アルゴリズムに関する追加の制限が含まれています。このサブポリシーを設定すると、システムの相互運用性が低下します。たとえば、3072 ビットより短い RSA 鍵と DH 鍵、追加の SSH アルゴリズム、および複数の TLS グループを使用できません。また、FIPS:OSPP を設定すると、Red Hat コンテンツ配信ネットワーク (CDN) 構造への接続が防止されます。さらに、FIPS:OSPP を使用する IdM デプロイメントには Active Directory (AD) を統合できません。FIPS:OSPP を使用する RHEL ホストと AD ドメイン間の通信が機能しないか、一部の AD アカウントが認証できない可能性があります。

注記

FIPS:OSPP 暗号化サブポリシーを設定すると、システムが CC 非準拠になります。RHEL システムを CC 標準に準拠させる唯一の正しい方法は、cc-config パッケージで提供されているガイダンスに従うことです。認定済みの RHEL バージョン、検証レポート、および CC ガイドへのリンクのリストについては、ナレッジベース記事「Compliance Activities and Government Standards」の Common Criteria セクションを参照してください。

Red Hat は、LEGACY ポリシーを使用する場合を除き、すべてのライブラリーがセキュアなデフォルト値を提供するように、すべてのポリシーレベルを継続的に調整します。LEGACY プロファイルはセキュアなデフォルト値を提供しませんが、このプロファイルには、簡単に悪用できるアルゴリズムは含まれていません。このため、提供されたポリシーで有効なアルゴリズムのセットまたは許容可能な鍵サイズは、Red Hat Enterprise Linux の存続期間中に変更する可能性があります。

このような変更は、新しいセキュリティー標準や新しいセキュリティー調査を反映しています。Red Hat Enterprise Linux のライフサイクル全体にわたって特定のシステムとの相互運用性を確保する必要がある場合は、そのシステムと対話するコンポーネントのシステム全体の暗号化ポリシーからオプトアウトするか、カスタム暗号化ポリシーを使用して特定のアルゴリズムを再度有効にする必要があります。

ポリシーレベルで許可されていると記載されている特定のアルゴリズムと暗号は、アプリケーションがそれらをサポートしている場合にのみ使用できます。

表6.1 暗号化ポリシーで有効になっている暗号スイートとプロトコル
 LEGACYDEFAULTFIPSFUTURE

IKEv1

いいえ

いいえ

いいえ

いいえ

3DES

はい

いいえ

いいえ

いいえ

RC4

はい

いいえ

いいえ

いいえ

DH

最低 1024 ビット

最低 2048 ビット

最低 2048 ビット[a]

最低 3072 ビット

RSA

最低 1024 ビット

最低 2048 ビット

最低 2048 ビット

最低 3072 ビット

DSA

はい

いいえ

いいえ

いいえ

TLS v1.0

はい

いいえ

いいえ

いいえ

TLS v1.1

はい

いいえ

いいえ

いいえ

デジタル署名における SHA-1

はい

はい

いいえ

いいえ

CBC モード暗号

はい

はい

はい

いいえ[b]

256 ビットより小さい鍵を持つ対称暗号

はい

はい

はい

いいえ

証明書における SHA-1 および SHA-224 の署名

はい

はい

はい

いいえ

[a] RFC 7919 および RFC 3526 で定義されている Diffie-Hellman グループのみを使用できます。
[b] TLS の CBC 暗号が無効になっています。TLS 以外のシナリオでは、AES-128-CBC は無効になっていますが、AES-256-CBC が有効になります。AES-256-CBC も無効にするには、カスタムのサブポリシーを適用します。

関連情報

  • システム上の crypto-policies(7) および update-crypto-policies(8) man ページ

6.2. システム全体の暗号化ポリシーの変更

update-crypto-policies ツールを使用してシステムを再起動すると、システム全体の暗号化ポリシーを変更できます。

前提条件

  • システムの root 権限がある。

手順

  1. オプション: 現在の暗号化ポリシーを表示します。

    $ update-crypto-policies --show
    DEFAULT
  2. 新しい暗号化ポリシーを設定します。

    # update-crypto-policies --set <POLICY>
    <POLICY>

    <POLICY> は、設定するポリシーまたはサブポリシー (FUTURELEGACYFIPS:OSPP など) に置き換えます。

  3. システムを再起動します。

    # reboot

検証

  • 現在の暗号化ポリシーを表示します。

    $ update-crypto-policies --show
    <POLICY>

関連情報

6.3. システム全体の暗号化ポリシーを、以前のリリースと互換性のあるモードに切り替え

Red Hat Enterprise Linux 8 におけるデフォルトのシステム全体の暗号化ポリシーでは、現在は古くて安全ではないプロトコルは許可されません。Red Hat Enterprise Linux 6 およびそれ以前のリリースとの互換性が必要な場合には、安全でない LEGACY ポリシーレベルを利用できます。

警告

LEGACY ポリシーレベルに設定すると、システムおよびアプリケーションの安全性が低下します。

手順

  1. システム全体の暗号化ポリシーを LEGACY レベルに切り替えるには、root で以下のコマンドを実行します。

    # update-crypto-policies --set LEGACY
    Setting system policy to LEGACY

関連情報

  • 利用可能な暗号化ポリシーレベルのリストについては、システム上の update-crypto-policies(8) man ページを参照してください。
  • カスタム暗号化ポリシーの定義については、システム上の update-crypto-policies(8) man ページの Custom Policies セクションと、crypto-policies(7) man ページの Crypto Policy Definition Format セクションを参照してください。

6.4. Web コンソールでシステム全体の暗号化ポリシーを設定する

RHEL Web コンソールインターフェイスで、システム全体の暗号化ポリシーとサブポリシーのいずれかを直接設定できます。4 つの事前定義されたシステム全体の暗号化ポリシーに加え、グラフィカルインターフェイスを介して、次のポリシーとサブポリシーの組み合わせを適用することもできます。

DEFAULT:SHA1
SHA-1 アルゴリズムが有効になっている DEFAULT ポリシー。
LEGACY:AD-SUPPORT
Active Directory サービスの相互運用性を向上させる、セキュリティーの低い設定を含む LEGACY ポリシー。
FIPS:OSPP
Common Criteria for Information Technology Security Evaluation 標準によって要求される追加の制限を含む FIPS ポリシー。
警告

システム全体のサブポリシー FIPS:OSPP には、Common Criteria (CC) 認定に必要な暗号化アルゴリズムに関する追加の制限が含まれています。そのため、このサブポリシーを設定すると、システムの相互運用性が低下します。たとえば、3072 ビットより短い RSA 鍵と DH 鍵、追加の SSH アルゴリズム、および複数の TLS グループを使用できません。また、FIPS:OSPP を設定すると、Red Hat コンテンツ配信ネットワーク (CDN) 構造への接続が防止されます。さらに、FIPS:OSPP を使用する IdM デプロイメントには Active Directory (AD) を統合できません。FIPS:OSPP を使用する RHEL ホストと AD ドメイン間の通信が機能しないか、一部の AD アカウントが認証できない可能性があります。

FIPS:OSPP 暗号化サブポリシーを設定すると、システムが CC 非準拠になる ことに注意してください。RHEL システムを CC 標準に準拠させる唯一の正しい方法は、cc-config パッケージで提供されているガイダンスに従うことです。認定済みの RHEL バージョン、検証レポート、および National Information Assurance Partnership (NIAP) で提供されている CC ガイドへのリンクのリストについては、ナレッジベース記事「Compliance Activities and Government Standards」の Common Criteria セクションを参照してください。

前提条件

手順

  1. RHEL 8 Web コンソールにログインします。

    詳細は、Web コンソールへのログイン を参照してください。

  2. Overview ページの Configuration カードで、Crypto policy の横にある現在のポリシー値をクリックします。

    The web console: Overview

  3. Change crypto policy ダイアログウィンドウで、システムで使用を開始するポリシーをクリックします。

    The web console: Change the system-wide cryptographic policy

  4. Apply and reboot ボタンをクリックします。

検証

  • 再起動後、Web コンソールに再度ログインし、暗号化ポリシー の値が選択したものと一致していることを確認します。

    あるいは、update-crypto-policies --show コマンドを入力して、現在のシステム全体の暗号化ポリシーをターミナルに表示することもできます。

6.5. システム全体の暗号化ポリシーに従わないようにアプリケーションを除外

アプリケーションで使用される暗号化関連の設定をカスタマイズする必要がある場合は、サポートされる暗号スイートとプロトコルをアプリケーションで直接設定することが推奨されます。

/etc/crypto-policies/back-ends ディレクトリーからアプリケーション関連のシンボリックリンクを削除することもできます。カスタマイズした暗号化設定に置き換えることもできます。この設定により、除外されたバックエンドを使用するアプリケーションに対するシステム全体の暗号化ポリシーが使用できなくなります。この修正は、Red Hat ではサポートされていません。

6.5.1. システム全体の暗号化ポリシーを除外する例

wget

wget ネットワークダウンローダーで使用される暗号化設定をカスタマイズするには、--secure-protocol オプションおよび --ciphers オプションを使用します。以下に例を示します。

$ wget --secure-protocol=TLSv1_1 --ciphers="SECURE128" https://example.com

詳細は、wget(1) man ページの HTTPS (SSL/TLS) Options のセクションを参照してください。

curl

curl ツールで使用する暗号を指定するには、--ciphers オプションを使用して、その値に、コロンで区切った暗号化のリストを指定します。以下に例を示します。

$ curl https://example.com --ciphers '@SECLEVEL=0:DES-CBC3-SHA:RSA-DES-CBC3-SHA'

詳細は、curl(1) の man ページを参照してください。

Firefox

Web ブラウザーの Firefox でシステム全体の暗号化ポリシーをオプトアウトできない場合でも、Firefox の設定エディターで、対応している暗号と TLS バージョンをさらに詳細に制限できます。アドレスバーに about:config と入力し、必要に応じて security.tls.version.min の値を変更します。たとえば、security.tls.version.min1 に設定すると、最低でも TLS 1.0 が必要になり、security.tls.version.min 2 が TLS 1.1 になります。

OpenSSH

OpenSSH サーバーに対するシステム全体の暗号化ポリシーを除外するには、/etc/sysconfig/sshd ファイルの CRYPTO_POLICY= 変数行のコメントを除外します。この変更後、/etc/ssh/sshd_config ファイルの Ciphers セクション、MACs セクション、KexAlgoritms セクション、および GSSAPIKexAlgorithms セクションで指定した値は上書きされません。

詳細は、sshd_config(5) の man ページを参照してください。

OpenSSH クライアントのシステム全体の暗号化ポリシーをオプトアウトするには、次のいずれかのタスクを実行します。

  • 指定のユーザーの場合は、~/.ssh/config ファイルのユーザー固有の設定でグローバルの ssh_config を上書きします。
  • システム全体の場合は、/etc/ssh/ssh_config.d/ ディレクトリーにあるドロップイン設定ファイルに暗号化ポリシーを指定します。このとき、辞書式順序で 05-redhat.conf ファイルよりも前に来るように、5 未満の 2 桁の接頭辞と、.conf という接尾辞を付けます (例: 04-crypto-policy-override.conf)。

詳細は、ssh_config(5) の man ページを参照してください。

関連情報

  • システム上の update-crypto-policies(8) man ページ

6.6. サブポリシーを使用したシステム全体の暗号化ポリシーのカスタマイズ

この手順を使用して、有効な暗号化アルゴリズムまたはプロトコルのセットを調整します。

既存のシステム全体の暗号化ポリシーの上にカスタムサブポリシーを適用するか、そのようなポリシーを最初から定義することができます。

スコープが設定されたポリシーの概念により、バックエンドごとに異なるアルゴリズムセットを有効にできます。各設定ディレクティブは、特定のプロトコル、ライブラリー、またはサービスに限定できます。

また、ディレクティブでは、ワイルドカードを使用して複数の値を指定する場合にアスタリスクを使用できます。

/etc/crypto-policies/state/CURRENT.pol ファイルには、ワイルドカードデプロイメント後に現在適用されているシステム全体の暗号化ポリシーのすべての設定がリスト表示されます。暗号化ポリシーをより厳密にするには、/usr/share/crypto-policies/policies/FUTURE.pol ファイルにリストされている値を使用することを検討してください。

サブポリシーの例は、/usr/share/crypto-policies/policies/modules/ ディレクトリーにあります。このディレクトリーのサブポリシーファイルには、コメントアウトされた行に説明が含まれています。

注記

システム全体の暗号化ポリシーのカスタマイズは、RHEL 8.2 から利用できます。スコープ指定ポリシーの概念と、RHEL 8.5 以降でワイルドカードを使用するオプションを使用できます。

手順

  1. /etc/crypto-policies/policies/modules/ ディレクトリーをチェックアウトします。

    # cd /etc/crypto-policies/policies/modules/
  2. 調整用のサブポリシーを作成します。次に例を示します。

    # touch MYCRYPTO-1.pmod
    # touch SCOPES-AND-WILDCARDS.pmod
    重要

    ポリシーモジュールのファイル名には大文字を使用します。

  3. 任意のテキストエディターでポリシーモジュールを開き、システム全体の暗号化ポリシーを変更するオプションを挿入します。次に例を示します。

    # vi MYCRYPTO-1.pmod
    min_rsa_size = 3072
    hash = SHA2-384 SHA2-512 SHA3-384 SHA3-512
    # vi SCOPES-AND-WILDCARDS.pmod
    # Disable the AES-128 cipher, all modes
    cipher = -AES-128-*
    
    # Disable CHACHA20-POLY1305 for the TLS protocol (OpenSSL, GnuTLS, NSS, and OpenJDK)
    cipher@TLS = -CHACHA20-POLY1305
    
    # Allow using the FFDHE-1024 group with the SSH protocol (libssh and OpenSSH)
    group@SSH = FFDHE-1024+
    
    # Disable all CBC mode ciphers for the SSH protocol (libssh and OpenSSH)
    cipher@SSH = -*-CBC
    
    # Allow the AES-256-CBC cipher in applications using libssh
    cipher@libssh = AES-256-CBC+
  4. 変更をモジュールファイルに保存します。
  5. ポリシーの調整を、システム全体の暗号化ポリシーレベル DEFAULT に適用します。

    # update-crypto-policies --set DEFAULT:MYCRYPTO-1:SCOPES-AND-WILDCARDS
  6. 暗号化設定を実行中のサービスやアプリケーションで有効にするには、システムを再起動します。

    # reboot

検証

  • /etc/crypto-policies/state/CURRENT.pol ファイルに変更が含まれていることを確認します。以下に例を示します。

    $ cat /etc/crypto-policies/state/CURRENT.pol | grep rsa_size
    min_rsa_size = 3072

関連情報

  • システム上の update-crypto-policies(8) man ページの Custom Policies セクション
  • システム上の crypto-policies(7) man ページの Crypto Policy Definition Format セクション
  • Red Hat ブログ記事 How to customize crypto policies in RHEL 8.2

6.7. システム全体の暗号化ポリシーをカスタマイズして SHA-1 を無効化

SHA-1 ハッシュ関数は本質的に設計面で弱く、暗号解析機能によって攻撃を受けやすいため、RHEL 8 ではデフォルトで SHA-1 を使用していません。ただし、一部のサードパーティーアプリケーション (公開署名など) は SHA-1 を使用します。システムの署名アルゴリズムで SHA-1 の使用を無効にするには、NO-SHA1 ポリシーモジュールを使用できます。

重要

NO-SHA1 ポリシーモジュールが無効にするのは、署名の SHA-1 ハッシュ関数だけでそれ以外は無効になりません。特に、NO-SHA1 モジュールでも、ハッシュベースのメッセージ認証コード (HMAC) とともに SHA-1 を使用できます。HMAC セキュリティープロパティーは、対応するハッシュ関数の衝突耐性に依存しないので、HMAC に SHA-1 を使用している場合に最近の SHA-1 への攻撃による影響は大幅に低くなっています。

特定の鍵交換 (KEX) アルゴリズムの組み合わせ (例: diffie-hellman-group-exchange-sha1) を無効にする必要があるものの、関連する KEX とアルゴリズムの両方を継続して使用する場合は、SSH のシステム全体の暗号化ポリシーをオプトアウトして SSH を直接設定する手順について、SSH で diffie-hellman-group1-sha1 アルゴリズムを無効にする手順 を参照してください。

注記

SHA-1 を無効にするモジュールは、RHEL 8.3 で利用できます。システム全体の暗号化ポリシーのカスタマイズは、RHEL 8.2 から利用できます。

手順

  1. ポリシーの調整を、システム全体の暗号化ポリシーレベル DEFAULT に適用します。

    # update-crypto-policies --set DEFAULT:NO-SHA1
  2. 暗号化設定を実行中のサービスやアプリケーションで有効にするには、システムを再起動します。

    # reboot

関連情報

  • システム上の update-crypto-policies(8) man ページの Custom Policies セクション
  • システム上の crypto-policies(7) man ページの Crypto Policy Definition Format セクション
  • Red Hat ブログ記事 How to customize crypto policies in RHEL

6.8. システム全体のカスタム暗号化ポリシーの作成および設定

完全なポリシーファイルを作成して使用することで、システム全体の暗号化ポリシーを特定の状況向けにカスタマイズできます。

注記

システム全体の暗号化ポリシーのカスタマイズは、RHEL 8.2 から利用できます。

手順

  1. カスタマイズのポリシーファイルを作成します。

    # cd /etc/crypto-policies/policies/
    # touch MYPOLICY.pol

    または、定義されている 4 つのポリシーレベルのいずれかをコピーします。

    # cp /usr/share/crypto-policies/policies/DEFAULT.pol /etc/crypto-policies/policies/MYPOLICY.pol
  2. 必要に応じて、テキストエディターでファイルを編集します。以下のようにしてカスタム暗号化ポリシーを使用します。

    # vi /etc/crypto-policies/policies/MYPOLICY.pol
  3. システム全体の暗号化ポリシーをカスタムレベルに切り替えます。

    # update-crypto-policies --set MYPOLICY
  4. 暗号化設定を実行中のサービスやアプリケーションで有効にするには、システムを再起動します。

    # reboot

関連情報

  • システム上の update-crypto-policies(8) man ページの Custom Policies セクションと crypto-policies(7) man ページの Crypto Policy Definition Format セクション
  • Red Hat ブログ記事 How to customize crypto policies in RHEL

6.9. crypto_policies RHEL システムロールを使用した FUTURE 暗号化ポリシーによるセキュリティーの強化

crypto_policies RHEL システムロールを使用して、管理対象ノードで FUTURE ポリシーを設定できます。このポリシーは、たとえば次のことを実現するのに役立ちます。

  • 将来の新たな脅威への対応: 計算能力の向上を予測します。
  • セキュリティーの強化: 強力な暗号化標準により、より長い鍵長とよりセキュアなアルゴリズムを必須にします。
  • 高度なセキュリティー標準への準拠: 医療、通信、金融などの分野ではデータの機密性が高く、強力な暗号化を利用できることが重要です。

通常、FUTURE は、機密性の高いデータを扱う環境、将来の規制に備える環境、長期的なセキュリティーストラテジーを採用する環境に適しています。

警告

レガシーのシステムやソフトウェアでは、FUTURE ポリシーによって強制される、より最新しく厳格なアルゴリズムやプロトコルをサポートする必要はありません。たとえば、古いシステムでは TLS 1.3 以上の鍵サイズがサポートされていない可能性があります。これにより互換性の問題が発生する可能性があります。

また、強力なアルゴリズムを使用すると、通常、計算負荷が増加し、システムのパフォーマンスに悪影響が及ぶ可能性があります。

前提条件

手順

  1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

    ---
    - name: Configure cryptographic policies
      hosts: managed-node-01.example.com
      tasks:
        - name: Configure the FUTURE cryptographic security policy on the managed node
          ansible.builtin.include_role:
            name: rhel-system-roles.crypto_policies
          vars:
            - crypto_policies_policy: FUTURE
            - crypto_policies_reboot_ok: true

    サンプル Playbook で指定されている設定は次のとおりです。

    crypto_policies_policy: FUTURE
    管理対象ノードで必要な暗号化ポリシー (FUTURE) を設定します。これは、基本ポリシー、またはいくつかのサブポリシーを含む基本ポリシーのどちらかです。指定した基本ポリシーとサブポリシーが、管理対象ノードで使用可能である必要があります。デフォルト値は null です。つまり、設定は変更されず、crypto_policies RHEL システムロールは Ansible fact のみを収集します。
    crypto_policies_reboot_ok: true
    すべてのサービスとアプリケーションが新しい設定ファイルを読み取るように、暗号化ポリシーの変更後にシステムを再起動します。デフォルト値は false です。

    Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.crypto_policies/README.md ファイルを参照してください。

  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/playbook.yml

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  3. Playbook を実行します。

    $ ansible-playbook ~/playbook.yml
警告

システム全体のサブポリシー FIPS:OSPP には、Common Criteria (CC) 認定に必要な暗号化アルゴリズムに関する追加の制限が含まれています。そのため、このサブポリシーを設定すると、システムの相互運用性が低下します。たとえば、3072 ビットより短い RSA 鍵と DH 鍵、追加の SSH アルゴリズム、および複数の TLS グループを使用できません。また、FIPS:OSPP を設定すると、Red Hat コンテンツ配信ネットワーク (CDN) 構造への接続が防止されます。さらに、FIPS:OSPP を使用する IdM デプロイメントには Active Directory (AD) を統合できません。FIPS:OSPP を使用する RHEL ホストと AD ドメイン間の通信が機能しないか、一部の AD アカウントが認証できない可能性があります。

FIPS:OSPP 暗号化サブポリシーを設定すると、システムが CC 非準拠になる ことに注意してください。RHEL システムを CC 標準に準拠させる唯一の正しい方法は、cc-config パッケージで提供されているガイダンスに従うことです。認定済みの RHEL バージョン、検証レポート、および National Information Assurance Partnership (NIAP) で提供されている CC ガイドへのリンクのリストについては、ナレッジベース記事「Compliance Activities and Government Standards」の Common Criteria セクションを参照してください。

検証

  1. コントロールノードで、たとえば verify_playbook.yml という名前の別の Playbook を作成します。

    ---
    - name: Verification
      hosts: managed-node-01.example.com
      tasks:
        - name: Verify active cryptographic policy
          ansible.builtin.include_role:
            name: rhel-system-roles.crypto_policies
        - name: Display the currently active cryptographic policy
          ansible.builtin.debug:
            var: crypto_policies_active

    サンプル Playbook で指定されている設定は次のとおりです。

    crypto_policies_active
    crypto_policies_policy 変数で受け入れられる形式の現在アクティブなポリシー名が含まれているエクスポートされた Ansible fact。
  2. Playbook の構文を検証します。

    $ ansible-playbook --syntax-check ~/verify_playbook.yml
  3. Playbook を実行します。

    $ ansible-playbook ~/verify_playbook.yml
    TASK [debug] **************************
    ok: [host] => {
        "crypto_policies_active": "FUTURE"
    }

    crypto_policies_active 変数は、管理対象ノード上のアクティブなポリシーを示します。

関連情報

  • /usr/share/ansible/roles/rhel-system-roles.crypto_policies/README.md ファイル
  • /usr/share/doc/rhel-system-roles/crypto_policies/ ディレクトリー
  • update-crypto-policies(8) および crypto-policies(7) man ページ

第7章 PKCS #11 で暗号化ハードウェアを使用するようにアプリケーションを設定

スマートカードや、エンドユーザー認証用の暗号化トークン、サーバーアプリケーション用のハードウェアセキュリティーモジュール (HSM) など、専用の暗号化デバイスで秘密情報の一部を分離することで、セキュリティー層が追加されます。RHEL では、PKCS #11 API を使用した暗号化ハードウェアへの対応がアプリケーション間で統一され、暗号ハードウェアでの秘密の分離が複雑なタスクではなくなりました。

7.1. PKCS #11 による暗号化ハードウェアへの対応

Public-Key Cryptography Standard (PKCS) #11 は、暗号化情報を保持し、暗号化機能を実行する暗号化デバイスへのアプリケーションプログラミングインターフェイス (API) を定義します。

PKCS #11 では、各ハードウェアまたはソフトウェアデバイスを統一された方法でアプリケーションに提示するオブジェクトである 暗号化トークン が導入されています。したがって、アプリケーションは、通常はユーザーによって使用されるスマートカードなどのデバイスや、通常はコンピューターによって使用されるハードウェアセキュリティーモジュールを PKCS #11 暗号化トークンとして認識します。

PKCS #11 トークンには、証明書、データオブジェクト、公開鍵、秘密鍵、または秘密鍵を含むさまざまなオブジェクトタイプを保存できます。これらのオブジェクトは、PKCS #11 Uniform Resource Identifier (URI) スキームを通じて一意に識別できます。

PKCS #11 の URI は、オブジェクト属性に従って、PKCS #11 モジュールで特定のオブジェクトを識別する標準的な方法です。これにより、URI の形式で、すべてのライブラリーとアプリケーションを同じ設定文字列で設定できます。

RHEL では、デフォルトでスマートカード用に OpenSC PKCS #11 ドライバーが提供されています。ただし、ハードウェアトークンと HSM には、システムにカウンターパートを持たない独自の PKCS #11 モジュールがあります。この PKCS #11 モジュールは p11-kit ツールで登録できます。これは、システムの登録済みスマートカードドライバーにおけるラッパーとして機能します。

システムで独自の PKCS #11 モジュールを有効にするには、新しいテキストファイルを /etc/pkcs11/modules/ ディレクトリーに追加します。

/etc/pkcs11/modules/ ディレクトリーに新しいテキストファイルを作成すると、独自の PKCS #11 モジュールをシステムに追加できます。たとえば、p11-kit の OpenSC 設定ファイルは、以下のようになります。

$ cat /usr/share/p11-kit/modules/opensc.module
module: opensc-pkcs11.so

7.2. スマートカードに保存した SSH 鍵による認証

スマートカードに ECDSA 鍵と RSA 鍵を作成して保存し、そのスマートカードを使用して OpenSSH クライアントで認証することができます。スマートカード認証は、デフォルトのパスワード認証に代わるものです。

前提条件

  • クライアントで、opensc パッケージをインストールして、pcscd サービスを実行している。

手順

  1. PKCS #11 の URI を含む OpenSC PKCS #11 モジュールが提供する鍵のリストを表示し、その出力を keys.pub ファイルに保存します。

    $ ssh-keygen -D pkcs11: > keys.pub
  2. 公開鍵をリモートサーバーに転送します。ssh-copy-id コマンドを使用し、前の手順で作成した keys.pub ファイルを指定します。

    $ ssh-copy-id -f -i keys.pub <username@ssh-server-example.com>
  3. ECDSA 鍵を使用して <ssh-server-example.com> に接続します。鍵を一意に参照する URI のサブセットのみを使用することもできます。次に例を示します。

    $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" <ssh-server-example.com>
    Enter PIN for 'SSH key':
    [ssh-server-example.com] $

    OpenSSH は p11-kit-proxy ラッパーを使用し、OpenSC PKCS #11 モジュールが p11-kit ツールに登録されているため、前のコマンドを簡略化できます。

    $ ssh -i "pkcs11:id=%01" <ssh-server-example.com>
    Enter PIN for 'SSH key':
    [ssh-server-example.com] $

    PKCS #11 の URI の id= の部分を飛ばすと、OpenSSH が、プロキシーモジュールで利用可能な鍵をすべて読み込みます。これにより、必要な入力の量を減らすことができます。

    $ ssh -i pkcs11: <ssh-server-example.com>
    Enter PIN for 'SSH key':
    [ssh-server-example.com] $
  4. オプション: ~/.ssh/config ファイルで同じ URI 文字列を使用して、設定を永続化できます。

    $ cat ~/.ssh/config
    IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so"
    $ ssh <ssh-server-example.com>
    Enter PIN for 'SSH key':
    [ssh-server-example.com] $

    ssh クライアントユーティリティーが、この URI とスマートカードの鍵を自動的に使用するようになります。

関連情報

  • システム上の p11-kit(8)opensc.conf(5)pcscd(8)ssh(1)、および ssh-keygen(1) man ページ

7.3. スマートカード上の証明書を使用して認証するアプリケーションの設定

アプリケーションでスマートカードを使用して認証することにより、セキュリティーが強化され、自動化が簡素化される場合があります。次の方法を使用して、Public Key Cryptography Standard (PKCS) #11 URI をアプリケーションに統合できます。

  • Firefox Web ブラウザーは、p11-kit-proxy PKCS #11 モジュールを自動的にロードします。つまり、システムで対応しているすべてのスマートカードが自動的に検出されます。TLS クライアント認証を使用する場合、追加のセットアップは必要ありません。サーバーが要求したときにスマートカードの鍵と証明書が自動的に使用されます。
  • アプリケーションが GnuTLS または NSS ライブラリーを使用している場合、PKCS #11 URI はすでにサポートされています。また、OpenSSL ライブラリーに依存するアプリケーションは、openssl-pkcs11 パッケージによって提供される pkcs11 エンジンを通じて、スマートカードを含む暗号化ハードウェアモジュールにアクセスできます。
  • スマートカード上の秘密鍵を操作する必要があり、NSSGnuTLSOpenSSL を使用しないアプリケーションは、特定の PKCS #11 モジュールの PKCS #11 API を使用するのではなく、p11-kit API を直接使用して、スマートカードを含む暗号化ハードウェアモジュールを操作できます。
  • wget ネットワークダウンローダーを使用すると、ローカルに保存された秘密鍵と証明書へのパスの代わりに PKCS #11 URI を指定できます。これにより、安全に保管された秘密鍵と証明書を必要とするタスクのスクリプトの作成が簡素化される可能性があります。以下に例を示します。

    $ wget --private-key 'pkcs11:token=softhsm;id=%01;type=private?pin-value=111111' --certificate 'pkcs11:token=softhsm;id=%01;type=cert' https://example.com/
  • また、curl ツールを使用する場合は、PKCS #11 URI を指定することもできます。

    $ curl --key 'pkcs11:token=softhsm;id=%01;type=private?pin-value=111111' --cert 'pkcs11:token=softhsm;id=%01;type=cert' https://example.com/

関連情報

  • システム上の curl(1)wget(1)、および p11-kit(8) man ページ

7.4. Apache で秘密鍵を保護する HSM の使用

Apache HTTP サーバーは、ハードウェアセキュリティーモジュール (HSM) に保存されている秘密鍵と連携できます。これにより、鍵の漏えいや中間者攻撃を防ぐことができます。通常、これを行うには、ビジーなサーバーに高パフォーマンスの HSM が必要になります。

HTTPS プロトコルの形式でセキュアな通信を行うために、Apache HTTP サーバー (httpd) は OpenSSL ライブラリーを使用します。OpenSSL は、PKCS #11 にネイティブに対応しません。HSM を使用するには、エンジンインターフェイスを介して PKCS #11 モジュールへのアクセスを提供する openssl-pkcs11 パッケージをインストールする必要があります。通常のファイル名ではなく PKCS #11 の URI を使用すると、/etc/httpd/conf.d/ssl.conf 設定ファイルでサーバーの鍵と証明書を指定できます。以下に例を示します。

SSLCertificateFile    "pkcs11:id=%01;token=softhsm;type=cert"
SSLCertificateKeyFile "pkcs11:id=%01;token=softhsm;type=private?pin-value=111111"

httpd-manual パッケージをインストールして、TLS 設定を含む Apache HTTP サーバーの完全ドキュメントを取得します。/etc/httpd/conf.d/ssl.conf 設定ファイルで利用可能なディレクティブの詳細は、/usr/share/httpd/manual/mod/mod_ssl.html を参照してください。

7.5. Nginx で秘密鍵を保護する HSM の使用

Nginx HTTP サーバーは、ハードウェアセキュリティーモジュール (HSM) に保存されている秘密鍵と連携できます。これにより、鍵の漏えいや中間者攻撃を防ぐことができます。通常、これを行うには、ビジーなサーバーに高パフォーマンスの HSM が必要になります。

Nginx は暗号化操作に OpenSSL を使用するため、PKCS #11 への対応は openssl-pkcs11 エンジンを介して行う必要があります。Nginx は現在、HSM からの秘密鍵の読み込みのみに対応します。また、証明書は通常のファイルとして個別に提供する必要があります。/etc/nginx/nginx.conf 設定ファイルの server セクションで ssl_certificate オプションおよび ssl_certificate_key オプションを変更します。

ssl_certificate     /path/to/cert.pem
ssl_certificate_key "engine:pkcs11:pkcs11:token=softhsm;id=%01;type=private?pin-value=111111";

Nginx 設定ファイルの PKCS #11 URI に接頭辞 engine:pkcs11: が必要なことに注意してください。これは、他の pkcs11 接頭辞がエンジン名を参照するためです。

第8章 共通システム証明書の使用

共有システム証明書ストレージは、NSS、GnuTLS、OpenSSL、および Java が、システムの証明書アンカーと、拒否リスト情報を取得するデフォルトソースを共有します。トラストストアには、デフォルトで、Mozilla CA リスト (信頼できるリストおよび信頼できないリスト) が含まれています。システムでは、コア Mozilla CA リストを更新したり、別の証明書リストを選択したりできます。

8.1. システム全体のトラストストア

RHEL では、統合されたシステム全体のトラストストアが /etc/pki/ca-trust/ ディレクトリーおよび /usr/share/pki/ca-trust-source/ ディレクトリーに置かれています。/usr/share/pki/ca-trust-source/ のトラスト設定は、/etc/pki/ca-trust/ の設定よりも低い優先順位で処理されます。

証明書ファイルは、インストールされているサブディレクトリーによって扱われ方が異なります。たとえば、トラストアンカーは /usr/share/pki/ca-trust-source/anchors/ または /etc/pki/ca-trust/source/anchors/ ディレクトリーに属します。

注記

階層暗号化システムでは、トラストアンカーとは、他のパーティーが信頼できると想定する権威あるエンティティーです。X.509 アーキテクチャーでは、ルート証明書はトラストチェーンの元となるトラストアンカーです。チェーンの検証を有効にするには、信頼元がまずトラストアンカーにアクセスできる必要があります。

関連情報

  • システムの update-ca-trust(8) および trust(1) man ページ

8.2. 新しい証明書の追加

新しいソースでシステムのアプリケーションを確認するには、対応する証明書をシステム全体のストアに追加し、update-ca-trust コマンドを使用します。

前提条件

  • ca-certificates パッケージがシステムにインストールされている。

手順

  1. システムで信頼されている CA のリストに、シンプルな PEM または DER のファイルフォーマットに含まれる証明書を追加するには、/usr/share/pki/ca-trust-source/anchors/ ディレクトリーまたは /etc/pki/ca-trust/source/anchors/ ディレクトリーに証明書ファイルをコピーします。以下に例を示します。

    # cp ~/certificate-trust-examples/Cert-trust-test-ca.pem /usr/share/pki/ca-trust-source/anchors/
  2. システム全体のトラストストア設定を更新するには、update-ca-trust コマンドを実行します。

    # update-ca-trust extract
注記

update-ca-trust を事前に実行しなくても、Firefox ブラウザーは追加された証明書を使用できますが、CA を変更するたびに update-ca-trust コマンドを入力してください。Firefox、Chromium および GNOME Web などのブラウザーはファイルをキャッシュするので、ブラウザーのキャッシュをクリアするか、ブラウザーを再起動して、現在のシステム証明書の設定を読み込む必要がある場合があります。

関連情報

  • システムの update-ca-trust(8) および trust(1) man ページ

8.3. 信頼されているシステム証明書の管理

trust コマンドを使用すると、システム全体の共有トラストストアの証明書を便利な方法で管理できます。

  • トラストアンカーのリスト表示、抽出、追加、削除、または変更を行うには、trust コマンドを使用します。このコマンドの組み込みヘルプを表示するには、引数を付けずに、または --help ディレクティブを付けて実行します。

    $ trust
    usage: trust command <args>...
    
    Common trust commands are:
      list             List trust or certificates
      extract          Extract certificates and trust
      extract-compat   Extract trust compatibility bundles
      anchor           Add, remove, change trust anchors
      dump             Dump trust objects in internal format
    
    See 'trust <command> --help' for more information
  • すべてのシステムのトラストアンカーおよび証明書のリストを表示するには、trust list コマンドを実行します。

    $ trust list
    pkcs11:id=%d2%87%b4%e3%df%37%27%93%55%f6%56%ea%81%e5%36%cc%8c%1e%3f%bd;type=cert
        type: certificate
        label: ACCVRAIZ1
        trust: anchor
        category: authority
    
    pkcs11:id=%a6%b3%e1%2b%2b%49%b6%d7%73%a1%aa%94%f5%01%e7%73%65%4c%ac%50;type=cert
        type: certificate
        label: ACEDICOM Root
        trust: anchor
        category: authority
    ...
  • トラストアンカーをシステム全体のトラストストアに保存するには、trust anchor サブコマンドを使用し、証明書のパスを指定します。<path.to/certificate.crt> を、証明書およびそのファイル名へのパスに置き換えます。

    # trust anchor <path.to/certificate.crt>
  • 証明書を削除するには、証明書のパス、または証明書の ID を使用します。

    # trust anchor --remove <path.to/certificate.crt>
    # trust anchor --remove "pkcs11:id=<%AA%BB%CC%DD%EE>;type=cert"

関連情報

  • trust コマンドのすべてのサブコマンドは、以下のような詳細な組み込みヘルプを提供します。

    $ trust list --help
    usage: trust list --filter=<what>
    
      --filter=<what>     filter of what to export
                            ca-anchors        certificate anchors
    ...
      --purpose=<usage>   limit to certificates usable for the purpose
                            server-auth       for authenticating servers
    ...

関連情報

  • システムの update-ca-trust(8) および trust(1) man ページ

第9章 セキュリティーコンプライアンスおよび脆弱性スキャンの開始

9.1. RHEL における設定コンプライアンスツール

次の設定コンプライアンスツールを使用すると、Red Hat Enterprise Linux で完全に自動化されたコンプライアンス監査を実行できます。このツールは SCAP (Security Content Automation Protocol) 規格に基づいており、コンプライアンスポリシーの自動化に合わせるように設計されています。

SCAP Workbench
scap-workbench グラフィカルユーティリティーは、単一のローカルシステムまたはリモートシステム上で設定および脆弱性スキャンを実行するように設計されています。これらのスキャンと評価に基づくセキュリティーレポートの生成にも使用できます。
OpenSCAP

OpenSCAP ライブラリーは、付随する oscap コマンドラインユーティリティーとともに、ローカルシステムで設定スキャンと脆弱性スキャンを実行するように設計されています。これにより、設定コンプライアンスのコンテンツを検証し、スキャンおよび評価に基づいてレポートおよびガイドを生成します。

重要

OpenSCAP の使用中にメモリー消費の問題が発生する可能性があります。これにより、プログラムが途中で停止し、結果ファイルが生成されない可能性があります。詳細については、ナレッジベース記事 OpenSCAP のメモリー消費の問題 を参照してください。

SCAP Security Guide (SSG)
scap-security-guide パッケージは、Linux システム用のセキュリティーポリシーのコレクションを提供します。このガイダンスは、セキュリティー強化に関する実践的なアドバイスのカタログで構成されています (該当する場合は、法規制要件へのリンクが含まれます)。このプロジェクトは、一般的なポリシー要件と特定の実装ガイドラインとの間にあるギャップを埋めることを目的としています。
Script Check Engine (SCE)
SCAP プロトコルの拡張機能である SCE を使用すると、管理者は Bash、Python、Ruby などのスクリプト言語を使用してセキュリティーコンテンツを作成できます。SCE 拡張機能は、openscap-engine-sce パッケージで提供されます。SCE 自体は SCAP 標準規格の一部ではありません。

複数のリモートシステムで自動コンプライアンス監査を実行する必要がある場合は、Red Hat Satellite 用の OpenSCAP ソリューションを利用できます。

9.2. Red Hat Security Advisories OVAL フィード

Red Hat Enterprise Linux のセキュリティー監査機能は、標準規格セキュリティー設定共通化手順 (Security Content Automation Protocol (SCAP)) を基にしています。SCAP は、自動化された設定、脆弱性およびパッチの確認、技術的な制御コンプライアンスアクティビティー、およびセキュリティーの測定に対応している多目的な仕様のフレームワークです。

SCAP 仕様は、スキャナーまたはポリシーエディターの実装が義務付けられていなくても、セキュリティーコンテンツの形式がよく知られて標準化されているエコシステムを作成します。これにより、組織は、採用しているセキュリティーベンダーの数に関係なく、セキュリティーポリシー (SCAP コンテンツ) を構築するのは一度で済みます。

セキュリティー検査言語 OVAL (Open Vulnerability Assessment Language) は、SCAP に不可欠で最も古いコンポーネントです。その他のツールやカスタマイズされたスクリプトとは異なり、OVAL は、宣言型でリソースが必要な状態を記述します。OVAL コードは、スキャナーと呼ばれる OVAL インタープリターツールを使用して直接実行されることは決してありません。OVAL が宣言型であるため、評価されるシステムの状態が偶然修正されることはありません。

他のすべての SCAP コンポーネントと同様に、OVAL は XML に基づいています。SCAP 標準規格は、いくつかのドキュメント形式を定義します。この形式にはそれぞれ異なる種類の情報が記載され、異なる目的に使用されます。

Red Hat 製品セキュリティー を使用すると、Red Hat 製品をお使いのお客様に影響を及ぼすセキュリティー問題をすべて追跡して調査します。Red Hat カスタマーポータルで簡潔なパッチやセキュリティーアドバイザリーを適時提供します。Red Hat は OVAL パッチ定義を作成してサポートし、マシンが判読可能なセキュリティーアドバイザリーを提供します。

プラットフォーム、バージョン、およびその他の要因が異なるため、Red Hat 製品セキュリティーによる脆弱性の重大度定性評価は、サードパーティーが提供する Common Vulnerability Scoring System (CHC) のベースライン評価と完全に一致しているわけではありません。したがって、サードパーティーが提供する定義ではなく、RHSA OVAL 定義を使用することが推奨されます。

RHSA OVAL 定義 は完全なパッケージとして利用でき、新しいセキュリティーアドバイザリーが Red Hat カスタマーポータルで利用可能になってから 1 時間以内に更新されます。

各 OVAL パッチ定義は、Red Hat セキュリティーアドバイザリー (RHSA) と 1 対 1 にマッピングしています。RHSA には複数の脆弱性に対する修正が含まれるため、各脆弱性は、共通脆弱性識別子 (Common Vulnerabilities and Exposures (CVE)) 名ごとに表示され、公開バグデータベースの該当箇所へのリンクが示されます。

RHSA OVAL 定義は、システムにインストールされている RPM パッケージで脆弱なバージョンを確認するように設計されています。この定義は拡張でき、パッケージが脆弱な設定で使用されているかどうかを見つけるなど、さらに確認できるようにすることができます。この定義は、Red Hat が提供するソフトウェアおよび更新に対応するように設計されています。サードパーティーソフトウェアのパッチ状態を検出するには、追加の定義が必要です。

注記

Red Hat Insights for Red Hat Enterprise Linux コンプライアンスサービス は、IT セキュリティーおよびコンプライアンス管理者が Red Hat Enterprise Linux システムのセキュリティーポリシーのコンプライアンスを評価、監視、およびレポートするのに役立ちます。また、コンプライアンスサービス UI 内で完全に SCAP セキュリティーポリシーを作成および管理することもできます。

9.3. 脆弱性スキャン

9.3.1. Red Hat Security Advisories OVAL フィード

Red Hat Enterprise Linux のセキュリティー監査機能は、標準規格セキュリティー設定共通化手順 (Security Content Automation Protocol (SCAP)) を基にしています。SCAP は、自動化された設定、脆弱性およびパッチの確認、技術的な制御コンプライアンスアクティビティー、およびセキュリティーの測定に対応している多目的な仕様のフレームワークです。

SCAP 仕様は、スキャナーまたはポリシーエディターの実装が義務付けられていなくても、セキュリティーコンテンツの形式がよく知られて標準化されているエコシステムを作成します。これにより、組織は、採用しているセキュリティーベンダーの数に関係なく、セキュリティーポリシー (SCAP コンテンツ) を構築するのは一度で済みます。

セキュリティー検査言語 OVAL (Open Vulnerability Assessment Language) は、SCAP に不可欠で最も古いコンポーネントです。その他のツールやカスタマイズされたスクリプトとは異なり、OVAL は、宣言型でリソースが必要な状態を記述します。OVAL コードは、スキャナーと呼ばれる OVAL インタープリターツールを使用して直接実行されることは決してありません。OVAL が宣言型であるため、評価されるシステムの状態が偶然修正されることはありません。

他のすべての SCAP コンポーネントと同様に、OVAL は XML に基づいています。SCAP 標準規格は、いくつかのドキュメント形式を定義します。この形式にはそれぞれ異なる種類の情報が記載され、異なる目的に使用されます。

Red Hat 製品セキュリティー を使用すると、Red Hat 製品をお使いのお客様に影響を及ぼすセキュリティー問題をすべて追跡して調査します。Red Hat カスタマーポータルで簡潔なパッチやセキュリティーアドバイザリーを適時提供します。Red Hat は OVAL パッチ定義を作成してサポートし、マシンが判読可能なセキュリティーアドバイザリーを提供します。

プラットフォーム、バージョン、およびその他の要因が異なるため、Red Hat 製品セキュリティーによる脆弱性の重大度定性評価は、サードパーティーが提供する Common Vulnerability Scoring System (CHC) のベースライン評価と完全に一致しているわけではありません。したがって、サードパーティーが提供する定義ではなく、RHSA OVAL 定義を使用することが推奨されます。

RHSA OVAL 定義 は完全なパッケージとして利用でき、新しいセキュリティーアドバイザリーが Red Hat カスタマーポータルで利用可能になってから 1 時間以内に更新されます。

各 OVAL パッチ定義は、Red Hat セキュリティーアドバイザリー (RHSA) と 1 対 1 にマッピングしています。RHSA には複数の脆弱性に対する修正が含まれるため、各脆弱性は、共通脆弱性識別子 (Common Vulnerabilities and Exposures (CVE)) 名ごとに表示され、公開バグデータベースの該当箇所へのリンクが示されます。

RHSA OVAL 定義は、システムにインストールされている RPM パッケージで脆弱なバージョンを確認するように設計されています。この定義は拡張でき、パッケージが脆弱な設定で使用されているかどうかを見つけるなど、さらに確認できるようにすることができます。この定義は、Red Hat が提供するソフトウェアおよび更新に対応するように設計されています。サードパーティーソフトウェアのパッチ状態を検出するには、追加の定義が必要です。

注記

Red Hat Insights for Red Hat Enterprise Linux コンプライアンスサービス は、IT セキュリティーおよびコンプライアンス管理者が Red Hat Enterprise Linux システムのセキュリティーポリシーのコンプライアンスを評価、監視、およびレポートするのに役立ちます。また、コンプライアンスサービス UI 内で完全に SCAP セキュリティーポリシーを作成および管理することもできます。

9.3.2. システムの脆弱性のスキャン

oscap コマンドラインユーティリティーを使用すると、ローカルシステムのスキャン、設定コンプライアンスコンテンツの確認、ならびにスキャンおよび評価を基にしたレポートとガイドの生成が可能です。このユーティリティーは、OpenSCAP ライブラリーのフロントエンドとしてサービスを提供し、その機能を処理する SCAP コンテンツのタイプに基づいてモジュール (サブコマンド) にグループ化します。

前提条件

  • openscap-scanner および bzip2 パッケージがインストールされます。

手順

  1. システムに最新 RHSA OVAL 定義をダウンロードします。

    # wget -O - https://www.redhat.com/security/data/oval/v2/RHEL8/rhel-8.oval.xml.bz2 | bzip2 --decompress > rhel-8.oval.xml
  2. システムの脆弱性をスキャンし、vulnerability.html ファイルに結果を保存します。

    # oscap oval eval --report vulnerability.html rhel-8.oval.xml

検証

  • 結果をブラウザーで確認します。以下に例を示します。

    $ firefox vulnerability.html &

関連情報

9.3.3. リモートシステムの脆弱性のスキャン

SSH プロトコル経由で oscap-ssh ツールを使用して、OpenSCAP スキャナーでリモートシステムの脆弱性をチェックできます。

前提条件

  • openscap-utils および bzip2 パッケージは、スキャンに使用するシステムにインストールされます。
  • リモートシステムに openscap-scanner パッケージがインストールされている。
  • リモートシステムで SSH サーバーが実行している。

手順

  1. システムに最新 RHSA OVAL 定義をダウンロードします。

    # wget -O - https://www.redhat.com/security/data/oval/v2/RHEL8/rhel-8.oval.xml.bz2 | bzip2 --decompress > rhel-8.oval.xml
  2. リモートシステムの脆弱性をスキャンし、結果をファイルに保存します。

    # oscap-ssh <username>@<hostname> <port> oval eval --report <scan-report.html> rhel-8.oval.xml

    以下を置き換えます。

    • <username>@<hostname> は、リモートシステムのユーザー名とホスト名に置き換えます。
    • <port> は、リモートシステムにアクセスできるポート番号 (例: 22) です。
    • <scan-report.html> は、oscap がスキャン結果を保存するファイル名です。

9.4. 設定コンプライアンススキャン

9.4.1. RHEL の設定コンプライアンス

設定コンプライアンススキャンを使用して、特定の組織で定義されているベースラインに準拠できます。たとえば、米国政府と協力している場合は、システムを Operating System Protection Profile (OSPP) に準拠させ、支払い処理業者の場合は、システムを Payment Card Industry Data Security Standard (PCI-DSS) に準拠させなければならない場合があります。設定コンプライアンススキャンを実行して、システムセキュリティーを強化することもできます。

Red Hat は、対象コンポーネント向けの Red Hat のベストプラクティスに従っているため、SCAP Security Guide パッケージで提供される Security Content Automation Protocol (SCAP) コンテンツに従うことを推奨します。

SCAP Security Guide パッケージは、SCAP 1.2 および SCAP 1.3 標準規格に準拠するコンテンツを提供します。openscap scanner ユーティリティーは、SCAP Security Guide パッケージで提供される SCAP 1.2 および SCAP 1.3 コンテンツの両方と互換性があります。

重要

設定コンプライアンススキャンを実行しても、システムが準拠しているとは限りません。

SCAP Security Guide スイートは、データストリームドキュメントの形式で、複数のプラットフォームのプロファイルを提供します。データストリームは、定義、ベンチマーク、プロファイル、および個々のルールが含まれるファイルです。各ルールでは、コンプライアンスの適用性と要件を指定します。RHEL は、セキュリティーポリシーを扱う複数のプロファイルを提供します。Red Hat データストリームには、業界標準の他に、失敗したルールの修正に関する情報も含まれます。

コンプライアンススキャンリソースの構造

Data stream
   ├── xccdf
   |      ├── benchmark
   |            ├── profile
   |            |    ├──rule reference
   |            |    └──variable
   |            ├── rule
   |                 ├── human readable data
   |                 ├── oval reference
   ├── oval          ├── ocil reference
   ├── ocil          ├── cpe reference
   └── cpe           └── remediation

プロファイルは、OSPP、PCI-DSS、Health Insurance Portability and Accountability Act (HIPAA) などのセキュリティーポリシーに基づく一連のルールです。これにより、セキュリティー標準規格に準拠するために、システムを自動で監査できます。

プロファイルを変更 (調整) して、パスワードの長さなどの特定のルールをカスタマイズできます。プロファイルの調整の詳細は、SCAP Workbench を使用したセキュリティープロファイルのカスタマイズ を参照してください。

9.4.2. OpenSCAP スキャン結果の例

OpenSCAP スキャンに適用されるデータストリームとプロファイル、およびシステムのさまざまなプロパティーに応じて、各ルールから特定の結果が生成される場合があります。以下に考えられる結果とその意味の簡単な説明を示します。

Pass
スキャンでは、このルールとの競合が見つかりませんでした。
Fail
スキャンで、このルールとの競合が検出されました。
Not checked
OpenSCAP はこのルールの自動評価を実行しません。システムがこのルールに手動で準拠しているかどうかを確認してください。
Not applicable
このルールは、現在の設定には適用されません。
Not selected
このルールはプロファイルには含まれません。OpenSCAP はこのルールを評価せず、結果にこのようなルールは表示されません。
Error
スキャンでエラーが発生しました。詳細は、--verbose DEVEL オプションを指定して oscap コマンドで確認できます。Red Hat カスタマーポータル でサポートケースを作成するか、Red Hat Jira の RHEL プロジェクト でチケットを作成します。
Unknown
スキャンで予期しない状況が発生しました。詳細は、`--verbose DEVEL オプションを指定して oscap コマンドを入力できます。Red Hat カスタマーポータル でサポートケースを作成するか、Red Hat Jira の RHEL プロジェクト でチケットを作成します。

9.4.3. 設定コンプライアンスのプロファイルの表示

スキャンまたは修復にプロファイルを使用することを決定する前に、oscap info サブコマンドを使用して、プロファイルを一覧表示し、詳細な説明を確認できます。

前提条件

  • openscap-scanner パッケージおよび scap-security-guide パッケージがインストールされている。

手順

  1. SCAP Security Guide プロジェクトが提供するセキュリティーコンプライアンスプロファイルで利用可能なファイルをすべて表示します。

    $ ls /usr/share/xml/scap/ssg/content/
    ssg-firefox-cpe-dictionary.xml  ssg-rhel6-ocil.xml
    ssg-firefox-cpe-oval.xml        ssg-rhel6-oval.xml
    …
    ssg-rhel6-ds-1.2.xml          ssg-rhel8-oval.xml
    ssg-rhel8-ds.xml              ssg-rhel8-xccdf.xml
    …
  2. oscap info サブコマンドを使用して、選択したデータストリームに関する詳細情報を表示します。データストリームを含む XML ファイルは、名前に -ds 文字列で示されます。Profiles セクションでは、利用可能なプロファイルと、その ID のリストを確認できます。

    $ oscap info /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
    Profiles:
    …
      Title: Health Insurance Portability and Accountability Act (HIPAA)
        Id: xccdf_org.ssgproject.content_profile_hipaa
      Title: PCI-DSS v3.2.1 Control Baseline for Red Hat Enterprise Linux 8
        Id: xccdf_org.ssgproject.content_profile_pci-dss
      Title: OSPP - Protection Profile for General Purpose Operating Systems
        Id: xccdf_org.ssgproject.content_profile_ospp
    …
  3. データストリームファイルからプロファイルを選択し、選択したプロファイルに関する追加情報を表示します。そのためには、oscap info--profile オプションを指定した後に、直前のコマンドの出力で表示された ID の最後のセクションを指定します。たとえば、HIPPA プロファイルの ID は xccdf_org.ssgproject.content_profile_hipaa で、--profile オプションの値は hipaa です。

    $ oscap info --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
    …
    Profile
    	Title: Health Insurance Portability and Accountability Act (HIPAA)
    
    	Description: The HIPAA Security Rule establishes U.S. national standards to protect individuals’ electronic personal health information that is created, received, used, or maintained by a covered entity.
    …

関連情報

9.4.4. 特定のベースラインによる設定コンプライアンスの評価

oscap コマンドラインツールを使用して、システムまたはリモートシステムが特定のベースラインに準拠しているかどうかを判断し、結果をレポートに保存できます。

前提条件

  • openscap-scanner パッケージおよび scap-security-guide パッケージがインストールされている。
  • システムが準拠する必要があるベースライン内のプロファイルの ID を知っている必要があります。ID を見つけるには、設定コンプライアンスのプロファイルの表示 セクションを参照してください。

手順

  1. ローカルシステムをスキャンして、選択したプロファイルへの準拠を評価し、スキャン結果をファイルに保存します。

    $ oscap xccdf eval --report <scan-report.html> --profile <profileID> /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

    以下を置き換えます。

    • <scan-report.html> は、oscap がスキャン結果を保存するファイル名です。
    • <profileID> は、システムが準拠する必要があるプロファイル ID (例: hipaa) です。
  2. オプション: リモートシステムをスキャンして、選択したプロファイルへの準拠を評価し、スキャン結果をファイルに保存します。

    $ oscap-ssh <username>@<hostname> <port> xccdf eval --report <scan-report.html> --profile <profileID> /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

    以下を置き換えます。

    • <username>@<hostname> は、リモートシステムのユーザー名とホスト名に置き換えます。
    • <port> は、リモートシステムにアクセスできるポート番号です。
    • <scan-report.html> は、oscap がスキャン結果を保存するファイル名です。
    • <profileID> は、システムが準拠する必要があるプロファイル ID (例: hipaa) です。

関連情報

  • システム上の scap-security-guide(8) man ページ
  • /usr/share/doc/scap-security-guide/ ディレクトリーにある SCAP Security Guide ドキュメント
  • /usr/share/doc/scap-security-guide/guides/ssg-rhel8-guide-index.html - scap-security-guide-doc パッケージでインストールされた Red Hat Enterprise Linux 8 のセキュアな設定ガイド
  • OpenSCAP のメモリー消費の問題

9.5. 特定のベースラインに合わせたシステムの修復

特定のベースラインに合わせて RHEL システムを修正できます。SCAP Security Guide で提供されるプロファイルに合わせてシステムを修正できます。使用可能なプロファイルのリストの詳細は、設定コンプライアンスのプロファイルの表示 を参照してください。

警告

修正 オプションが有効な状態でのシステム評価は、慎重に行わないとシステムが機能不全に陥る場合があります。Red Hat は、セキュリティーを強化した修正で加えられた変更を元に戻す自動手段は提供していません。修復は、デフォルト設定の RHEL システムで対応しています。インストール後にシステムが変更した場合は、修正を実行しても、必要なセキュリティープロファイルに準拠しない場合があります。

前提条件

  • scap-security-guide パッケージがインストールされている。

手順

  1. --remediate オプションを指定した oscap コマンドを使用してシステムを修復します。

    # oscap xccdf eval --profile <profileID> --remediate /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

    <profileID> は、システムが準拠する必要があるプロファイル ID (例: hipaa) に置き換えます。

  2. システムを再起動します。

検証

  1. システムがプロファイルに準拠しているかどうかを評価し、スキャン結果をファイルに保存します。

    $ oscap xccdf eval --report <scan-report.html> --profile <profileID> /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

    以下を置き換えます。

    • <scan-report.html> は、oscap がスキャン結果を保存するファイル名です。
    • <profileID> は、システムが準拠する必要があるプロファイル ID (例: hipaa) です。

関連情報

9.6. SSG Ansible Playbook を使用して、特定のベースラインに合わせてシステムを修正する

SCAP Security Guide プロジェクトの Ansible Playbook ファイルを使用して、特定のベースラインに合わせてシステムを修正できます。この例では Health Insurance Portability and Accountability Act (HIPAA) プロファイルを使用していますが、SCAP Security Guide で提供されている他のプロファイルに合わせて修正することもできます。使用可能なプロファイルのリストの詳細は、設定コンプライアンスのプロファイルの表示 を参照してください。

警告

修正 オプションが有効な状態でのシステム評価は、慎重に行わないとシステムが機能不全に陥る場合があります。Red Hat は、セキュリティーを強化した修正で加えられた変更を元に戻す自動手段は提供していません。修復は、デフォルト設定の RHEL システムで対応しています。インストール後にシステムが変更した場合は、修正を実行しても、必要なセキュリティープロファイルに準拠しない場合があります。

前提条件

手順

  1. Ansible を使用して、HIPAA に準拠するようにシステムを修正します。

    # ansible-playbook -i localhost, -c local /usr/share/scap-security-guide/ansible/rhel8-playbook-hipaa.yml
  2. システムを再起動します。

検証

  1. システムが HIPAA プロファイルに準拠しているかどうかを評価し、スキャン結果をファイルに保存します。

    # oscap xccdf eval --profile hipaa --report <scan-report.html> /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

    <scan-report.html> は、oscap がスキャン結果を保存するファイル名に置き換えます。

関連情報

9.7. システムを特定のベースラインに合わせるための修復用 Ansible Playbook の作成

システムを特定のベースラインに合わせるために必要な修復のみを含む Ansible Playbook を作成できます。この Playbook は、すでに満たされている要件を含んでいないため、小型です。Playbook を作成しても、システムは一切変更されません。ここでは、後で適用するためのファイルを準備するだけです。この例では、Health Insurance Portability and Accountability Act (HIPAA) プロファイルを使用します。

注記

RHEL 8.6 では、Ansible Engine は、組み込みモジュールのみを含む ansible-core パッケージに置き換えられました。Ansible 修復の多くは、community コレクションおよび Portable Operating System Interface (POSIX) コレクションのモジュールを使用することに注意してください。これは組み込みモジュールには含まれていません。この場合は、Bash 修復を Ansible 修復の代わりに使用できます。RHEL 8.6 の Red Hat Connector には、修復 Playbook が Ansible Core で機能するために必要な Ansible モジュールが含まれています。

前提条件

  • scap-security-guide パッケージがインストールされている。

手順

  1. システムをスキャンして結果を保存します。

    # oscap xccdf eval --profile hipaa --results <hipaa-results.xml> /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
  2. 結果が含まれるファイルで、結果 ID の値を見つけます。

    # oscap info <hipaa-results.xml>
  3. 手順 1 で生成されたファイルに基づいて Ansible Playbook を生成します。

    # oscap xccdf generate fix --fix-type ansible --result-id <xccdf_org.open-scap_testresult_xccdf_org.ssgproject.content_profile_hipaa> --output <hipaa-remediations.yml> <hipaa-results.xml>
  4. 生成されたファイルを確認します。これには、手順 1 で実行されたスキャン中に失敗したルールの Ansible 修復が含まれています。この生成されたファイルを確認した後、ansible-playbook <hipaa-remediations.yml> コマンドを使用して適用できます。

検証

  • お使いのテキストエディターで、手順 1 で実行したスキャンで失敗したルールが、生成した <hipaa-remediations.yml> ファイルに含まれていることを確認します。

関連情報

9.8. 後でアプリケーションを修復するための Bash スクリプトの作成

この手順を使用して、システムを HIPAA などのセキュリティープロファイルと調整する修正を含む Bash スクリプトを作成します。次の手順では、システムに変更を加えることなく、後のアプリケーション用にファイルを準備する方法を説明します。

前提条件

  • RHEL システムに、scap-security-guide パッケージがインストールされている。

手順

  1. oscap コマンドを使用してシステムをスキャンし、結果を XML ファイルに保存します。以下の例では、oscaphipaa プロファイルに対してシステムを評価します。

    # oscap xccdf eval --profile hipaa --results <hipaa-results.xml> /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
  2. 結果が含まれるファイルで、結果 ID の値を見つけます。

    # oscap info <hipaa-results.xml>
  3. 手順 1 で生成された結果ファイルに基づいて Bash スクリプトを生成します。

    # oscap xccdf generate fix --fix-type bash --result-id <xccdf_org.open-scap_testresult_xccdf_org.ssgproject.content_profile_hipaa> --output <hipaa-remediations.sh> <hipaa-results.xml>
  4. <hipaa-remediations.sh> ファイルには、手順 1 で実行されたスキャン中に失敗したルールの修復が含まれます。この生成されたファイルを確認したら、このファイルと同じディレクトリー内で、./<hipaa-remediations.sh> コマンドを使用してファイルを適用できます。

検証

  • お使いのテキストエディターで、手順 1 で実行したスキャンで失敗したルールが <hipaa-remediations.sh> ファイルに含まれていることを確認します。

関連情報

  • システム上の scap-security-guide(8)oscap(8)bash(1) man ページ

9.9. SCAP Workbench を使用したカスタムプロファイルでシステムのスキャン

SCAP Workbench (scap-workbench) パッケージはグラフィカルユーティリティーで、1 台のローカルシステムまたはリモートシステムで設定スキャンと脆弱性スキャンを実行し、システムの修復を実行して、スキャン評価に基づくレポートを生成します。oscap コマンドラインユーティリティーとの比較は、SCAP Workbench には限定的な機能しかないことに注意してください。SCAP Workbench は、データストリームファイルの形式でセキュリティーコンテンツを処理します。

9.9.1. SCAP Workbench を使用したシステムのスキャンおよび修復

選択したセキュリティーポリシーに対してシステムを評価するには、以下の手順に従います。

前提条件

  • scap-workbench パッケージがシステムにインストールされている。

手順

  1. GNOME Classic デスクトップ環境から SCAP Workbench を実行するには、Super キーを押して アクティビティーの概要 を開き、scap-workbenchと入力して Enterを押します。または、次のコマンドを実行します。

    $ scap-workbench &
  2. 以下のオプションのいずれかを使用してセキュリティーポリシーを選択します。

    • 開始ウィンドウの Load Content ボタン
    • Open content from SCAP Security Guide
    • File メニューの Open Other Content で、XCCDF、SCAP RPM、またはデータストリームファイルの各ファイルを検索します。

      SCAP workbench の起動
  3. Remediate チェックボックスを選択して、システム設定の自動修正を行うことができます。このオプションを有効にすると、SCAP Workbench は、ポリシーにより適用されるセキュリティールールに従ってシステム設定の変更を試みます。このプロセスは、システムスキャン時に失敗した関連チェックを修正する必要があります。

    警告

    修正 オプションが有効な状態でのシステム評価は、慎重に行わないとシステムが機能不全に陥る場合があります。Red Hat は、セキュリティーを強化した修正で加えられた変更を元に戻す自動手段は提供していません。修復は、デフォルト設定の RHEL システムで対応しています。インストール後にシステムが変更した場合は、修正を実行しても、必要なセキュリティープロファイルに準拠しない場合があります。

  4. Scan ボタンをクリックし、選択したプロファイルでシステムをスキャンします。

    SCAP ワークベンチの結果
  5. スキャン結果を XCCDF ファイル、ARF ファイル、または HTML ファイルの形式で保存するには、Save Results コンボボックスをクリックします。HTML Report オプションを選択して、スキャンレポートを、人間が判読できる形式で生成します。XCCDF 形式および ARF (データストリーム) 形式は、追加の自動処理に適しています。3 つのオプションはすべて繰り返し選択できます。
  6. 結果ベースの修復をファイルにエクスポートするには、ポップアップメニューの Generate remediation role を使用します。

9.9.2. SCAP Workbench を使用したセキュリティープロファイルのカスタマイズ

セキュリティープロファイルをカスタマイズするには、特定のルール (パスワードの最小長など) のパラメーターを変更し、別の方法で対象とするルールを削除し、追加のルールを選択して内部ポリシーを実装できます。プロファイルをカスタマイズして新しいルールの定義はできません。

以下の手順は、プロファイルをカスタマイズ (調整) するための SCAP Workbench の使用を示しています。oscap コマンドラインユーティリティーで使用するようにカスタマイズしたプロファイルを保存することもできます。

前提条件

  • scap-workbench パッケージがシステムにインストールされている。

手順

  1. SCAP Workbench を実行し、Open content from SCAP Security Guide または File メニューの Open Other Content を使用してカスタマイズするプロファイルを選択します。
  2. 選択したセキュリティープロファイルを必要に応じて調整するには、Customize ボタンをクリックします。

    これにより、元のデータストリームファイルを変更せずに現在選択されているプロファイルを変更できる新しいカスタマイズウィンドウが開きます。新しいプロファイル ID を選択します。

    新しいプロファイルの ID の選択
  3. 論理グループに分けられたルールを持つツリー構造を使用するか、Search フィールドを使用して変更するルールを検索します。
  4. ツリー構造のチェックボックスを使用した include ルールまたは exclude ルール、または必要に応じてルールの値を変更します。

    OSPP プロファイルにおけるルールのカスタマイズ
  5. OK ボタンをクリックして変更を確認します。
  6. 変更内容を永続的に保存するには、以下のいずれかのオプションを使用します。

    • File メニューの Save Customization Only を使用して、カスタマイズファイルを別途保存します。
    • File メニュー Save All を選択して、すべてのセキュリティーコンテンツを一度に保存します。

      Into a directory オプションを選択すると、SCAP Workbench は、データストリームファイルおよびカスタマイズファイルの両方を、指定した場所に保存します。これはバックアップソリューションとして使用できます。

      As RPM オプションを選択すると、SCAP Workbench に、データストリームファイル、ならびにカスタマイズファイルを含む RPM パッケージの作成を指示できます。これは、リモートでスキャンできないシステムにセキュリティーコンテンツを配布したり、詳細な処理のためにコンテンツを配信するのに便利です。

注記

SCAP Workbench は、カスタマイズしたプロファイル向けの結果ベースの修正に対応していないため、oscap コマンドラインユーティリティーでエクスポートした修正を使用します。

9.10. コンテナーおよびコンテナーイメージの脆弱性スキャン

以下の手順を使用して、コンテナーまたはコンテナーイメージのセキュリティー脆弱性を検索します。

注記

oscap-podman コマンドは、RHEL 8.2 で利用できます。RHEL 8.1 および 8.0 の場合は、ナレッジベースの記事 Using OpenSCAP for scanning containers in RHEL 8 で説明されている回避策を利用します。

前提条件

  • openscap-utils および bzip2 パッケージがインストールされます。

手順

  1. システムに最新 RHSA OVAL 定義をダウンロードします。

    # wget -O - https://www.redhat.com/security/data/oval/v2/RHEL8/rhel-8.oval.xml.bz2 | bzip2 --decompress > rhel-8.oval.xml
  2. コンテナーまたはコンテナーイメージの ID を取得します。以下に例を示します。

    # podman images
    REPOSITORY                            TAG      IMAGE ID       CREATED       SIZE
    registry.access.redhat.com/ubi8/ubi   latest   096cae65a207   7 weeks ago   239 MB
  3. コンテナーまたはコンテナーイメージで脆弱性をスキャンし、結果を vulnerability.html ファイルに保存します。

    # oscap-podman 096cae65a207 oval eval --report vulnerability.html rhel-8.oval.xml

    oscap-podman コマンドには root 権限が必要で、コンテナーの ID は最初の引数であることに注意してください。

検証

  • 結果をブラウザーで確認します。以下に例を示します。

    $ firefox vulnerability.html &

関連情報

  • 詳細は、oscap-podman(8) および oscap(8) の man ページを参照してください。

9.11. 特定のベースラインを使用したコンテナーまたはコンテナーイメージのセキュリティーコンプライアンスの評価

コンテナーまたはコンテナーイメージが、Operating System Protection Profile (OSPP)、Payment Card Industry Data Security Standard (PCI-DSS)、Health Insurance Portability and Accountability Act (HIPAA) などの特定のセキュリティーベースラインに準拠しているかどうかを評価できます。

注記

oscap-podman コマンドは、RHEL 8.2 で利用できます。RHEL 8.1 および 8.0 の場合は、ナレッジベースの記事 Using OpenSCAP for scanning containers in RHEL 8 で説明されている回避策を利用します。

前提条件

  • openscap-utils パッケージおよび scap-security-guide パッケージがインストールされている。
  • システムへの root アクセス権があります。

手順

  1. コンテナーまたはコンテナーイメージの ID を見つけます。

    1. コンテナーの ID を見つけるには、podman ps -a コマンドを入力します。
    2. コンテナーイメージの ID を見つけるには、podman images コマンドを入力します。
  2. コンテナーまたはコンテナーイメージがプロファイルに準拠しているかどうかを評価し、スキャン結果をファイルに保存します。

    # oscap-podman <ID> xccdf eval --report <scan-report.html> --profile <profileID> /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

    以下を置き換えます。

    • <ID> は、コンテナーまたはコンテナーイメージの ID です。
    • <scan-report.html> は、oscap がスキャン結果を保存するファイル名です。
    • <profileID> は、システムが準拠する必要があるプロファイル ID (例: hipaaospppci-dss) です。

検証

  • 結果をブラウザーで確認します。以下に例を示します。

    $ firefox <scan-report.html> &amp;
注記

notapplicable とマークされたルールは、ベアメタルおよび仮想化システムにのみ適用され、コンテナーまたはコンテナーイメージには適用されません。

関連情報

  • oscap-podman(8) および scap-security-guide(8) の man ページ。
  • /usr/share/doc/scap-security-guide/ ディレクトリー。

9.12. AIDE で整合性の確認

Advanced Intrusion Detection Environment (AIDE) は、システムにファイルのデータベースを作成し、そのデータベースを使用してファイルの整合性を確保し、システムの侵入を検出するユーティリティーです。

9.12.1. AIDE のインストール

AIDE を使用してファイル整合性チェックを開始するには、対応するパッケージをインストールし、AIDE データベースを初期化する必要があります。

前提条件

  • AppStream リポジトリーが有効になっている。

手順

  1. aide パッケージをインストールします。

    # yum install aide
  2. 初期データベースを生成します。

    # aide --init
    Start timestamp: 2024-07-08 10:39:23 -0400 (AIDE 0.16)
    AIDE initialized database at /var/lib/aide/aide.db.new.gz
    
    Number of entries:	55856
    
    ---------------------------------------------------
    The attributes of the (uncompressed) database(s):
    ---------------------------------------------------
    
    /var/lib/aide/aide.db.new.gz
    …
      SHA512   : mZaWoGzL2m6ZcyyZ/AXTIowliEXWSZqx
                 IFYImY4f7id4u+Bq8WeuSE2jasZur/A4
                 FPBFaBkoCFHdoE/FW/V94Q==
  3. オプション: デフォルト設定では、aide --init コマンドは、/etc/aide.conf ファイルで定義するディレクトリーとファイルのセットのみを確認します。ディレクトリーまたはファイルを AIDE データベースに追加し、監視パラメーターを変更するには、/etc/aide.conf を変更します。
  4. データベースの使用を開始するには、初期データベースのファイル名から末尾の .new を削除します。

    # mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
  5. オプション: AIDE データベースの場所を変更するには、/etc/aide.conf ファイルを編集し、DBDIR 値を変更します。追加のセキュリティーのデータベース、設定、/usr/sbin/aide バイナリーファイルを、読み取り専用メディアなどの安全な場所に保存します。

9.12.2. AIDE を使用した整合性チェックの実行

crond サービスを使用すると、AIDE で定期的なファイル整合性チェックをスケジュールできます。

前提条件

  • AIDE が適切にインストールされ、データベースが初期化されている。AIDE のインストール を参照してください。

手順

  1. 手動でチェックを開始するには、以下を行います。

    # aide --check
    Start timestamp: 2024-07-08 10:43:46 -0400 (AIDE 0.16)
    AIDE found differences between database and filesystem!!
    
    Summary:
      Total number of entries:	55856
      Added entries:		0
      Removed entries:		0
      Changed entries:		1
    
    ---------------------------------------------------
    Changed entries:
    ---------------------------------------------------
    
    f   ...      ..S : /root/.viminfo
    
    ---------------------------------------------------
    Detailed information about changes:
    ---------------------------------------------------
    
    File: /root/.viminfo
      SELinux  : system_u:object_r:admin_home_t:s | unconfined_u:object_r:admin_home
                 0                                | _t:s0
    …
  2. 少なくとも、AIDE を毎週実行するようにシステムを設定します。最適な設定としては、AIDE を毎日実行します。たとえば、cron コマンドを使用して毎日午前 04:05 に AIDE を実行するようにスケジュールするには、/etc/crontab ファイルに次の行を追加します。

     05 4 * * * root /usr/sbin/aide --check

関連情報

  • システム上の cron(8) man ページ

9.12.3. AIDE データベースの更新

パッケージの更新や設定ファイルの調整など、システムの変更が確認できたら、基本となる AIDE データベースも更新します。

前提条件

  • AIDE が適切にインストールされ、データベースが初期化されている。AIDE のインストール を参照してください。

手順

  1. 基本となる AIDE データベースを更新します。

    # aide --update

    aide --update コマンドは、/var/lib/aide/aide.db.new.gz データベースファイルを作成します。

  2. 整合性チェックで更新したデータベースを使用するには、ファイル名から末尾の .new を削除します。

9.12.4. ファイル整合性ツール:AIDE および IMA

Red Hat Enterprise Linux は、システム上のファイルとディレクトリーの整合性をチェックおよび保持するためのさまざまなツールを提供します。次の表は、シナリオに適したツールを決定するのに役立ちます。

表9.1 AIDE と IMA の比較
比較項目Advanced Intrusion Detection Environment (AIDE)Integrity Measurement Architecture (IMA)

確認対象

AIDE は、システム上のファイルとディレクトリーのデータベースを作成するユーティリティーです。このデータベースは、ファイルの整合性をチェックし、侵入を検出するのに役立ちます。

IMA は、以前に保存された拡張属性と比較してファイル測定値 (ハッシュ値) をチェックすることにより、ファイルが変更されているかどうかを検出します。

確認方法

AIDE はルールを使用して、ファイルとディレクトリーの整合性状態を比較します。

IMA は、ファイルハッシュ値を使用して侵入を検出します。

理由

検出- AIDE は、ルールを検証することにより、ファイルが変更されているかどうかを検出します。

検出と防止- IMA は、ファイルの拡張属性を置き換えることにより、攻撃を検出および防止します。

使用方法

AIDE は、ファイルまたはディレクトリーが変更されたときに脅威を検出します。

誰かがファイル全体の変更を試みた時に、IMA は脅威を検出します。

範囲

AIDE は、ローカルシステム上のファイルとディレクトリーの整合性をチェックします。

IMA は、ローカルシステムとリモートシステムのセキュリティーを確保します。

9.13. LUKS を使用したブロックデバイスの暗号化

ディスク暗号化を使用すると、ブロックデバイス上のデータを暗号化して保護できます。デバイスの復号化されたコンテンツにアクセスするには、認証としてパスフレーズまたは鍵を入力します。これは、デバイスがシステムから物理的に取り外された場合でも、デバイスのコンテンツを保護するのに役立つため、モバイルコンピューターやリムーバブルメディアにとって重要です。LUKS 形式は、Red Hat Enterprise Linux におけるブロックデバイスの暗号化のデフォルト実装です。

9.13.1. LUKS ディスクの暗号化

Linux Unified Key Setup-on-disk-format (LUKS) は、暗号化されたデバイスの管理を簡素化するツールセットを提供します。LUKS を使用すると、ブロックデバイスを暗号化し、複数のユーザーキーでマスターキーを復号化できるようになります。パーティションの一括暗号化には、このマスターキーを使用します。

Red Hat Enterprise Linux は、LUKS を使用してブロックデバイスの暗号化を実行します。デフォルトではインストール時に、ブロックデバイスを暗号化するオプションが指定されていません。ディスクを暗号化するオプションを選択すると、コンピューターを起動するたびにパスフレーズの入力が求められます。このパスフレーズは、パーティションを復号化するバルク暗号鍵のロックを解除します。デフォルトのパーティションテーブルを変更する場合は、暗号化するパーティションを選択できます。この設定は、パーティションテーブル設定で行われます。

Ciphers

LUKS に使用されるデフォルトの暗号は aes-xts-plain64 です。LUKS のデフォルトの鍵サイズは 512 ビットです。Anaconda XTS モードを使用した LUKS のデフォルトの鍵サイズは 512 ビットです。使用可能な暗号は次のとおりです。

  • 高度暗号化標準 (Advanced Encryption Standard, AES)
  • Twofish
  • Serpent

LUKS によって実行される操作

  • LUKS は、ブロックデバイス全体を暗号化するため、脱着可能なストレージメディアやノート PC のディスクドライブといった、モバイルデバイスのコンテンツを保護するのに適しています。
  • 暗号化されたブロックデバイスの基本的な内容は任意であり、スワップデバイスの暗号化に役立ちます。また、とりわけデータストレージ用にフォーマットしたブロックデバイスを使用する特定のデータベースに関しても有用です。
  • LUKS は、既存のデバイスマッパーのカーネルサブシステムを使用します。
  • LUKS はパスフレーズのセキュリティーを強化し、辞書攻撃から保護します。
  • LUKS デバイスには複数のキースロットが含まれているため、バックアップキーやパスフレーズを追加できます。
重要

LUKS は次のシナリオには推奨されません。

  • LUKS などのディスク暗号化ソリューションは、システムの停止時にしかデータを保護しません。システムの電源がオンになり、LUKS がディスクを復号化すると、そのディスクのファイルは、そのファイルにアクセスできるすべてのユーザーが使用できます。
  • 同じデバイスに対する個別のアクセスキーを複数のユーザーが持つ必要があるシナリオ。LUKS1 形式はキースロットを 8 個提供し、LUKS2 形式はキースロットを最大 32 個提供します。
  • ファイルレベルの暗号化を必要とするアプリケーション。

9.13.2. RHEL の LUKS バージョン

Red Hat Enterprise Linux では、LUKS 暗号化のデフォルト形式は LUKS2 です。古い LUKS1 形式は引き続き完全にサポートされており、以前の Red Hat Enterprise Linux リリースと互換性のある形式で提供されます。LUKS2 再暗号化は、LUKS1 再暗号化と比較して、より堅牢で安全に使用できる形式と考えられています。

LUKS2 形式を使用すると、バイナリー構造を変更することなく、さまざまな部分を後に更新できます。LUKS2 は、内部的にメタデータに JSON テキスト形式を使用し、メタデータの冗長性を提供し、メタデータの破損を検出し、メタデータのコピーから自動的に修復します。

重要

LUKS2 と LUKS1 はディスクの暗号化に異なるコマンドを使用するため、LUKS1 のみをサポートするシステムでは LUKS2 を使用しないでください。LUKS バージョンに誤ったコマンドを使用すると、データが失われる可能性があります。

表9.2 LUKS バージョンに応じた暗号化コマンド
LUKS バージョン暗号化コマンド

LUKS2

cryptsetup reencrypt

LUKS1

cryptsetup-reencrypt

オンラインの再暗号化

LUKS2 形式は、デバイスが使用中の間に、暗号化したデバイスの再暗号化に対応します。たとえば、以下のタスクを実行するにあたり、デバイスでファイルシステムをアンマウントする必要はありません。

  • ボリュームキーの変更
  • 暗号化アルゴリズムの変更

    暗号化されていないデバイスを暗号化する場合は、ファイルシステムのマウントを解除する必要があります。暗号化の短い初期化後にファイルシステムを再マウントできます。

    LUKS1 形式は、オンライン再暗号化に対応していません。

変換

特定の状況では、LUKS1 を LUKS2 に変換できます。具体的には、以下のシナリオでは変換ができません。

  • LUKS1 デバイスが、Policy-Based Decryption (PBD) Clevis ソリューションにより使用されているとマークされている。cryptsetup ツールは、luksmeta メタデータが検出されると、そのデバイスを変換することを拒否します。
  • デバイスがアクティブになっている。デバイスが非アクティブ状態でなければ、変換することはできません。

9.13.3. LUKS2 再暗号化中のデータ保護のオプション

LUKS2 では、再暗号化プロセスで、パフォーマンスやデータ保護の優先度を設定する複数のオプションを選択できます。LUKS2 は、次のモードの resilience オプションを備えています。cryptsetup reencrypt --resilience resilience-mode /dev/sdx コマンドを使用すると、これらのモードのいずれかを選択できます。

checksum

デフォルトのモード。データ保護とパフォーマンスのバランスを取ります。

このモードでは、再暗号化領域内のセクターのチェックサムが個別に保存されます。チェックサムは、LUKS2 によって再暗号化されたセクターについて、復旧プロセスで検出できます。このモードでは、ブロックデバイスセクターの書き込みがアトミックである必要があります。

journal
最も安全なモードですが、最も遅いモードでもあります。このモードでは、再暗号化領域をバイナリー領域にジャーナル化するため、LUKS2 はデータを 2 回書き込みます。
none
none モードではパフォーマンスが優先され、データ保護は提供されません。SIGTERM シグナルやユーザーによる Ctrl+C キーの押下など、安全なプロセス終了からのみデータを保護します。予期しないシステム障害やアプリケーション障害が発生すると、データが破損する可能性があります。

LUKS2 の再暗号化プロセスが強制的に突然終了した場合、LUKS2 は以下のいずれかの方法で復旧を実行できます。

自動

次のいずれかのアクションを実行すると、次回の LUKS2 デバイスを開くアクション中に自動復旧アクションがトリガーされます。

  • cryptsetup open コマンドを実行する。
  • systemd-cryptsetup コマンドを使用してデバイスを接続する。
手動
LUKS2 デバイスで cryptsetup repair /dev/sdx コマンドを使用する。

関連情報

  • システム上の cryptsetup-reencrypt(8) および cryptsetup-repair(8) man ページ

9.13.4. LUKS2 を使用したブロックデバイスの既存データの暗号化

LUKS2 形式を使用して、まだ暗号化されていないデバイスの既存のデータを暗号化できます。新しい LUKS ヘッダーは、デバイスのヘッドに保存されます。

前提条件

  • ブロックデバイスにファイルシステムがある。
  • データのバックアップを作成している。

    警告

    ハードウェア、カーネル、または人的ミスにより、暗号化プロセス時にデータが失われる場合があります。データの暗号化を開始する前に、信頼性の高いバックアップを作成してください。

手順

  1. 暗号化するデバイスにあるファイルシステムのマウントをすべて解除します。次に例を示します。

    # umount /dev/mapper/vg00-lv00
  2. LUKS ヘッダーを保存するための空き容量を確認します。シナリオに合わせて、次のいずれかのオプションを使用します。

    • 論理ボリュームを暗号化する場合は、以下のように、ファイルシステムのサイズを変更せずに、論理ボリュームを拡張できます。以下に例を示します。

      # lvextend -L+32M /dev/mapper/vg00-lv00
    • parted などのパーティション管理ツールを使用してパーティションを拡張します。
    • このデバイスのファイルシステムを縮小します。ext2、ext3、または ext4 のファイルシステムには resize2fs ユーティリティーを使用できます。XFS ファイルシステムは縮小できないことに注意してください。
  3. 暗号化を初期化します。

    # cryptsetup reencrypt --encrypt --init-only --reduce-device-size 32M /dev/mapper/vg00-lv00 lv00_encrypted
    
    /dev/mapper/lv00_encrypted is now active and ready for online encryption.
  4. デバイスをマウントします。

    # mount /dev/mapper/lv00_encrypted /mnt/lv00_encrypted
  5. 永続的なマッピングのエントリーを /etc/crypttab ファイルに追加します。

    1. luksUUID を見つけます。

      # cryptsetup luksUUID /dev/mapper/vg00-lv00
      
      a52e2cc9-a5be-47b8-a95d-6bdf4f2d9325
    2. 任意のテキストエディターで /etc/crypttab を開き、このファイルにデバイスを追加します。

      $ vi /etc/crypttab
      
      lv00_encrypted UUID=a52e2cc9-a5be-47b8-a95d-6bdf4f2d9325 none

      a52e2cc9-a5be-47b8-a95d-6bdf4f2d9325 は、デバイスの luksUUID に置き換えます。

    3. dracut で initramfs を更新します。

      $ dracut -f --regenerate-all
  6. /etc/fstab ファイルに永続的なマウントのエントリーを追加します。

    1. アクティブな LUKS ブロックデバイスのファイルシステムの UUID を見つけます。

      $ blkid -p /dev/mapper/lv00_encrypted
      
      /dev/mapper/lv00-encrypted: UUID="37bc2492-d8fa-4969-9d9b-bb64d3685aa9" BLOCK_SIZE="4096" TYPE="xfs" USAGE="filesystem"
    2. 任意のテキストエディターで /etc/fstab を開き、このファイルにデバイスを追加します。次に例を示します。

      $ vi /etc/fstab
      
      UUID=37bc2492-d8fa-4969-9d9b-bb64d3685aa9 /home auto rw,user,auto 0

      37bc2492-d8fa-4969-9d9b-bb64d3685aa9 は、ファイルシステムの UUID に置き換えます。

  7. オンライン暗号化を再開します。

    # cryptsetup reencrypt --resume-only /dev/mapper/vg00-lv00
    
    Enter passphrase for /dev/mapper/vg00-lv00:
    Auto-detected active dm device 'lv00_encrypted' for data device /dev/mapper/vg00-lv00.
    Finished, time 00:31.130, 10272 MiB written, speed 330.0 MiB/s

検証

  1. 既存のデータが暗号化されているかどうかを確認します。

    # cryptsetup luksDump /dev/mapper/vg00-lv00
    
    LUKS header information
    Version: 2
    Epoch: 4
    Metadata area: 16384 [bytes]
    Keyslots area: 16744448 [bytes]
    UUID: a52e2cc9-a5be-47b8-a95d-6bdf4f2d9325
    Label: (no label)
    Subsystem: (no subsystem)
    Flags: (no flags)
    
    Data segments:
      0: crypt
    	offset: 33554432 [bytes]
    	length: (whole device)
    	cipher: aes-xts-plain64
    [...]
  2. 暗号化された空のブロックデバイスのステータスを表示します。

    # cryptsetup status lv00_encrypted
    
    /dev/mapper/lv00_encrypted is active and is in use.
      type:    LUKS2
      cipher:  aes-xts-plain64
      keysize: 512 bits
      key location: keyring
      device:  /dev/mapper/vg00-lv00

関連情報

  • システム上の cryptsetup(8)cryptsetup-reencrypt(8)lvextend(8)resize2fs(8)、および parted(8) man ページ

9.13.5. 独立したヘッダーがある LUKS2 を使用してブロックデバイスの既存データの暗号化

LUKS ヘッダーを保存するための空き領域を作成せずに、ブロックデバイスの既存のデータを暗号化できます。ヘッダーは、追加のセキュリティー層としても使用できる、独立した場所に保存されます。この手順では、LUKS2 暗号化形式を使用します。

前提条件

  • ブロックデバイスにファイルシステムがある。
  • データのバックアップを作成している。

    警告

    ハードウェア、カーネル、または人的ミスにより、暗号化プロセス時にデータが失われる場合があります。データの暗号化を開始する前に、信頼性の高いバックアップを作成してください。

手順

  1. 以下のように、そのデバイスのファイルシステムをすべてアンマウントします。

    # umount /dev/nvme0n1p1
  2. 暗号化を初期化します。

    # cryptsetup reencrypt --encrypt --init-only --header /home/header /dev/nvme0n1p1 nvme_encrypted
    
    WARNING!
    ========
    Header file does not exist, do you want to create it?
    
    Are you sure? (Type 'yes' in capital letters): YES
    Enter passphrase for /home/header:
    Verify passphrase:
    /dev/mapper/nvme_encrypted is now active and ready for online encryption.

    /home/header は、独立した LUKS ヘッダーを持つファイルへのパスに置き換えます。後で暗号化したデバイスのロックを解除するために、独立した LUKS ヘッダーにアクセスできる必要があります。

  3. デバイスをマウントします。

    # mount /dev/mapper/nvme_encrypted /mnt/nvme_encrypted
  4. オンライン暗号化を再開します。

    # cryptsetup reencrypt --resume-only --header /home/header /dev/nvme0n1p1
    
    Enter passphrase for /dev/nvme0n1p1:
    Auto-detected active dm device 'nvme_encrypted' for data device /dev/nvme0n1p1.
    Finished, time 00m51s,   10 GiB written, speed 198.2 MiB/s

検証

  1. 独立したヘッダーがある LUKS2 を使用するブロックデバイスの既存のデータが暗号化されているかどうかを確認します。

    # cryptsetup luksDump /home/header
    
    LUKS header information
    Version:       	2
    Epoch:         	88
    Metadata area: 	16384 [bytes]
    Keyslots area: 	16744448 [bytes]
    UUID:          	c4f5d274-f4c0-41e3-ac36-22a917ab0386
    Label:         	(no label)
    Subsystem:     	(no subsystem)
    Flags:       	(no flags)
    
    Data segments:
      0: crypt
    	offset: 0 [bytes]
    	length: (whole device)
    	cipher: aes-xts-plain64
    	sector: 512 [bytes]
    [...]
  2. 暗号化された空のブロックデバイスのステータスを表示します。

    # cryptsetup status nvme_encrypted
    
    /dev/mapper/nvme_encrypted is active and is in use.
      type:    LUKS2
      cipher:  aes-xts-plain64
      keysize: 512 bits
      key location: keyring
      device:  /dev/nvme0n1p1

関連情報

  • システム上の cryptsetup(8) および cryptsetup-reencrypt(8) man ページ

9.13.6. LUKS2 を使用した空のブロックデバイスの暗号化

LUKS2 形式を使用して、空のブロックデバイスを暗号化して、暗号化ストレージとして使用できます。

前提条件

  • 空のブロックデバイス。lsblk などのコマンドを使用して、そのデバイス上に実際のデータ (ファイルシステムなど) がないかどうかを確認できます。

手順

  1. 暗号化した LUKS パーティションとしてパーティションを設定します。

    # cryptsetup luksFormat /dev/nvme0n1p1
    
    WARNING!
    ========
    This will overwrite data on /dev/nvme0n1p1 irrevocably.
    Are you sure? (Type 'yes' in capital letters): YES
    Enter passphrase for /dev/nvme0n1p1:
    Verify passphrase:
  2. 暗号化した LUKS パーティションを開きます。

    # cryptsetup open /dev/nvme0n1p1 nvme0n1p1_encrypted
    
    Enter passphrase for /dev/nvme0n1p1:

    これにより、パーティションのロックが解除され、デバイスマッパーを使用してパーティションが新しいデバイスにマッピングされます。暗号化されたデータを上書きしないように、このコマンドは、デバイスが暗号化されたデバイスであり、/dev/mapper/device_mapped_name パスを使用して LUKS を通じてアドレス指定されることをカーネルに警告します。

  3. 暗号化されたデータをパーティションに書き込むためのファイルシステムを作成します。このパーティションには、デバイスマップ名を介してアクセスする必要があります。

    # mkfs -t ext4 /dev/mapper/nvme0n1p1_encrypted
  4. デバイスをマウントします。

    # mount /dev/mapper/nvme0n1p1_encrypted mount-point

検証

  1. 空のブロックデバイスが暗号化されているかどうかを確認します。

    # cryptsetup luksDump /dev/nvme0n1p1
    
    LUKS header information
    Version:       	2
    Epoch:         	3
    Metadata area: 	16384 [bytes]
    Keyslots area: 	16744448 [bytes]
    UUID:          	34ce4870-ffdf-467c-9a9e-345a53ed8a25
    Label:         	(no label)
    Subsystem:     	(no subsystem)
    Flags:       	(no flags)
    
    Data segments:
      0: crypt
    	offset: 16777216 [bytes]
    	length: (whole device)
    	cipher: aes-xts-plain64
    	sector: 512 [bytes]
    [...]
  2. 暗号化された空のブロックデバイスのステータスを表示します。

    # cryptsetup status nvme0n1p1_encrypted
    
    /dev/mapper/nvme0n1p1_encrypted is active and is in use.
      type:    LUKS2
      cipher:  aes-xts-plain64
      keysize: 512 bits
      key location: keyring
      device:  /dev/nvme0n1p1
      sector size:  512
      offset:  32768 sectors
      size:    20938752 sectors
      mode:    read/write

関連情報

  • システム上の cryptsetup(8)cryptsetup-open(8)cryptsetup-lusFormat(8) man ページ

9.13.7. Web コンソールで LUKS パスフレーズの設定

システムの既存の論理ボリュームに暗号化を追加する場合は、ボリュームをフォーマットすることでしか実行できません。

前提条件

  • RHEL 8 Web コンソールがインストールされている。

    手順は、Web コンソールのインストールおよび有効化 を参照してください。

  • cockpit-storaged パッケージがシステムにインストールされている。
  • 暗号化なしで、既存の論理ボリュームを利用できます。

手順

  1. RHEL 8 Web コンソールにログインします。

    詳細は、Web コンソールへのログイン を参照してください。

  2. Storage をクリックします。
  3. Storage テーブルで、暗号化するストレージデバイスの横にあるメニューボタン をクリックします。
  4. ドロップダウンメニューから Format を選択します。
  5. Encryption field で、暗号化仕様 LUKS1 または LUKS2 を選択します。
  6. 新しいパスフレーズを設定し、確認します。
  7. オプション: その他の暗号化オプションを変更します。
  8. フォーマット設定の最終処理
  9. Format をクリックします。

9.13.8. Web コンソールで LUKS パスフレーズの変更

Web コンソールで、暗号化されたディスクまたはパーティションで LUKS パスフレーズを変更します。

前提条件

手順

  1. RHEL 8 Web コンソールにログインします。

    詳細は、Web コンソールへのログイン を参照してください。

  2. Storage をクリックします。
  3. Storage テーブルで、暗号化されたデータを含むディスクを選択します。
  4. ディスクページで、Keys セクションまでスクロールし、編集ボタンをクリックします。

    cockpit LUKS edit

  5. パスフレーズの変更 ダイアログウィンドウで、以下を行います。

    1. 現在のパスフレーズを入力します。
    2. 新しいパスフレーズを入力します。
    3. 新しいパスフレーズを確認します。

      cockpit change pwd

  6. Saveをクリックします。

9.13.9. storage RHEL システムロールを使用して LUKS2 暗号化ボリュームを作成する

storage ロールを使用し、Ansible Playbook を実行して、LUKS で暗号化されたボリュームを作成および設定できます。

前提条件

手順

  1. 機密性の高い変数を暗号化されたファイルに保存します。

    1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>
    2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      luks_password: <password>
    3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。
  2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

    ---
    - name: Manage local storage
      hosts: managed-node-01.example.com
      vars_files:
        - vault.yml
      tasks:
        - name: Create and configure a volume encrypted with LUKS
          ansible.builtin.include_role:
            name: rhel-system-roles.storage
          vars:
            storage_volumes:
              - name: barefs
                type: disk
                disks:
                  - sdb
                fs_type: xfs
                fs_label: <label>
                mount_point: /mnt/data
                encryption: true
                encryption_password: "{{ luks_password }}"

    Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.storage/README.md ファイルを参照してください。

  3. Playbook の構文を検証します。

    $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  4. Playbook を実行します。

    $ ansible-playbook --ask-vault-pass ~/playbook.yml

検証

  1. LUKS 暗号化ボリュームの luksUUID 値を見つけます。

    # ansible managed-node-01.example.com -m command -a 'cryptsetup luksUUID /dev/sdb'
    
    4e4e7970-1822-470e-b55a-e91efe5d0f5c
  2. ボリュームの暗号化ステータスを表示します。

    # ansible managed-node-01.example.com -m command -a 'cryptsetup status luks-4e4e7970-1822-470e-b55a-e91efe5d0f5c'
    
    /dev/mapper/luks-4e4e7970-1822-470e-b55a-e91efe5d0f5c is active and is in use.
      type:    LUKS2
      cipher:  aes-xts-plain64
      keysize: 512 bits
      key location: keyring
      device:  /dev/sdb
    ...
  3. 作成された LUKS 暗号化ボリュームを確認します。

    # ansible managed-node-01.example.com -m command -a 'cryptsetup luksDump /dev/sdb'
    
    LUKS header information
    Version:        2
    Epoch:          3
    Metadata area:  16384 [bytes]
    Keyslots area:  16744448 [bytes]
    UUID:           4e4e7970-1822-470e-b55a-e91efe5d0f5c
    Label:          (no label)
    Subsystem:      (no subsystem)
    Flags:          (no flags)
    
    Data segments:
      0: crypt
            offset: 16777216 [bytes]
            length: (whole device)
            cipher: aes-xts-plain64
            sector: 512 [bytes]
    ...

関連情報

9.14. ポリシーベースの複号を使用した暗号化ボリュームの自動アンロックの設定

ポリシーベースの複号 (PBD) は、物理マシンおよび仮想マシンにおいて、ハードドライブで暗号化した root ボリュームおよびセカンダリーボリュームのロックを解除できるようにする一連の技術です。PBD は、ユーザーパスワード、TPM (Trusted Platform Module) デバイス、システムに接続する PKCS #11 デバイス (たとえばスマートカード) などのさまざまなロックの解除方法、もくしは特殊なネットワークサーバーを使用します。

PBD を使用すると、ポリシーにさまざまなロックの解除方法を組み合わせて、さまざまな方法で同じボリュームのロックを解除できるようにすることができます。RHEL における PBD の現在の実装は、Clevis フレームワークと、ピン と呼ばれるプラグインで構成されます。各ピンは、個別のアンロック機能を提供します。現在利用できるピンは以下のとおりです。

tang
ネットワークサーバーを使用してボリュームのロックを解除できるようにします。
tpm2
TPM2 ポリシーを使用してボリュームのロックを解除できるようにします。
sss
Shamir’s Secret Sharing (SSS) 暗号化スキームを使用して高可用性システムをデプロイできます。

9.14.1. NBDE (Network-Bound Disk Encryption)

Network Bound Disc Encryption (NBDE) は、ポリシーベースの復号 (PBD) のサブカテゴリーであり、暗号化されたボリュームを特別なネットワークサーバーにバインドできるようにします。NBDE の現在の実装には、Tang サーバー自体と、Tang サーバー用の Clevis ピンが含まれます。

RHEL では、NBDE は次のコンポーネントとテクノロジーによって実装されます。

図9.1 LUKS1 で暗号化したボリュームを使用する場合の NBDE スキーム(luksmeta パッケージは、LUKS2 ボリュームには使用されません)

Network-Bound Disk Encryption (NBDE)

Tang は、ネットワークのプレゼンスにデータをバインドするためのサーバーです。セキュリティーが保護された特定のネットワークにシステムをバインドする際に利用可能なデータを含めるようにします。Tang はステートレスで、TLS または認証は必要ありません。エスクローベースのソリューション (サーバーが暗号鍵をすべて保存し、使用されたことがあるすべての鍵に関する知識を有する) とは異なり、Tang はクライアントの鍵と相互作用することはないため、クライアントから識別情報を得ることがありません。

Clevis は、自動化された復号用のプラグイン可能なフレームワークです。NBDE では、Clevis は、LUKS ボリュームの自動アンロックを提供します。clevis パッケージは、クライアントで使用される機能を提供します。

Clevis ピン は、Clevis フレームワークへのプラグインです。このようなピンの 1 つは、NBDE サーバー (Tang) との相互作用を実装するプラグインです。

Clevis および Tang は、一般的なクライアントおよびサーバーのコンポーネントで、ネットワークがバインドされた暗号化を提供します。RHEL では、LUKS と組み合わせて使用され、ルートおよび非ルートストレージボリュームを暗号化および復号して、ネットワークにバインドされたディスク暗号化を実現します。

クライアントおよびサーバーのコンポーネントはともに José ライブラリーを使用して、暗号化および複号の操作を実行します。

NBDE のプロビジョニングを開始すると、Tang サーバーの Clevis ピンは、Tang サーバーの、アドバタイズされている非対称鍵のリストを取得します。もしくは、鍵が非対称であるため、Tang の公開鍵のリストを帯域外に配布して、クライアントが Tang サーバーにアクセスしなくても動作できるようにします。このモードは オフラインプロビジョニング と呼ばれます。

Tang 用の Clevis ピンは、公開鍵のいずれかを使用して、固有で、暗号論的に強力な暗号鍵を生成します。この鍵を使用してデータを暗号化すると、この鍵は破棄されます。Clevis クライアントは、使いやすい場所に、このプロビジョニング操作で生成した状態を保存する必要があります。データを暗号化するこのプロセスは プロビジョニング手順 と呼ばれています。

LUKS バージョン 2 (LUKS2) は、RHEL のデフォルトのディスク暗号化形式であるため、NBDE のプロビジョニング状態は、LUKS2 ヘッダーにトークンとして保存されます。luksmeta パッケージによる NBDE のプロビジョニング状態は、LUKS1 で暗号化したボリュームにのみ使用されます。

Tang 用の Clevis ピンは、規格を必要とせずに LUKS1 と LUKS2 の両方をサポートします。Clevis はプレーンテキストファイルを暗号化できますが、ブロックデバイスの暗号化には cryptsetup ツールを使用する必要があります。詳細については、 Encrypting block devices using LUKS を参照してください。

クライアントがそのデータにアクセスする準備ができると、プロビジョニング手順で生成したメタデータを読み込み、応答して暗号鍵を戻します。このプロセスは 復旧手順 と呼ばれます。

Clevis は、NBDE ではピンを使用して LUKS ボリュームをバインドしているため、自動的にロックが解除されます。バインドプロセスが正常に終了すると、提供されている Dracut アンロックを使用してディスクをアンロックできます。

注記

kdump カーネルクラッシュのダンプメカニズムが、システムメモリーのコンテンツを LUKS で暗号化したデバイスに保存するように設定されている場合には、2 番目のカーネル起動時にパスワードを入力するように求められます。

関連情報

9.14.2. enforcing モードの SELinux を使用して Tang サーバーをデプロイする

Tang サーバーを使用して、Clevis 対応クライアント上の LUKS 暗号化ボリュームのロックを自動的に解除できます。最小限のシナリオでは、tang パッケージをインストールし、systemctl enable tangd.socket --now コマンドを入力することにより、ポート 80 に Tang サーバーをデプロイします。次の手順の例では、SELinux 強制モードの限定サービスとしてカスタムポートで実行されている Tang サーバーのデプロイメントを示しています。

前提条件

  • policycoreutils-python-utils パッケージおよび依存関係がインストールされている。
  • firewalld サービスが実行している。

手順

  1. tang パッケージとその依存関係をインストールするには、root で以下のコマンドを実行します。

    # yum install tang
  2. 7500/tcp などの不要なポートを選択し、tangd サービスがそのポートにバインドできるようにします。

    # semanage port -a -t tangd_port_t -p tcp 7500

    ポートは 1 つのサービスのみで一度に使用できるため、すでに使用しているポートを使用しようとすると、ValueError:Port already defined エラーが発生します。

  3. ファイアウォールのポートを開きます。

    # firewall-cmd --add-port=7500/tcp
    # firewall-cmd --runtime-to-permanent
  4. tangd サービスを有効にします。

    # systemctl enable tangd.socket
  5. オーバーライドファイルを作成します。

    # systemctl edit tangd.socket
  6. 以下のエディター画面で、/etc/systemd/system/tangd.socket.d/ ディレクトリーにある空の override.conf ファイルを開き、次の行を追加して、Tang サーバーのデフォルトのポートを、80 から、以前取得した番号に変更します。

    [Socket]
    ListenStream=
    ListenStream=7500
    重要

    # Anything between here# Lines below this で始まる行の間に以前のコードスニペットを挿入します。挿入しない場合、システムは変更を破棄します。

  7. Ctrl+OEnter を押し、変更を保存します。Ctrl+X を押してエディターを終了します。
  8. 変更した設定を再読み込みします。

    # systemctl daemon-reload
  9. 設定が機能していることを確認します。

    # systemctl show tangd.socket -p Listen
    Listen=[::]:7500 (Stream)
  10. tangd サービスを開始します。

    # systemctl restart tangd.socket

    tangd が、systemd のソケットアクティベーションメカニズムを使用しているため、最初に接続するとすぐにサーバーが起動します。最初の起動時に、一組の暗号鍵が自動的に生成されます。鍵の手動生成などの暗号化操作を実行するには、jose ユーティリティーを使用します。

検証

  • NBDE クライアントで、次のコマンドを使用して、Tang サーバーが正しく動作していることを確認します。このコマンドにより、暗号化と復号化に渡すものと同じメッセージが返される必要があります。

    # echo test | clevis encrypt tang '{"url":"<tang.server.example.com:7500>"}' -y | clevis decrypt
    test

関連情報

  • システム上の tang(8)semanage(8)firewall-cmd(1)jose(1)systemd.unit(5) および systemd.socket(5) man ページ

9.14.3. Tang サーバーの鍵のローテーションおよびクライアントでのバインディングの更新

セキュリティー上の理由から、Tang サーバーの鍵をローテーションし、クライアント上の既存のバインディングを定期的に更新してください。鍵をローテートするのに適した間隔は、アプリケーション、鍵のサイズ、および組織のポリシーにより異なります。

したがって、nbde_server RHEL システムロールを使用して、Tang 鍵をローテーションできます。詳細は 複数の Tang サーバー設定での nbde_server システムロールの使用 を参照してください。

前提条件

  • Tang サーバーが実行している。
  • clevis パッケージおよび clevis-luks パッケージがクライアントにインストールされている。
  • RHEL 8.2 に、clevis luks listclevis luks report、および clevis luks regen が追加されていることに注意してください。

手順

  1. /var/db/tang 鍵データベースディレクトリーのすべての鍵の名前の前に . を指定して、アドバタイズメントに対して非表示にします。以下の例のファイル名は、Tang サーバーの鍵データベースディレクトリーにある一意のファイル名とは異なります。

    # cd /var/db/tang
    # ls -l
    -rw-r--r--. 1 root root 349 Feb  7 14:55 UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
    -rw-r--r--. 1 root root 354 Feb  7 14:55 y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk
    # mv UV6dqXSwe1bRKG3KbJmdiR020hY.jwk .UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
    # mv y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk .y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk
  2. 名前が変更され、Tang サーバーのアドバタ