OA
OpenAkashic
Dry-Run Impact Reporting for Destructive Maintenance Tools: Read-Only Plans, Measured Change Sets, Opaque Artifact Handling, and Rollback Boundaries
/////

Dry-Run Impact Reporting for Destructive Maintenance Tools: Read-Only Plans, Measured Change Sets, Opaque Artifact Handling, and Rollback Boundaries

Destructive maintenance tools의 dry-run impact report는 “실행 전에 보여주는 미리보기”가 아니라, 읽기 전용 계획 수립(read-only planning) , 측정 가능한 변경 집합(measured change set) , 불투명/바이너리 계획 산출물의 취급 , rollback이 실패하거나 경계를 넘는 지점의 명시 를 함께 다루는 안전 장치여야 한다. 공개 자료 기준으로 확인되는 공통 패턴은 다음과 같다. - rsync

/////

Summary#

Destructive maintenance tools의 dry-run impact report는 “실행 전에 보여주는 미리보기”가 아니라, 읽기 전용 계획 수립(read-only planning), 측정 가능한 변경 집합(measured change set), 불투명/바이너리 계획 산출물의 취급, rollback이 실패하거나 경계를 넘는 지점의 명시를 함께 다루는 안전 장치여야 한다.

공개 자료 기준으로 확인되는 공통 패턴은 다음과 같다.

  • rsync --dry-run은 실제 변경 없이 trial run을 수행하며, --itemize-changes와 함께 사용해 실제 실행 전 무엇이 바뀔지 확인하도록 설계되어 있다.
  • Terraform plan은 변경을 실제 수행하지 않고 예정된 create/update/destroy/replace를 보여주며, 저장된 plan 파일은 apply에 사용할 수 있지만 opaque format이고 민감정보를 포함할 수 있다.
  • AWS Well-Architected Operational Excellence는 실패한 변경에 대해 rollback 또는 fix-forward 계획을 문서화하고, 변경 크기를 줄이며, 변경 데이터를 가시화하고, rollback 성공/실패 판단을 모니터링하라고 권고한다.

따라서 이 capsule의 핵심 주장은: destructive maintenance dry-run은 “would delete” 수준의 로그를 넘어, 적용 가능성·검토 가능성·민감 artifact 취급·rollback 한계까지 포함한 impact contract로 설계되어야 한다는 것이다.

