18.3.3.2. 全 NBDE ノードのキー変更
リモートクラスターにダウンタイムを発生させずに DaemonSet オブジェクトを使用することで、リモートクラスターのすべてのノードにキーを再生成できます。
キーの再生成中にノードの電源が失われた場合、ノードが起動できなくなり、Red Hat Advanced Cluster Management (RHACM) または GitOps パイプラインを介したノードの再デプロイが必要になる可能性があります。
前提条件
-
Network-Bound Disk Encryption(NBDE) ノードが割り当てられたすべてのクラスターへの
cluster-adminアクセス。 - Tang サーバーのキーが変更されていない場合でも、キーの再生成が行われるすべての NBDE ノードからすべての Tang サーバーにアクセスできる必要があります。
- すべての Tang サーバーの Tang サーバーの URL およびキーのサムプリントを取得します。
手順
以下のテンプレートに基づいて
DaemonSetオブジェクトを作成します。このテンプレートは 3 つの冗長 Tang サーバーを設定しますが、他の状況にも簡単に対応できます。NEW_TANG_PIN環境の Tang サーバーの URL およびサムプリントを、実際の環境に合わせて変更します。apiVersion: apps/v1 kind: DaemonSet metadata: name: tang-rekey namespace: openshift-machine-config-operator spec: selector: matchLabels: name: tang-rekey template: metadata: labels: name: tang-rekey spec: containers: - name: tang-rekey image: registry.access.redhat.com/ubi9/ubi-minimal:latest imagePullPolicy: IfNotPresent command: - "/sbin/chroot" - "/host" - "/bin/bash" - "-ec" args: - | rm -f /tmp/rekey-complete || true echo "Current tang pin:" clevis-luks-list -d $ROOT_DEV -s 1 echo "Applying new tang pin: $NEW_TANG_PIN" clevis-luks-edit -f -d $ROOT_DEV -s 1 -c "$NEW_TANG_PIN" echo "Pin applied successfully" touch /tmp/rekey-complete sleep infinity readinessProbe: exec: command: - cat - /host/tmp/rekey-complete initialDelaySeconds: 30 periodSeconds: 10 env: - name: ROOT_DEV value: /dev/disk/by-partlabel/root - name: NEW_TANG_PIN value: >- {"t":1,"pins":{"tang":[ {"url":"http://tangserver01:7500","thp":"WOjQYkyK7DxY_T5pMncMO5w0f6E"}, {"url":"http://tangserver02:7500","thp":"I5Ynh2JefoAO3tNH9TgI4obIaXI"}, {"url":"http://tangserver03:7500","thp":"38qWZVeDKzCPG9pHLqKzs6k1ons"} ]}} volumeMounts: - name: hostroot mountPath: /host securityContext: privileged: true volumes: - name: hostroot hostPath: path: / nodeSelector: kubernetes.io/os: linux priorityClassName: system-node-critical restartPolicy: Always serviceAccount: machine-config-daemon serviceAccountName: machine-config-daemonこの場合は、
tangserver01のキーを再生成していても、tangserver01の新規サムプリントだけでなく、その他すべての Tang サーバーの現在のサムプリントも指定する必要があります。キーの再生成操作にすべてのサムプリントの指定に失敗すると、中間者攻撃の可能性が高まります。キーの再生成が必要なすべてのクラスターにデーモンセットを配布するには、次のコマンドを実行します。
$ oc apply -f tang-rekey.yamlただし、スケーリングで実行するには、デーモンセットを ACM ポリシーでラップします。この ACM 設定には、デーモンセットをデプロイするポリシーが 1 つ、すべてのデーモンセット Pod が READY であることを確認する 2 番目のポリシー、およびクラスターの適切なセットに適用する配置ルールを含める必要があります。
デーモンセットのすべてのサーバーが正常に再割り当てされたことを確認したら、デーモンセットを削除します。デーモンセットを削除しない場合は、次回のキー再生成操作の前にこれを削除する必要があります。
検証
デーモンセットを配布したら、デーモンセットを監視し、キー作成が正常に完了したことを確認します。サンプルのデーモンセットのスクリプトは、キー変更に失敗するとエラーで終了し、成功した場合には CURRENT 状態のままになります。また、キーの再生成が正常に実行されると、Pod に READY のマークを付ける readiness プローブもあります。
以下は、キー変更が完了する前に設定されたデーモンセットの出力リストの例です。
$ oc get -n openshift-machine-config-operator ds tang-rekey出力例
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE tang-rekey 1 1 0 1 0 kubernetes.io/os=linux 11s以下は、キーの変更が正常に実行された後のデーモンセットの出力リストの例です。
$ oc get -n openshift-machine-config-operator ds tang-rekey出力例
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE tang-rekey 1 1 1 1 1 kubernetes.io/os=linux 13h
キーの再生成には、通常完了までに数分かかります。
ACM ポリシーを使用してデーモンセットを複数のクラスターに分散する場合には、すべてのデーモンセットの READY の数が DESIRED の数と等しいことを確認するコンプライアンスポリシーを含める必要があります。こうすることで、このようなポリシーに準拠すると、すべてのデーモンセット Pod が READY で、キーの再生成が正常に実行されていることが分かります。ACM 検索を使用して、デーモンセットのすべての状態をクエリーすることもできます。