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

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

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

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

3.2.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 ファイルを作成します。

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

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

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

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

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

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

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

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

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

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

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

手順

  1. RHEL 8 システムを取得して、これを登録し、サブスクライブします。

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

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

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

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

    $ cd ..
    $ git clone https://github.com/kmods-via-containers/kvc-simple-kmod
  6. この例では、設定ファイル simple-kmod.conf を編集し、Dockerfile の名前を Dockerfile.rhel に変更し、ファイルが以下のように表示されるようにします。

    $ cd kvc-simple-kmod
    $ cat simple-kmod.conf
    
    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"
  7. この例ではカーネルモジュール simple-kmodkmods-via-containers@.service のインスタンスを作成し、これを有効にします。

    $ sudo make install
    $ sudo kmods-via-containers build simple-kmod $(uname -r)
  8. systemd サービスを有効にしてから起動し、ステータスを確認します。

    $ sudo systemctl enable kmods-via-containers@simple-kmod.service
    $ sudo systemctl start kmods-via-containers@simple-kmod.service
    $ 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...
  9. カーネルモジュールがロードされていることを確認するには、lsmod コマンドを使用してモジュールを一覧表示します。

    $ lsmod | grep simple_
    simple_procfs_kmod     16384  0
    simple_kmod            16384  0
  10. 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

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

