.terraform.lock.hcl の自動 update について検討する

[suzuki-shunsuke]

Renovate による provider の自動アップデート

Renovate では required_providers の provider のバージョン制約で、 provider の version を固定することを強制し、 そのバージョン制約のバージョンを update するということをする。

.terraform.lock.hcl を更新せずにバージョン制約だけ上げると terraform init は失敗する。

現状

https://github.com/suzuki-shunsuke/github-action-terraform-init/tree/v0.1.4 では terraform init に失敗したら terraform init -upgrade を実行し、 .terraform.lock.hcl を更新し、自動でコミットするようになっている。

以前自分が shell script で同様の処理を実装していた際は、 PR Author が Renovate の場合のみ同様の処理を行っていたが、 https://github.com/suzuki-shunsuke/github-action-terraform-init/tree/v0.1.4 では PR Author をチェックしなくなってしまっている

.terraform.lock.hcl の自動 update の必要性

まず Renovate で provider を自動 update するには .terraform.lock.hcl の自動 update が不可欠。 加えて、 terraform に詳しくない人が使う前提で考えると、ローカルで .terraform.lock.hcl を更新してもらうのはハードルが高い。 CI で丁寧なガイド(脳死でコマンド実行すれば OK) をコメントできれば改善するかもしれないが、それでも結構ハードルがある。 特に組織の規模が大きいと厳しい(小さければ教育すればよいし、コミュニケーションも取りやすい)

provider を working directory で管理せず、中央集権的に管理するという選択肢

これは mercari が採用している方法。 working directory ごとに update する必要がないし、使用する provider を中央集権的に管理することでサプライチェーン攻撃にも対応できる。 やるとしたら

• .terraform.lock.hcl を .gitignore に追加
• version 制約はどうする？

自動で .terraform.lock.hcl を更新するリスク

バージョンをコードで管理し、再現性を保証するという意味では自動 update でも問題ない。 ただし、 .terraform.lock.hcl にはサプライチェーン攻撃を防ぐという機能もあり、自動 update してしまうとその効果を損なう可能性がある気がしている。 .terraform.lock.hcl には download された provider の checksum が記録されており、 terraform init で download された provider の checksum が .terraform.lock.hcl に記録された checksum と異なる場合、 terraform init が失敗し、改ざんを検知することができる。 しかし、自動で terraform init -upgrade を実行するということは、それを無視して .terraform.lock.hcl を改ざんされた provider の checksum で書き換えてしまうことになるのではないかと思われる。

.terraform.lock.hcl を更新するケース

• 新しい provider の追加
• provider の update
• 新しい platform の追加(CI は linux/amd64 で実行しているので、追加されるとしたら linux/amd64)

Provider の信頼性をどう検証するのか

• provider の新しい version が出たとして、その信頼性をどう検証するのか
• https://discuss.hashicorp.com/t/what-is-the-best-practise-with-terraform-lock-hcl-in-modules-commit-or-not/28648/2

However, there are other mechanism in place that complement the lock file:

Terraform verifies the certificate of the remote registry against your system’s trusted certificate store, preventing certain kinds of misdirection or man-in-the-middle attacks. If you’re using the default direct installation method then Terraform checks the downloaded package against a set of approved checksums signed using a signature selected by the registry, so an attacker would need to compromise the checksums, the signature, and the package. If you’re running terraform validate in an isolated environment without access to any credentials then you might conclude also that the risk of executing arbitrary untrusted code is relatively low in this case.

registry にある provider は署名されているので、それも含めて侵害する必要がある。 ただ CI で署名をしてて GitHub Account を乗っ取られたりすると署名では防げない。

terraform validate って credential なしでも実行できるのか。 provider さえダウンロードされていればできるってことかな

[suzuki-shunsuke]

$ terraform init -upgrade

だとすべての provider を upgrade することになるし、 terraform init が失敗したらだと、 checksum が変わっていても検知できない。 Renovate で update された特定の provider だけ更新するみたいなことができると便利

[suzuki-shunsuke]

https://www.terraform.io/cli/commands/providers/lock

引数で provider 指定すれば特定の provider だけ update できる

[suzuki-shunsuke]

やりたいこと

• Terraform Provider の Update を自動化したい
  • 大量の working directory を手動で update, Renovate を全部手動で approve は避けたい
  • terraform に詳しくない人が、 .terraform.lock.hcl をよく知らなくてもなんとかなるようにしたい
• Working Directory ごとに段階的に update できるようにしたい
  • 全 working directory でバージョンを共通化し、一気に update は避けたい
• セキュアにしたい
  • provider の改ざんを防げるようにしたい
  • 利用可能な provider をホワイトリストで管理したい
  • terraform init -upgrade で改ざんを見逃すのは避けたい
• provider や module のダウンロードを高速化したい
  • キャッシュが肥大化して遅くなるとかは避けたい