第17章 インストール設定

17.1. ノードのカスタマイズ

OpenShift Container Platform ノードへの直接の変更は推奨されませんが、必要とされる低レベルのセキュリティー、冗長性、ネットワーク、またはパフォーマンス機能を実装することが必要になる場合があります。OpenShift Container Platform ノードへの直接の変更は、以下によって実行できます。

  • openshift-install の実行時にクラスターを起動するためにマニフェストファイルに組み込まれるマシン設定を作成します。
  • Machine Config Operator を使用して実行中の OpenShift Container Platform ノードに渡されるマシン設定を作成します。
  • ベアメタルノードのインストール時に coreos-installer に渡される Ignition 設定を作成します。

以下のセクションでは、この方法でノード上で設定する必要が生じる可能性のある機能について説明します。

17.1.1. day-1 カーネル引数の追加

多くの場合、カーネル引数を day-2 アクティビティーとして変更することが推奨されますが、初期クラスターのインストール時にすべてのマスターまたはワーカーノードにカーネル引数を追加することができます。以下は、クラスターのインストール時にカーネル引数を追加して、システムの初回起動前に有効にする必要が生じる可能性のある理由です。

  • SELinux などの機能を無効にし、初回起動時にシステムに影響を与えないようにする必要がある場合。
  • システムの起動前に、低レベルのネットワーク設定を実行する必要がある場合。

カーネル引数をマスターまたはワーカーノードに追加するには、MachineConfig オブジェクトを作成し、そのオブジェクトをクラスターのセットアップ時に Ignition が使用するマニフェストファイルのセットに挿入することができます。

起動時に RHEL 8 カーネルに渡すことのできる引数の一覧については、Kernel.org カーネルパラメーターを参照してください。カーネル引数が OpenShift Container Platform の初回インストールを完了するために必要な場合は、この手順でカーネル引数のみを追加することが推奨されます。

手順

  1. インストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。

    $ ./openshift-install create manifests --dir=<installation_directory>
  2. カーネル引数をワーカーまたはコントロールプレーンノード (別名マスターノード) に追加するかどうかを決定します。
  3. openshift ディレクトリーでファイル(例: 99-openshift-machineconfig-master-kargs.yaml)を作成し、カーネル設定を追加するために MachineConfig オブジェクトを定義します。この例では、loglevel=7 カーネル引数をコントロールプレーンノードに追加します。

    $ cat << EOF > 99-openshift-machineconfig-master-kargs.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 99-openshift-machineconfig-master-kargs
    spec:
      kernelArguments:
        - loglevel=7
    EOF

    カーネル引数をワーカーノードに追加する場合は、masterworker に切り替えます。マスターおよびワーカーノードの両方に追加するために別々の YAML ファイルを作成します。

クラスターの作成を継続できます。

17.1.2. カーネルモジュールのノードへの追加

大半の一般的なハードウェアの場合、Linux カーネルには、コンピューターの起動時にそのハードウェアを使用するために必要となるデバイスドライバーモジュールが含まれます。ただし、一部のハードウェアの場合、Linux でモジュールを利用できません。したがって、各ホストコンピューターにこれらのモジュールを提供する方法を確保する必要があります。この手順では、OpenShift Container Platform クラスターのノードについてこれを実行する方法を説明します。

この手順に従ってカーネルモジュールを最初にデプロイする際、モジュールは現行のカーネルに対して利用可能になります。新規カーネルがインストールされると、kmods-via-containers ソフトウェアはモジュールを再ビルドし、デプロイしてそのモジュールの新規カーネルと互換性のあるバージョンが利用可能になるようにします。

この機能によって各ノードでモジュールが最新の状態に保てるようにするために、以下が実行されます。

  • 新規カーネルがインストールされているかどうかを検出するために、システムの起動時に起動する各ノードに systemd サービスを追加します。
  • 新規カーネルが検出されると、サービスはモジュールを再ビルドし、これをカーネルにインストールします。

この手順に必要なソフトウェアの詳細については、kmods-via-containers github サイトを参照してください。