3.2.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 リポジトリーへのポインターを追加します。これには、新たにインストールされたカーネルと一致させる必要があるため、新規のカーネルパッケージが含まれている必要があります。
3.2.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
    Username: yourname
    Password: ***************
    # subscription-manager attach --auto
  2. ソフトウェアのビルドに必要なソフトウェアをインストールします。

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

    $ mkdir kmods; cd kmods
    $ cat <<EOF > ./baseconfig.ign
    {
      "ignition": { "version": "2.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 キーは必要ありません。

  4. 以下のようなベース 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に変更します。どちらの方法でも、デプロイメントの種類ごとに異なるファイル名を使用して手順全体を繰り返すことができます。

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

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

    $ FAKEROOT=$(mktemp -d)
    $ cd kmods-via-containers
    $ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/
    $ cd ../kvc-simple-kmod
    $ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/
  4. filetranspiler というツールおよび依存するソフトウェアを取得します。

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

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

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

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

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

    $ lsmod | grep simple_
    simple_procfs_kmod     16384  0
    simple_kmod            16384  0

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

OpenShift Container Platform のインストール時に、すべてのマスターおよびノードノードでディスクの暗号化を有効にできます。この機能には以下の特徴があります。

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

サポートされている暗号化モードとして、以下の 2 つのモードを使用できます。

  • TPM v2: これは優先されるモードです。TPM v2 はパスフレーズを安全な暗号プロセッサーに保存します。TPM v2 ディスク暗号化を実装するには、以下で説明されているように Ignition 設定ファイルを作成します。
  • Tang: Tang を使用してクラスターを暗号化するには、Tang サーバーを使用する必要があります。Clevis はクライアント側に復号化を実装します。Tang 暗号化モードは、ベアメタルのインストールの場合にのみサポートされます。

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

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

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

手順

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

    $ ./openshift-install create manifests --dir=<installation_directory>
  3. openshift ディレクトリーで、マスターおよび/またはワーカーファイルを作成し、それらのノードのディスクを暗号化します。以下は、それらの 2 つのファイルの例になります。

    $ cat << EOF > ./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: 2.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;base64,e30K
            filesystem: root
            mode: 420
            path: /etc/clevis.json
    EOF
    $ cat << EOF > ./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: 2.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;base64,e30K
            filesystem: root
            mode: 420
            path: /etc/clevis.json
    EOF
  4. YAML ファイルのバックアップコピーを作成します。ファイルはクラスターの作成時に削除されるため、これを実行する必要があります。
  5. 残りの OpenShift Container Platform のデプロイメントを継続します。

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

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

手順

  1. 暗号化の設定を構成し、openshift-install を実行してクラスターをインストールし、oc を使用してクラスターを操作するために Red Hat Enterprise Linux サーバーにアクセスします。
  2. 既存の Tang サーバーを設定するか、またはこれにアクセスします。手順については、「NBDE (Network-Bound Disk Encryption)」を参照してください。タグの表示についての詳細は、Securing Automated Decryption New Cryptography and Techniques を参照してください。
  3. クラスターについて Red Hat Enterprise Linux CoreOS (RHCOS) インストールを実行する際にネットワークを設定するためにカーネル引数を追加します。たとえば、DHCP ネットワークを設定するには、ip=dhcp を特定するか、またはカーネルコマンドラインにパラメーターを追加する際に静的ネットワークを設定します。DHCP と静的ネットワークの両方の場合、rd.neednet=1 カーネル引数も指定する必要があります。
重要

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

  1. サムプリントを生成します。(まだインストールされていない場合は) clevis パッケージをインストールし、Tang サーバーからサムプリントを生成します。url の値を Tang サーバーの URL に置き換えます。

    $ sudo yum install clevis -y
    $ echo nifty random wordwords \
         | clevis-encrypt-tang \
           '{"url":"https://tang.example.org"}'
    
    The advertisement contains the following signing keys:
    
    PLjNyRdGw03zlRoGjQYMahSZGu9
    
    Do you wish to trust these keys? [ynYN] y
    eyJhbmc3SlRyMXpPenc3ajhEQ01tZVJiTi1oM...
  2. Base64 でエンコードされたファイルを作成します。値を Tang サーバーの URL (url) と生成したサムプリント (thp) で置き換えます。

    $ (cat <<EOM
    {
     "url": "https://tang.example.com",
     "thp": "PLjNyRdGw03zlRoGjQYMahSZGu9"
    }
    EOM
    ) | base64 -w0
    
    ewogInVybCI6ICJodHRwczovL3RhbmcuZXhhbXBsZS5jb20iLAogInRocCI6ICJaUk1leTFjR3cwN3psVExHYlhuUWFoUzBHdTAiCn0K
  3. TPM2 の例の「source」を、ワーカーおよび/またはマスターノードのサンプルのいずれか、またはそれら両方の Base64 でエンコードされたファイルに置き換えます。

    重要

    rd.neednet=1 カーネル引数を追加する必要があります。

    $ cat << EOF > ./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: 2.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;base64,e30K
              source: data:text/plain;base64,ewogInVybCI6ICJodHRwczovL3RhbmcuZXhhbXBsZS5jb20iLAogInRocCI6ICJaUk1leTFjR3cwN3psVExHYlhuUWFoUzBHdTAiCn0K
            filesystem: root
            mode: 420
            path: /etc/clevis.json
      kernelArguments:
        - rd.neednet=1 <.>
    EOF
    必須。
    $ cat << EOF > ./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: 2.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;base64,e30K
              source: data:text/plain;base64,ewogInVybCI6ICJodHRwczovL3RhbmcuZXhhbXBsZS5jb20iLAogInRocCI6ICJaUk1leTFjR3cwN3psVExHYlhuUWFoUzBHdTAiCn0K
            filesystem: root
            mode: 420
            path: /etc/clevis.json
      kernelArguments:
        - rd.neednet=1 <.>
    EOF
    必須。
  4. 残りの OpenShift Container Platform のデプロイメントを継続します。

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

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

手順

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

    $ cat << EOF | base64
        server clock.redhat.com iburst
        driftfile /var/lib/chrony/drift
        makestep 1.0 3
        rtcsync
        logdir /var/log/chrony
        EOF
    
    ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGli
    L2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAv
    dmFyL2xvZy9jaHJvbnkK
  2. MachineConfig ファイルを作成します。base64 文字列を独自に作成した文字列に置き換えます。この例では、ファイルを master ノードに追加します。これを worker に切り替えたり、 worker ロールの追加の MachineConfig を作成したりできます。

    $ cat << EOF > ./masters-chrony-configuration.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: masters-chrony-configuration
    spec:
      config:
        ignition:
          config: {}
          security:
            tls: {}
          timeouts: {}
          version: 2.2.0
        networkd: {}
        passwd: {}
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGliL2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAvdmFyL2xvZy9jaHJvbnkK
              verification: {}
            filesystem: root
            mode: 420
            path: /etc/chrony.conf
      osImageURL: ""
    EOF
  3. 設定ファイルのバックアップコピーを作成します。
  4. クラスターがまだ起動していない場合は、マニフェストファイルを生成し、そのファイルを openshift ディレクトリーに追加してから、クラスターの作成を継続します。
  5. クラスターがすでに実行中の場合は、ファイルを以下のように適用します。

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

3.2.5. 追加リソース

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