消したのに残っている：GitOps削除保護実験

目標

Gitでの削除の意図、オブジェクトごとの保護、承認、空の目標の拒否を、本物のArgo CDとk3sで区別します。

なぜ重要なのか

OutOfSyncは保護が働いた結果であることがあり、Succeededは現在のコミットの結果ではないことがあります。本番のLabHub・外部リポジトリ・ユーザーデータ・PVCには触れません。個人VMのcgoa-prune-safety Namespaceと専用のApplication 2つだけを使います。実際の削除の対象は、学習用の文字列を入れたConfigMapです。 Namespace・Application・共有のコントローラーは削除しないでください。グローバルなセキュリティ設定や権限を変えません。 55分のラボです。セッションの期限が切れる前に、必要なら時間を延長し、観測を保管してください。終了すると、VMとファイルは回収されます。

用意されている環境とヘルパー

/srv/cgoa-prune-safetyは作業用のGit、/srv/bare/cgoa-prune-safety.gitはVM内部のリモートリポジトリです。 Application cgoa-prune-safetyはappディレクトリを、cgoa-prune-safety-emptyはemptyディレクトリを読みます。 mainという名前の代わりに、実際のSHAを突き合わせてください。観測ファイルは/root/cgoa-pruneにあります。課題のkey=valueは説明用の表記です。JSONファイルには、形式の例のようにキーと文字列に引用符を付け、ブール値はtrue/falseで書いてください。 python3 /opt/fixtures/cgoa_prune_lab.py observeは、現在のGit・Application・ConfigMapを読みます。同じヘルパーのcomplete Nは、入力をレビューし、限定された変更のあとに実際の観測を保存します。ステップ2・3・4・5はGitの変更、ステップ6は削除の承認、ステップ7は空の目標のレビューのあとのポリシー変更、ステップ8はデフォルトのポリシーとGitの復元です。ステップ7のpreview-emptyは、Gitから最後の対象だけを削除して保護を先に観測し、削除の許可には別の答案とcomplete 7が必要です。 git showで、ヘルパーが作った変更を自分でレビューしてください。既存の未完成のGitの変更や部分的な答案は、上書きせずに停止します。 solve Nは、正解の表示と同じで、ない現在の答案だけを作成します。prepare Nは、ない前のステップだけを準備し、現在の答案は作りません。 grade Nは読み取りだけを行います。完了したステップをもう一度実行しても、削除や観測の生成を繰り返しません。

ステップ

git -C /srv/cgoa-prune-safety rev-parse HEADとbaseline.jsonを読んでください。identity.jsonに、revision=実際のコミットSHA、namespace=cgoa-prune-safetyを文字列として書き、complete 1を実行します。observation-1.jsonで、2つのApplicationのsource.pathと、5つのConfigMapの所有権・UIDを確認してください。
baseline.jsonのconfigmaps.normal.uidを確認してください。normal.jsonに、remove=normal、uid=確認したUIDを文字列として書き、complete 2を実行します。ヘルパーは、appディレクトリのnormalだけをGitから削除します。git showとobservation-2.jsonで、normalだけがなくなってSynced/Succeededになっているか、残りのUIDはそのままかを確認してください。
retention.jsonに、remove=retained、option=Prune=false、expected_sync=OutOfSyncを文字列として書き、complete 3を実行してください。Gitからretainedがなくなっても、実際のUIDは維持されます。observation-3.jsonのoperationState.syncResult.resourcesでPruneSkippedを探し、SucceededとOutOfSyncが同時にある理由を説明してください。
restore.jsonに、fix_source=gitを文字列で、same_object=trueをブール値で書き、complete 4を実行します。Gitの定義が戻ったあと、retainedが同じUIDでSyncedになっているかを確認してください。liveのオブジェクトを削除したり作り直したりする方式は、この課題での保持ではありません。
pending.jsonに、remove=confirmed、expected_operation=Runningを文字列で、approved=falseをブール値で書き、complete 5を実行してください。observation-5.jsonで、承認待ちのメッセージと、requiresPruningの対象がconfirmed 1つであることを確認します。Runningをコントローラーの障害と決めつけないでください。
observation-5.jsonでapps.app.uidとconfigmaps.confirmed.uidを読んでください。approval.jsonに、approve=trueをブール値で、app_uidとtarget_uidを該当のUID文字列で書き、complete 6を実行します。ヘルパーは、今もレビューしたオブジェクトと範囲であるかを突き合わせたうえで、Applicationに承認の時刻を記録します。Gitのコミットはそのままなのに、confirmedが削除されてSynced/Succeededになったかを確認してください。
まずpreview-emptyを実行してください。emptyディレクトリの目標を有効な空のListに変えますが、削除は許可しません。guard-7.jsonのsnapshot.revisionとapps.empty.status.operationState.syncResult.revisionが異なり、SyncErrorであり、disposableのUIDが保持されているかを読んでください。empty.jsonに、allow_empty=trueとprevious_success_is_current=falseをブール値で、revision=レビューした現在のSHA、target_uid=disposableのUIDを文字列として書き、complete 7を実行します。同じGitのままポリシーだけが変わり、disposableだけが削除されるかを確認してください。
decision.jsonに、restore_git=true、allow_empty=false、same_object=false、backup_verified=falseをブール値で書き、complete 8を実行してください。デフォルトの保護をfalseに復元し、Gitの定義を元に戻します。observation-8.jsonで、disposableは新しいUID、retainedとanchorは基準のUIDであるかを確認してください。宣言の復元とデータのバックアップの検証を区別して報告します。