以下の重要な点に留意してください。

  • この手順はテクノロジープレビューです。
  • ソフトウェアのツールおよびサンプルは公式の RPM 形式で利用できず、現時点ではこの手順に記載されている非公式の github.com サイトからしか取得できません。
  • この手順で追加する必要がある可能性のあるサードパーティーのカーネルモジュールについては Red Hat はサポートしません。
  • この手順では、カーネルモジュールのビルドに必要なソフトウェアは RHEL 8 コンテナーにデプロイされます。モジュールは、ノードが新規カーネルを取得する際に各ノードで自動的に再ビルドされることに注意してください。このため、各ノードには、モジュールの再ビルドに必要なカーネルと関連パッケージを含む yum リポジトリーへのアクセスが必要です。このコンテンツは、有効な RHEL サブスクリプションを使用して効果的に利用できます。

17.1.2.1. カーネルモジュールコンテナーのビルドおよびテスト

カーネルモジュールを OpenShift Container Platform クラスターにデプロイする前に、プロセスを別の RHEL システムでテストできます。カーネルモジュールのソースコード、KVC フレームワーク、および kmod-via-containers ソフトウェアを収集します。次にモジュールをビルドし、テストします。RHEL 8 システムでこれを行うには、以下を実行します。

手順

  1. RHEL 8 システムを登録します。

    # subscription-manager register
  2. RHEL 8 システムにサブスクリプションを割り当てます。

    # subscription-manager attach --auto
  3. ソフトウェアとコンテナーのビルドに必要なソフトウェアをインストールします。

    # yum install podman make git -y
  4. kmod-via-containers リポジトリーのクローンを作成します。

    1. リポジトリーのフォルダーを作成します。

      $ mkdir kmods; cd kmods
    2. リポジトリーのクローンを作成します。

      $ git clone https://github.com/kmods-via-containers/kmods-via-containers
  5. RHEL 8 ビルドホストに KVC フレームワークインスタンスをインストールし、モジュールをテストします。これにより、kmods-via-container systemd サービスが追加され、読み込まれます。

    1. kmod-via-containers ディレクトリーに移動します。

      $ cd kmods-via-containers/
    2. KVC フレームワークインスタンスをインストールします。

      $ sudo make install
    3. systemd マネージャー設定を再読み込みします。

      $ sudo systemctl daemon-reload
  6. カーネルモジュールのソースコードを取得します。ソースコードは、制御下になく、他から提供されるサードパーティーモジュールをビルドするために使用される可能性があります。システムに対してクローン作成できる以下の kvc-simple-kmod サンプルのコンテンツと同様のコンテンツが必要になります。

    $ cd .. ; git clone https://github.com/kmods-via-containers/kvc-simple-kmod
  7. この例では、設定ファイル simple-kmod.conf を編集し、Dockerfile の名前を Dockerfile.rhel に変更します。

    1. kvc-simple-kmod ディレクトリーに移動します。

      $ cd kvc-simple-kmod
    2. Dockerfile の名前を変更します。

      $ cat simple-kmod.conf

      Dockerfile の例

      KMOD_CONTAINER_BUILD_CONTEXT="https://github.com/kmods-via-containers/kvc-simple-kmod.git"
      KMOD_CONTAINER_BUILD_FILE=Dockerfile.rhel
      KMOD_SOFTWARE_VERSION=dd1a7d4
      KMOD_NAMES="simple-kmod simple-procfs-kmod"

  8. この例ではカーネルモジュール simple-kmodkmods-via-containers@.service のインスタンスを作成します。

    $ sudo make install
  9. kmods-via-containers@.service インスタンスを有効にします。

    $ sudo kmods-via-containers build simple-kmod $(uname -r)
  10. systemd サービスを有効にし、起動します。

    $ sudo systemctl enable kmods-via-containers@simple-kmod.service --now
    1. サービスのステータスを確認します。

      $ sudo systemctl status kmods-via-containers@simple-kmod.service

      出力例

      ● kmods-via-containers@simple-kmod.service - Kmods Via Containers - simple-kmod
         Loaded: loaded (/etc/systemd/system/kmods-via-containers@.service;
                enabled; vendor preset: disabled)
         Active: active (exited) since Sun 2020-01-12 23:49:49 EST; 5s ago...

  11. カーネルモジュールがロードされていることを確認するには、lsmod コマンドを使用してモジュールを一覧表示します。

    $ lsmod | grep simple_

    出力例

    simple_procfs_kmod     16384  0
    simple_kmod            16384  0

  12. オプション。他の方法を使用して simple-kmod のサンプルが機能していることを確認します。

    • dmesg を使ってカーネルリングバッファーで「Hello world」メッセージを探します。

      $ dmesg | grep 'Hello world'

      出力例

      [ 6420.761332] Hello world from simple_kmod.

    • /procsimple-procfs-kmod の値を確認します。

      $ sudo cat /proc/simple-procfs-kmod

      出力例

      simple-procfs-kmod number = 0

    • spkut コマンドを実行して、モジュールの詳細情報を取得します。

      $ sudo spkut 44

      出力例

      KVC: wrapper simple-kmod for 4.18.0-147.3.1.el8_1.x86_64
      Running userspace wrapper using the kernel module container...
      + podman run -i --rm --privileged
         simple-kmod-dd1a7d4:4.18.0-147.3.1.el8_1.x86_64 spkut 44
      simple-procfs-kmod number = 0
      simple-procfs-kmod number = 44