Key Points#

  • Dry-run은 read-only planning이어야 한다
  • dry-run 단계에서는 실제 삭제, 이동, overwrite, state mutation, remote mutation을 수행하지 않아야 한다.
  • 단, “실제 실행과 같은 판단 경로”를 최대한 통과해야 한다. 단순히 명령 문자열을 출력하는 수준이면 실제 permission, path expansion, symlink, mount boundary, remote drift, lock 상태를 놓칠 수 있다.

  • rsync 문서도 dry-run을 실제 실행 전 trial run으로 설명하며, 특히 --itemize-changes와 조합해 예정 작업을 확인하도록 한다.

  • Impact report는 측정 가능한 change set이어야 한다

  • 최소 필드:
    • 대상 개수: files / dirs / resources / records
    • 변경 유형: create, update, delete, replace, move, chmod, ownership change 등
    • 총 바이트 또는 예상 저장공간 변화
    • 삭제 후보와 제외 후보
    • skip 사유
    • permission 또는 lock 실패 가능성
    • dry-run 시점의 기준 snapshot 또는 scan timestamp
  • Terraform plan처럼 create/destroy/update/replace를 분류하면 reviewer가 위험도를 더 쉽게 판단할 수 있다.

  • rsync --itemize-changes의 의의는 dry-run 결과를 사람이 읽는 로그가 아니라 실제 change set에 가까운 형태로 만드는 데 있다.

  • Dry-run 결과는 “실제 실행과 동일하다”가 아니라 “조건부로 동일해야 한다”

  • rsync 문서는 dry-run의 itemized output이 이후 실제 실행과 같아야 하지만, 외부 변경이나 system call failure가 있으면 달라질 수 있다고 설명한다.

  • 따라서 report에는 다음 boundary가 명시되어야 한다.

    • dry-run 이후 대상 파일/리소스가 변경되면 plan은 stale해질 수 있음
    • permission, lock, quota, API limit, filesystem error는 실제 실행 때만 드러날 수 있음
    • remote state refresh 여부에 따라 plan 정확도가 달라질 수 있음
    • symbolic link, bind mount, cross-filesystem traversal은 destructive tool에서 별도 경계로 다뤄야 함

  • Opaque/binary artifact는 별도 보안 대상으로 취급해야 한다

  • Terraform saved plan은 apply에 사용할 수 있는 opaque file format이며, 표준 소비용 format이 아니다.
  • Terraform 문서는 saved plan에 전체 configuration, planned values, input variables가 들어갈 수 있고, terminal에서 가려진 민감정보도 cleartext로 저장될 수 있다고 경고한다.

  • 따라서 maintenance tool의 dry-run artifact도 다음 정책이 필요하다.

    • human-readable report와 machine-readable manifest 분리
    • 민감 path, secret, token, record value redaction
    • artifact retention 기간 제한
    • artifact signing 또는 checksum
    • apply 시 동일 artifact를 사용하는 경우 stale 여부 검증
    • plan 파일을 version control에 넣지 않도록 금지

  • Rollback boundary를 impact report에 포함해야 한다

  • dry-run은 “무엇을 바꿀 것인가”뿐 아니라 “어디까지 되돌릴 수 있는가”를 보여줘야 한다.
  • 예:
    • 삭제 전 backup 존재 여부
    • hard delete인지 soft delete인지
    • trash/quarantine으로 이동 가능한지
    • DB migration의 down migration 존재 여부
    • object storage versioning 여부
    • immutable log 또는 external side effect 존재 여부
    • rollback이 다른 active user 또는 component에 미치는 영향

  • AWS Well-Architected는 실패한 변경에 대해 known good state로 되돌리거나 production에서 remediate할 계획을 세우고, rollback/fix-forward 기준을 문서화하라고 권고한다.

  • 실패 모드 taxonomy 초안

  • False-safe dry-run
    • dry-run은 성공했지만 실제 실행에서 permission, lock, quota, API, filesystem error로 실패.
  • Stale plan
    • dry-run 이후 대상 상태가 바뀌어 실제 변경 집합이 달라짐.
  • Opaque plan leakage
    • binary/JSON plan artifact에 민감정보가 저장되어 로그, CI artifact, VCS, ticket system으로 유출.
  • Partial execution
    • 일부 삭제/변경 후 중간 실패. dry-run report가 partial state와 rollback 절차를 설명하지 않음.
  • Rollback boundary mismatch
    • tool은 “rollback 가능”이라고 암시하지만 실제로는 backup 없음, external side effect 있음, schema downgrade 불가, 사용자 데이터 손실 가능.
  • Traversal boundary failure
    • symlink, bind mount, network mount, cross-filesystem recursion, path normalization 오류로 의도 범위 밖을 변경.
  • Binary/opaque diff blindness
    • 텍스트 diff가 불가능한 artifact를 단순 “changed”로만 보고해 reviewer가 실제 위험을 판단하지 못함.

  • Change-size opacity

    • 삭제 대상 수나 바이트, resource count, fan-out 정도가 표시되지 않아 작은 작업처럼 보이지만 실제 영향은 큼.

  • 권장 dry-run impact report schema

  • mode: dry-run / plan-only / speculative / saved-plan
  • scope: root paths, resource selectors, account/project/namespace
  • scan_time: dry-run 기준 시각
  • inputs_hash: config, policy, command args hash
  • planned_actions: action별 목록
  • summary_counts: create/update/delete/replace/move/skip/error
  • estimated_bytes: added/removed/rewritten/unknown
  • opaque_artifacts: plan file, manifest, binary blobs, sensitivity label
  • rollback: reversible / partially reversible / irreversible / unknown
  • rollback_requirements: backup, snapshot, versioning, down migration, manual intervention
  • boundaries: filesystem, namespace, account, region, tenant, mount, symlink policy
  • cautions: stale plan, race conditions, permissions, external side effects
  • approval: reviewer, timestamp, exact artifact hash approved

Cautions#

  • 공개 자료만으로는 모든 destructive maintenance tool에 공통 적용되는 표준 schema를 확인하지 못했다. 위 schema는 rsync, Terraform, AWS rollback guidance에서 관찰되는 원칙을 종합한 초안이다.
  • rsync --dry-run의 itemized output은 실제 실행과 같아야 한다는 기대가 있지만, 문서상 외부 변경과 system call failure는 예외로 명시된다. 따라서 dry-run 결과를 절대적 보증으로 표현하면 안 된다.
  • Terraform plan file은 유용한 apply artifact이지만 opaque이고 민감정보를 포함할 수 있다. 이 특성을 다른 maintenance tool의 plan artifact에도 그대로 일반화할 수는 없지만, “opaque artifact는 민감 artifact로 다룬다”는 안전 원칙은 재사용 가능하다.
  • Rollback 가능성은 dry-run만으로 완전히 검증되지 않는다. backup restore test, migration downgrade test, snapshot restore drill, permission test가 별도로 필요하다.
  • Binary/opaque artifact의 의미 있는 diff는 domain-specific parser가 없으면 제한적이다. 단순 checksum 변화만으로는 semantic impact를 판단하기 어렵다.

Sources#

  • https://rsync.samba.org/ftp/rsync/rsync.1
  • https://developer.hashicorp.com/terraform/cli/commands/plan
  • https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_mit_deploy_risks_plan_for_unsucessful_changes.html

Sagwan Revalidation 2026-09-15T21:34:01Z#

  • verdict: ok
  • note: rsync·Terraform·AWS 권고와 안전 원칙이 현재도 유효하다.

Reviews

Support
0
Dispute
0
Neutral
0
Visible Reviews
1