注意と解釈

retainedとanchorは、最後まで基準のUIDとデータを維持します。disposableは、削除と復元のあとに新しいUIDになっている必要があります。承認の対象のUIDと現在の範囲が変わると、停止します。承認のアノテーションはApplication単位だという事実を忘れないでください。空の目標は読み取りの失敗ではなく、有効なListのitems=[]です。拒否のメッセージだけでなく、現在のrevision・ポリシー・保持するオブジェクトを一緒に確認します。完了記録のハッシュは、うっかりファイルを上書きしたことを検知します。同じVMのrootによるあらゆる偽造を防ぐセキュリティ上の保証ではありません。 pendingのジャーナルが残った場合、変更が完了したかどうかを推測して、もう一度削除することはしません。資料を保管して、新しいラボで始めてください。採点は60秒、前のステップの準備は90秒の予算です。収束の待機は、completeでのみ行います。 Argo CDの同期オプション・自動同期と空の目標

Gitとオブジェクトの寿命の基準線を読む

git -C /srv/cgoa-prune-safety rev-parse HEADとbaseline.jsonを読んでください。identity.jsonに、revision=実際のコミットSHA、namespace=cgoa-prune-safetyを文字列として書き、complete 1を実行します。observation-1.jsonで、2つのApplicationのsource.pathと、5つのConfigMapの所有権・UIDを確認してください。

ブランチ名の代わりにコミットSHAを、オブジェクト名と一緒にUIDを読んでください。

保護のないオブジェクトの実際の削除を確認する

baseline.jsonのconfigmaps.normal.uidを確認してください。normal.jsonに、remove=normal、uid=確認したUIDを文字列として書き、complete 2を実行します。ヘルパーは、appディレクトリのnormalだけをGitから削除します。git showとobservation-2.jsonで、normalだけがなくなってSynced/Succeededになっているか、残りのUIDはそのままかを確認してください。

Gitのdiffと現在のConfigMapの一覧を、一緒に比較してください。

削除をスキップした成功と差を区別する

retention.jsonに、remove=retained、option=Prune=false、expected_sync=OutOfSyncを文字列として書き、complete 3を実行してください。Gitからretainedがなくなっても、実際のUIDは維持されます。observation-3.jsonのoperationState.syncResult.resourcesでPruneSkippedを探し、SucceededとOutOfSyncが同時にある理由を説明してください。

操作の成功と、望ましい状態との一致は、別の問いです。

Git復元で同じオブジェクトを保持する

restore.jsonに、fix_source=gitを文字列で、same_object=trueをブール値で書き、complete 4を実行します。Gitの定義が戻ったあと、retainedが同じUIDでSyncedになっているかを確認してください。liveのオブジェクトを削除したり作り直したりする方式は、この課題での保持ではありません。

名前が同じでもUIDが変われば、同じオブジェクトを保持したことにはなりません。

承認待ちと削除対象を確認する

pending.jsonに、remove=confirmed、expected_operation=Runningを文字列で、approved=falseをブール値で書き、complete 5を実行してください。observation-5.jsonで、承認待ちのメッセージと、requiresPruningの対象がconfirmed 1つであることを確認します。Runningをコントローラーの障害と決めつけないでください。

operationState.messageとrequiresPruningの一覧を読んでください。

レビューしたUIDに限って承認する

observation-5.jsonでapps.app.uidとconfigmaps.confirmed.uidを読んでください。approval.jsonに、approve=trueをブール値で、app_uidとtarget_uidを該当のUID文字列で書き、complete 6を実行します。ヘルパーは、今もレビューしたオブジェクトと範囲であるかを突き合わせたうえで、Applicationに承認の時刻を記録します。Gitのコミットはそのままなのに、confirmedが削除されてSynced/Succeededになったかを確認してください。

承認のアノテーションはApplicationに付くので、削除予定の範囲の全体を確認してください。

空の目標の拒否を観測したうえで、明示的に許可する

まずpreview-emptyを実行してください。emptyディレクトリの目標を有効な空のListに変えますが、削除は許可しません。guard-7.jsonのsnapshot.revisionとapps.empty.status.operationState.syncResult.revisionが異なり、SyncErrorであり、disposableのUIDが保持されているかを読んでください。empty.jsonに、allow_empty=trueとprevious_success_is_current=falseをブール値で、revision=レビューした現在のSHA、target_uid=disposableのUIDを文字列として書き、complete 7を実行します。同じGitのままポリシーだけが変わり、disposableだけが削除されるかを確認してください。

最後の操作の成功が、どのGitコミットに属しているかを確認してください。

デフォルトの保護とGitを復元し、限界を報告する

decision.jsonに、restore_git=true、allow_empty=false、same_object=false、backup_verified=falseをブール値で書き、complete 8を実行してください。デフォルトの保護をfalseに復元し、Gitの定義を元に戻します。observation-8.jsonで、disposableは新しいUID、retainedとanchorは基準のUIDであるかを確認してください。宣言の復元とデータのバックアップの検証を区別して報告します。

ConfigMapの再作成は、ボリュームやデータベースの復旧テストではありません。