その後は、システムの起動時に、このサービスは新規カーネルが実行中であるかどうかをチェックします。新規カーネルがある場合は、サービスは新規バージョンのカーネルモジュールをビルドし、これをロードします。モジュールがすでにビルドされている場合は、これをロードします。

17.1.2.2. カーネルモジュールの OpenShift Container Platform へのプロビジョニング

OpenShift Container Platform クラスターの初回起動時にカーネルモジュールを有効にする必要があるかどうかに応じて、以下のいずれかの方法でデプロイするようにカーネルモジュールを設定できます。

  • クラスターインストール時のカーネルモジュールのプロビジョニング (day-1): コンテンツを MachineConfig として作成し、これをマニフェストファイルのセットと共に組み込み、これを openshift-install に提供できます。
  • Machine Config Operator によるカーネルモジュールのプロビジョニング (day-2): カーネルモジュールを追加する際にクラスターが稼働するまで待機できる場合、Machine Config Operator (MCO) を使用してカーネルモジュールソフトウェアをデプロイできます。

いずれの場合も、各ノードは、新規カーネルの検出時にカーネルパッケージと関連ソフトウェアパッケージを取得できる必要があります。該当するコンテンツを取得できるように各ノードをセットアップする方法はいくつかあります。

  • 各ノードに RHEL エンタイトルメントを提供します。
  • /etc/pki/entitlement ディレクトリーから、既存 RHEL ホストの RHEL エンタイトルメントを取得し、それらを Ignition 設定の作成時に提供する他のファイルと同じ場所にコピーします。
  • Dockerfile 内で、カーネルおよびその他のパッケージを含む yum リポジトリーへのポインターを追加します。これには、新たにインストールされたカーネルと一致させる必要があるため、新規のカーネルパッケージが含まれている必要があります。
17.1.2.2.1. MachineConfig オブジェクトでのカーネルモジュールのプロビジョニング

MachineConfig オブジェクト でカーネルモジュールソフトウェアをパッケージ化することで、そのソフトウェアをインストール時に、または Machine Config Operator を使用してワーカーまたはマスターノードに配信できます。

まず、使用するベース Ignition 設定を作成します。インストール時に、Ignition 設定にはクラスターの core ユーザーの authorized_keys ファイルに追加する ssh パブリックキーが含まれます。後で MCO を使用して MachineConfig を追加する場合、ssh パブリックキーは不要になります。どちらのタイプでも、サンプルの simple-kmod サービスは kmods-via-containers@simple-kmod.service を必要とする systemd ユニットファイルを作成します。

注記

