OpenTofu state 암호화, fallback 빼먹으면 일 난다

OpenTofu 1.7에서 state 암호화 기본 기능이 들어온 지도 꽤 됐다. 근데 막상 켜본 분들 중에 method 블록만 설정하고 fallback은 그냥 비워두는 경우가 많더라. 우리 팀도 처음에 그랬다. 결론부터 말하면, fallback 빼면 마이그레이션 순간에 무조건 한 번은 깨진다.

무슨 상황에서 깨지나

평문 state 파일이 있는 워크스페이스에 처음 암호화를 켤 때가 문제다. OpenTofu는 terraform.encryption 블록에서 지정한 method로 state를 읽으려고 시도하는데, 기존 파일은 평문이라 못 푼다. Error: Failed to decrypt state 한 줄 던지고 끝.

키 로테이션도 마찬가지다. PBKDF2 패스프레이즈를 바꿨다? 새 키로 옛날 state는 못 연다. 그래서 fallback이 필요하다.

terraform {
  encryption {
    key_provider "pbkdf2" "new" {
      passphrase = var.new_passphrase
    }

    key_provider "pbkdf2" "old" {
      passphrase = var.old_passphrase
    }

    method "aes_gcm" "new_method" {
      keys = key_provider.pbkdf2.new
    }

    method "aes_gcm" "old_method" {
      keys = key_provider.pbkdf2.old
    }

    state {
      method = method.aes_gcm.new_method

      fallback {
        method = method.aes_gcm.old_method
      }
    }
  }
}

fallback에 있는 method로 일단 복호화를 시도하고, 그 다음 새 method로 다시 암호화해서 저장한다. 한 번 apply 돌리면 state가 새 키로 갈아탄다. 그 뒤로는 fallback 블록을 제거해도 된다.

평문에서 처음 암호화로 넘어갈 때는 fallback을 아예 비워두면 된다. method 없는 빈 fallback이 "평문도 받아준다"는 의미다.

state {
  method = method.aes_gcm.new_method
  fallback {}
}

이 한 줄 빠지면 첫 apply가 안 된다. 처음 보면 당황한다.

1.12.2 보안 패치는 그냥 올리세요

지난달(2026-06)에 나온 1.12.2에 OpenBao key_provider 관련 패치가 들어갔다. 공격자가 조작한 JWE를 보내면 패닉이나 행이 발생하는 이슈였다. OpenBao 안 쓰면 영향 없지만, 어차피 1.12.x 라인은 자잘한 수정도 많이 들어왔으니 minor 업데이트는 그냥 따라가는 게 낫다.

혹시 KMS 기반 key_provider 쓰시는 분 계시면 fallback 패턴이 어떻게 다른지 댓글로 공유해주시면 감사하겠습니다. 우리는 아직 PBKDF2로 충분해서 KMS는 안 써봤다.