systemd ユニットはアップストリームのバグに対する回避策であり、kmods-via-containers@simple-kmod.service が起動時に開始するようにします。

  1. RHEL 8 システムを登録します。

    # subscription-manager register
  2. RHEL 8 システムにサブスクリプションを割り当てます。

    # subscription-manager attach --auto
  3. ソフトウェアのビルドに必要なソフトウェアをインストールします。

    # yum install podman make git -y
  4. systemd ユニットファイルを作成する Ignition 設定ファイルを作成します。

    1. Ignition 設定ファイルをホストするディレクトリーを作成します。

      $ mkdir kmods; cd kmods
    2. systemd ユニットファイルを作成する Ignition 設定ファイルを作成します。

      $ cat <<EOF > ./baseconfig.ign
      {
        "ignition": { "version": "3.2.0" },
        "passwd": {
          "users": [
            {
              "name": "core",
              "groups": ["sudo"],
              "sshAuthorizedKeys": [
                "ssh-rsa AAAA"
              ]
            }
          ]
        },
        "systemd": {
          "units": [{
            "name": "require-kvc-simple-kmod.service",
            "enabled": true,
            "contents": "[Unit]\nRequires=kmods-via-containers@simple-kmod.service\n[Service]\nType=oneshot\nExecStart=/usr/bin/true\n\n[Install]\nWantedBy=multi-user.target"
          }]
        }
      }
      EOF
      注記

      openshift-install の実行時に、パブリック SSH キーを使用する baseconfig.ign ファイルに追加する必要があります。MCO を使用して MachineConfig オブジェクトを作成する場合、パブリック SSH キーは必要ありません。

  5. 以下の設定を使用するベース MCO YAML スニペットを作成します。

    $ cat <<EOF > mc-base.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 10-kvc-simple-kmod
    spec:
      config:
    EOF
    注記

    mc-base.yaml は、worker ノードにカーネルモジュールをデプロイするように設定されます。マスターノードでデプロイするには、ロールを worker から masterに変更します。どちらの方法でも、デプロイメントの種類ごとに異なるファイル名を使用して手順全体を繰り返すことができます。

  6. kmods-via-containers ソフトウェアを取得します。

    1. kmods-via-containers リポジトリーのクローンを作成します。

      $ git clone https://github.com/kmods-via-containers/kmods-via-containers
    2. kvc-simple-kmod リポジトリーのクローンを作成します。

      $ git clone https://github.com/kmods-via-containers/kvc-simple-kmod
  7. モジュールソフトウェアを取得します。この例では、kvc-simple-kmod が使用されます。
  8. fakeroot ディレクトリーを作成し、先にクローン作成したリポジトリーを使用して Ignition で配信するファイルを使用してこれを設定します。

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

      $ FAKEROOT=$(mktemp -d)
    2. kmod-via-containers ディレクトリーに移動します。

      $ cd kmods-via-containers
    3. KVC フレームワークインスタンスをインストールします。

      $ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/
    4. kvc-simple-kmod ディレクトリーに移動します。

      $ cd ../kvc-simple-kmod
    5. インスタンスを作成します。

      $ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/
  9. filetranspiler というツールおよび依存するソフトウェアを取得します。

    $ cd .. ; sudo yum install -y python3
    git clone https://github.com/ashcrow/filetranspiler.git
  10. 最終的なマシン設定 YAML(mc.yaml)を生成し、これに配信するファイルと共にベース Ignition 設定、ベースマシン設定、および fakeroot ディレクトリーを含めます。

    $ ./filetranspiler/filetranspile -i ./baseconfig.ign \
         -f ${FAKEROOT} --format=yaml --dereference-symlinks \
         | sed 's/^/     /' | (cat mc-base.yaml -) > 99-simple-kmod.yaml
  11. クラスターがまだ起動していない場合は、マニフェストファイルを生成し、そのファイルを openshift ディレクトリーに追加します。クラスターがすでに実行中の場合は、ファイルを以下のように適用します。

    $ oc create -f 99-simple-kmod.yaml

    ノードは kmods-via-containers@simple-kmod.service サービスを起動し、カーネルモジュールがロードされます。

  12. カーネルモジュールがロードされていることを確認するには、ノードにログインすることができます (oc debug node/<openshift-node> を使用してから chroot /hostを使用します)。モジュールを一覧表示するには、lsmod コマンドを使用します。

    $ lsmod | grep simple_

    出力例

    simple_procfs_kmod     16384  0
    simple_kmod            16384  0

17.1.3. インストール時のディスクの暗号化

インストール時に、コントロールプレーンおよびコンピュートノードのブートディスクの暗号化を有効できます。OpenShift Container Platform は Trusted Platform Module (TPM) v2 および Tang 暗号化モードをサポートします。

  • TPM v2: これは優先されるモードです。TPM v2 は、サーバー内に含まれる安全な暗号プロセッサーにパスフレーズを保存します。このモードを使用すると、ディスクがサーバーから削除された場合にクラスターノードのブートディスクデータが復号化されないようにできます。
  • tang: Tang および Clevis は、ネットワークバインドディスク暗号化 (NBDE) を有効にするサーバーおよびクライアントコンポーネントです。クラスターノードのブートディスクデータを Tang サーバーにバインドできます。これにより、ノードが Tang サーバーにアクセスできるセキュアなネットワーク上にある場合を除き、データの復号化ができなくなります。Clevis は、クライアント側の復号化の実装に使用される自動復号化フレームワークです。
重要

Tang 暗号化モードを使用したディスクの暗号化は、ユーザーによってプロビジョニングされるインフラストラクチャーでのベアメタルおよび vSphere インストールでのみサポートされます。

TPM v2 または Tang 暗号化モードを有効にすると、RHCOS ブートディスクは LUKS2 形式を使用して暗号化されます。

この機能には以下の特徴があります。

  • インストーラーでプロビジョニングされるインフラストラクチャーおよびユーザーによってプロビジョニングされるインフラストラクチャーのデプロイメントで利用可能である。
  • Red Hat Enterprise Linux CoreOS (RHCOS) システムのみでサポートされる。
  • マニフェストのインストールフェーズでディスク暗号化が設定される。これにより、初回起動時からディスクに書き込まれたすべてのデータが暗号化されます。
  • パスフレーズを提供するのにユーザーの介入を必要としない。
  • AES-256-CBC 暗号化を使用する。

クラスター内のノードのディスク暗号化を有効にするには、以下の 2 つの手順の内のいずれかに従います。

17.1.3.1. TPM v2 ディスク暗号化の有効化

以下の手順を使用して、OpenShift Container Platform のインストール時に TPM v2 モードディスクの暗号化を有効にします。

注記

以前のバージョンの RHCOS では、ディスク暗号化は Ignition 設定で /etc/clevis.json を指定して設定されました。このファイルは、OpenShift Container Platform 4.7 以降で作成されたクラスターではサポートされません。LUKS デバイスは Ignition luks セクションで直接設定する必要があります。

前提条件

  • インストールノードで OpenShift Container Platform インストールプログラムをダウンロードしている。

手順

  1. TPM v2 暗号化を各ノードの BIOS で有効にする必要があるかどうかを確認します。これは、ほとんどの Dell システムで必要になります。コンピューターのマニュアルを確認してください。
  2. インストールノードで、インストールプログラムが含まれるディレクトリーに切り替え、クラスターの Kubernetes マニフェストを生成します。

    $ ./openshift-install create manifests --dir=<installation_directory> 1
    1
    <installation_directory> は、インストールファイルを保存するディレクトリーへのパスに置き換えます。
  3. マシン設定ファイルを作成し、TPM v2 暗号化モードを使用してコントロールプレーンまたはコンピュートノードのブートディスクを暗号化します。

    重要

    影響を受けるノードでブートディスクのミラーリングも設定する場合も、この手順を省略します。ブートディスクのミラーリングを設定する際にディスクの暗号化を設定します。

    • コントロールプレーンノードで暗号化を設定するには、以下のマシン設定サンプルを <installation_directory>/openshift ディレクトリーのファイルに保存します。たとえば、ファイルに 99-openshift-master-tpmv2-encryption.yaml などの名前を付けます。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        name: master-tpm
        labels:
          machineconfiguration.openshift.io/role: master
      spec:
        config:
          ignition:
            version: 3.2.0
          storage:
            luks:
              - name: root
                device: /dev/disk/by-partlabel/root
                clevis:
                  tpm2: true 1
                options: [--cipher, aes-cbc-essiv:sha256]
                wipeVolume: true
            filesystems:
              - device: /dev/mapper/root
                format: xfs
                wipeFilesystem: true
                label: root
      1
      Trusted Platform Module (TPM) セキュア暗号化プロセッサーを使用して root ファイルシステムを暗号化する場合は、この属性を true に設定します。
    • コンピュートノードで暗号化を設定するには、以下のマシン設定サンプルを <installation_directory>/openshift ディレクトリーのファイルに保存します。たとえば、ファイルに 99-openshift-worker-tpmv2-encryption.yaml などの名前を付けます。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        name: worker-tpm
        labels:
          machineconfiguration.openshift.io/role: worker
      spec:
        config:
          ignition:
            version: 3.2.0
          storage:
            luks:
              - name: root
                device: /dev/disk/by-partlabel/root
                clevis:
                  tpm2: true 1
                options: [--cipher, aes-cbc-essiv:sha256]
                wipeVolume: true
            filesystems:
              - device: /dev/mapper/root
                format: xfs
                wipeFilesystem: true
                label: root
      1
      Trusted Platform Module (TPM) セキュア暗号化プロセッサーを使用して root ファイルシステムを暗号化する場合は、この属性を true に設定します。
  4. YAML ファイルのバックアップコピーを作成します。元の YAML ファイルは Ignition 設定ファイルの作成時に使用されます。
  5. 残りの OpenShift Container Platform のデプロイメントを継続します。
重要

追加のデータパーティションを設定する場合、暗号化が明示的に要求されない限り、それらは暗号化されません。

17.1.3.2. Tang ディスク暗号化の有効化

以下の手順を使用して、OpenShift Container Platform のインストール時に Tang モードディスクの暗号化を有効にします。

注記

以前のバージョンの RHCOS では、ディスク暗号化は Ignition 設定で /etc/clevis.json を指定して設定されました。このファイルは、OpenShift Container Platform 4.7 以降で作成されたクラスターではサポートされません。LUKS デバイスは Ignition luks セクションで直接設定する必要があります。

前提条件

  • インストールノードで OpenShift Container Platform インストールプログラムをダウンロードしている。
  • Tang 交換キーのサムプリントの生成に使用できる Red Hat Enterprise Linux (RHEL) 8 マシンにアクセスできる。

手順

  1. Tang サーバーを設定するか、または既存のサーバーにアクセスします。手順については、「NBDE (Network-Bound Disk Encryption)」を参照してください。
  2. クラスターについて Red Hat Enterprise Linux CoreOS (RHCOS) インストールを実行する際にネットワークを設定するためにカーネル引数を追加します。たとえば、DHCP ネットワークを設定するには、ip=dhcp を特定するか、またはカーネルコマンドラインにパラメーターを追加する際に静的ネットワークを設定します。DHCP と静的ネットワークの両方の場合、rd.neednet=1 カーネル引数も指定する必要があります。

    重要

    このステップを省略すると、2 番目の起動に失敗します。

  1. RHEL 8 マシンに clevis パッケージがインストールされていない場合はインストールします。

    $ sudo yum install clevis
  1. RHEL 8 マシンで以下のコマンドを実行し、交換キーのサムプリントを生成します。http://tang.example.com:7500 を Tang サーバーの URL に置き換えます。

    $ clevis-encrypt-tang '{"url":"http://tang.example.com:7500"}' < /dev/null > /dev/null 1
    1
    この例では、tangd.socket は Tang サーバーのポート 7500 でリッスンしています。
    注記

    このステップでは、clevis-encrypt-tang コマンドを使用して、交換キーのサムプリントを生成します。この時点で暗号化用のデータがコマンドに渡されないため、/dev/null はプレーンテキストではなく、インプットとして提供されます。この手順には必要ないため、暗号化された出力は /dev/null に送信されます。

    出力例

    The advertisement contains the following signing keys:
    
    PLjNyRdGw03zlRoGjQYMahSZGu9 1

    1
    エクスチェンジキーのサムプリント。

    Do you want to trust these keys? [ynYN] のプロンプトが表示されたら、Y と入力します 。

    注記

    RHEL 8 には、Clevis バージョン 15 が同梱されており、SHA-1 ハッシュアルゴリズムを使用してサムプリントを生成します。その他のディストリビューションには、Clevis バージョン 17 以降があり、サムプリントに SHA-256 ハッシュアルゴリズムを使用します。サムプリントを作成するために SHA-1 を使用する Clevis バージョンを使用し、OpenShift Container Platform クラスターノードに Red Hat Enterprise Linux CoreOS (RHCOS) のインストール時に Clevis バインディングの問題を防ぐ必要があります。

  2. Kubernetes マニフェストを生成していない場合は、インストールノードでインストールプログラムが含まれるディレクトリーに移動してマニフェストを作成します。

    $ ./openshift-install create manifests --dir=<installation_directory> 1
    1
    <installation_directory> は、インストールファイルを保存するディレクトリーへのパスに置き換えます。
  3. マシン設定ファイルを作成して Tang 暗号化モードを使用し、コントロールプレーンまたはコンピュートノードのブートディスクを暗号化します。

    重要

    影響を受けるノードでブートディスクのミラーリングを設定する場合も、後で使用するためにエクスチェンジキーのサムプリントを記録し、この手順を省略します。ブートディスクのミラーリングを設定する際にディスクの暗号化を設定します。

    • コントロールプレーンノードで暗号化を設定するには、以下のマシン設定サンプルを <installation_directory>/openshift ディレクトリーのファイルに保存します。たとえば、ファイルに 99-openshift-master-tang-encryption.yaml などの名前を付けます。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        name: master-tang
        labels:
          machineconfiguration.openshift.io/role: master
      spec:
        config:
          ignition:
            version: 3.2.0
          storage:
            luks:
              - name: root
                device: /dev/disk/by-partlabel/root
                clevis:
                  tang:
                    - url: http://tang.example.com:7500 1
                      thumbprint: PLjNyRdGw03zlRoGjQYMahSZGu9 2
                options: [--cipher, aes-cbc-essiv:sha256]
                wipeVolume: true
            filesystems:
              - device: /dev/mapper/root
                format: xfs
                wipeFilesystem: true
                label: root
        kernelArguments:
          - rd.neednet=1 3
      1
      Tang サーバーの URL を指定します。この例では、tangd.socket は Tang サーバーのポート 7500 でリッスンしています。
      2
      前述のステップで生成された Exchange キーサムプリントを指定します。
      3
      rd.neednet=1 カーネル引数を追加して、initramfs でネットワークを起動します。この引数は必須です。
    • コンピュートノードで暗号化を設定するには、以下のマシン設定サンプルを <installation_directory>/openshift ディレクトリーのファイルに保存します。たとえば、ファイルに 99-openshift-worker-tang-encryption.yaml などの名前を付けます。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        name: worker-tang
        labels:
          machineconfiguration.openshift.io/role: worker
      spec:
        config:
          ignition:
            version: 3.2.0
          storage:
            luks:
              - name: root
                device: /dev/disk/by-partlabel/root
                clevis:
                  tang:
                    - url: http://tang.example.com:7500 1
                      thumbprint: PLjNyRdGw03zlRoGjQYMahSZGu9 2
                options: [--cipher, aes-cbc-essiv:sha256]
                wipeVolume: true
            filesystems:
              - device: /dev/mapper/root
                format: xfs
                wipeFilesystem: true
                label: root
        kernelArguments:
          - rd.neednet=1 3
      1
      Tang サーバーの URL を指定します。この例では、tangd.socket は Tang サーバーのポート 7500 でリッスンしています。
      2
      前述のステップで生成された Exchange キーサムプリントを指定します。
      3
      rd.neednet=1 カーネル引数を追加して、initramfs でネットワークを起動します。この引数は必須です。
  4. YAML ファイルのバックアップコピーを作成します。元の YAML ファイルは Ignition 設定ファイルの作成時に使用されます。
  5. 残りの OpenShift Container Platform インストールを継続します。
重要

追加のデータパーティションを設定する場合、暗号化が明示的に要求されない限り、それらは暗号化されません。

17.1.4. インストール時のディスクのミラーリング

コントロールプレーンおよびコンピュートノードでの OpenShift Container Platform のインストール時に、ブートディスクの 2 つ以上の冗長ストレージデバイスへのミラーリングを有効にできます。ノードは、1 つのデバイスが利用可能な状態である限り、ストレージデバイスに障害が発生した後も引き続き機能します。

ミラーリングは、障害の発生したディスクの置き換えをサポートしません。ミラーを元の低下していない状態に復元するには、ノードを再プロビジョニングします。

重要

ミラーリングは、Red Hat Enterprise Linux CoreOS (RHCOS) システムのユーザーによってプロビジョニングされるインフラストラクチャーのデプロイメントでのみ利用できます。ミラーリングのサポートは、BIOS または UEFI で起動した x86_64 ノード、および ppc64le ノードで利用できます。

手順

OpenShift Container Platform のデプロイメント時のブートディスクのミラーリングを有効にするには、以下を実行します。

  1. インストール用に Ignition 設定を作成するところまで、ベアメタルのインストール手順に従います。

    たとえば、以下のコマンドを入力しているはずです。

    $ openshift-install create ignition-configs --dir $HOME/clusterconfig
  2. Ignition 設定ファイルが作成されていることを確認します。

    $ ls $HOME/clusterconfig/

    出力例

    auth  bootstrap.ign  master.ign  metadata.json  worker.ign

  3. 設定しているノードのタイプに応じて、 master.ign または worker.ign 設定への参照のある RHCOS 設定 (RCC) を作成します。RCC は、ブートディスクのミラーリングに使用されるデバイスを指定する必要があります。ミラーリングされたルートファイルシステムで LUKS 暗号化が必要な場合は、この RCC でこれを設定する必要があります。

    以下の RCC の例では、$HOME/clusterconfig/worker-raid.rcc を作成する方法を示します。

    RCC の例

    variant: rhcos
    version: 0.1.0
    ignition:
      config:
        merge:
          - local: worker.ign 1
    boot_device:
      mirror:
        devices: 2
          - /dev/sda
          - /dev/sdb
      luks: 3
        tpm2: true 4
        tang: 5
          - url: http://tang.example.com:7500
            thumbprint: <tang_thumbprint>
    storage: 6
      luks:
        - name: root
          options: [--cipher, aes-cbc-essiv:sha256]

    1
    ノードタイプの Ignition 設定の名前を使用します。
    2
    RHCOS がインストールされるディスクを含む、ブートディスクミラーに含まれる必要があるすべてのディスクデバイスを一覧表示します。
    3
    ルートファイルシステムを暗号化する必要がある場合は、このセクションを追加してください。詳細は、「インストール時のディスクの暗号化」を参照してください。
    4
    Trusted Platform Module (TPM) を使用してルートファイルシステムを暗号化する場合は、このフィールドを追加してください。詳細は、「TPM v2 ディスク暗号化の有効化」を参照してください。
    5
    Tang サーバーを使用する必要がある場合は、このセクションを追加してください。サーバー URL およびサムプリントを取得するには、「Tang ディスク暗号化の有効化」の手順に従います。
    6
    ルートファイルシステムを暗号化する必要がある場合は、このセクションを追加してください。
  4. Fedora CoreOS Config Transpiler (FCCT) ツールを実行し、worker-raid.rcc などの RCC を、先の手順で作成した RCC で設定した Ignition 設定にマージします。

    $ podman run --pull=always --rm --volume $HOME/clusterconfig:/pwd --workdir /pwd \
        quay.io/coreos/fcct:release --files-dir . worker-raid.rcc --output worker-raid.ign

    このコマンドは、$HOME/clusterconfig/worker-raid.ign に統合された Ignition 設定を生成します。

  5. ノードをプロビジョニングするために組み合わされた Ignition 設定を使用し、残りの OpenShift Container Platform デプロイメントを引き続き実行します。

17.1.5. chrony タイムサービスの設定

chrony タイムサービス (chronyd) で使用されるタイムサーバーおよび関連する設定は、chrony.conf ファイルのコンテンツを変更し、それらのコンテンツをマシン設定としてノードに渡して設定できます。

手順

  1. chrony.conf ファイルのコンテンツを作成し、これを base64 でエンコードします。以下は例になります。

    $ cat << EOF | base64
        pool 0.rhel.pool.ntp.org iburst 1
        driftfile /var/lib/chrony/drift
        makestep 1.0 3
        rtcsync
        logdir /var/log/chrony
    EOF
    1
    DHCP サーバーが提供するものなど、有効な到達可能なタイムソースを指定します。または、NTP サーバーの 1.rhel.pool.ntp.org2.rhel.pool.ntp.org、または 3.rhel.pool.ntp.org のいずれかを指定できます。

    出力例

    ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGli
    L2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAv
    dmFyL2xvZy9jaHJvbnkK

  2. MachineConfig ファイルを作成します。base64 文字列を独自に作成した文字列に置き換えます。この例では、ファイルを master ノードに追加します。これを worker に切り替えたり、worker ロールの追加の MachineConfig を作成したりできます。クラスターが使用するそれぞれのタイプのマシンについて MachineConfig ファイルを作成します。

    $ cat << EOF > ./99-masters-chrony-configuration.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 99-masters-chrony-configuration
    spec:
      config:
        ignition:
          config: {}
          security:
            tls: {}
          timeouts: {}
          version: 3.2.0
        networkd: {}
        passwd: {}
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGliL2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAvdmFyL2xvZy9jaHJvbnkK
            mode: 420
            overwrite: true
            path: /etc/chrony.conf
      osImageURL: ""
    EOF
  3. 設定ファイルのバックアップコピーを作成します。
  4. 以下の 2 つの方法のいずれかで設定を適用します。

    • クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、そのファイルを <installation_directory>/openshift ディレクトリーに追加してから、クラスターの作成を継続します。
    • クラスターがすでに実行中の場合は、ファイルを適用します。

       $ oc apply -f ./99-masters-chrony-configuration.yaml

17.1.6. 追加リソース

FIPS サポートについての詳細は、「FIPS 暗号のサポート」を参照してください。