トップ «前の日記(2017-12-26) 最新 次の日記(2018-01-01)» 編集

2017-12-28 [長年日記]

_ IAM Policyの作り方に悩む - とりあえずS3 + CloudFront静的サイトを考える -

まとめ

  • AWS の Policy の種類が復習できた
  • AWS の Policy 関連用語と Terraform 用語の Resource, Data Source 用語との紐付けができた
  • 静的サイト向けの Policy に集中して考えた

操作から切り離して概念を整理しやすいのでドキュメントベースになるとありがたい。

AWS S3 の Bucket を読み書きできるポリシーとその適用方法が揺れていた

これまでに存在しているポリシーが以下のようなひどいことになっていた。

  1. S3 の Bucket Policy で Role と Action を割り当てているもの
  2. S3 の読み書きに特化した IAM User を作り、そのインラインポリシー ( IAM User Policy ) 側に Bucket ( arn ) 情報が書かれているもの
  3. IAM User Policy Attachment ( 未適用 )

図にするとこんな感じ。

S3 Bucketの読み書きのPolicy設定方法が複数ある様子

※ 上の図では AWS 用語を枠線で囲んでおいて、Terraform 用語を無地の上にそのまま置いている。そもそもこれまでこの辺の用語の理解が曖昧だったことに今回ほんとに気づかされている。(どうしても触る機会の少ないインフラ周りがおざなりになってしまう。)今回気づいたのは Bucket でも User でもない真ん中の Managed-Policy を aws_iam_policy で管理するようにしたらどうか?という話。

初期は 1 でやっていた。この頃の目的は静的サイト向けの Bucket ではなく、Web アプリの無限ストレージとして使い始めた。まだ AWS 自体がよく分かっておらず、読み書きを割り当てている IAM User の概念もボンヤリしていた。

で、いくつかそういうアプリが増えてきたときに Bucket 作って Policy 開いて、みたいな操作がダルくてイヤになって、Policy だけ別に作って Bucket に適用した方がよいのでは? と思い始めて 2 の形になった。

しかしこれは今にして思うと失敗だった。たぶん当初 3 を意識していたがやはり操作が面倒くさくて 2 の形に流れてしまった。

しかもこの形での指定が妙に複雑になっている部分がある。確か

  • ログイン可能な IAM User が手動で読み書き可能な Bucket を確認できるように
  • Rails + fog で bucket を覗く際になぜか指定が足りないと怒られた

辺りが理由と記憶しているが、これは静的サイトを CI で deploy するようにという今回の目的のためには不要な配慮になるはず。

解決案

静的サイトに限定して考える。

上のポリシーは Web アプリのストレージとしての Bucket のポリシーと混ざっているのがそもそもよくない。

AWS のマネージメントコンソールを手作業でぽちぽちしていくやり方と Terraform を共存(怖いけど)させる場合、恐らく 1 の形に近づけて Policy を Data Source で定義したうえで、せめてコピペせずに Bucket ごとに 個別に割り当ててあると直感的に分かりやすいと思う。(Bucket のプロパティを覗けばどういう状況か分かるので。)

ただ、ちゃんと自動化するなら第4の方式、

  • S3 Bucket
  • IAM User
  • IAM Policy
  • IAM Policy Document

をそれぞれ独立して定義した上で IAM User に IAM Policy をアタッチしておいて、最終的に IAM Policy Document だけをメンテすればよい感じにする方が .tf も .tfstate も diff が小さくなると思う。

少なくとも IAM User Policy の側に Bucket (正確には arn)を列挙してしまっている現状は、手作業での手間は若干減ってはいる(少なくとも bucket ごとに丸ごと policy をコピペしたうえで書き換える必要はない)が、自動化前提ではアホくさい。

User の関心事は 1) シンプルに静的サイトの deploy であり、2) deploy は手作業でなく CI/CD サービス経由であり、3) ログインは不要であるならば、 ユーザーの知っているべき情報は特に変化はない

手作業を捨てるならコードは DRY にして設定ファイルとしての HCL の可読性に寄せる方がスジがよいと思われる。

要確認

そもそも CloudFront 経由でしか publish しない方針なら、実は S3 の Read Only Policy って必要ないのでは?

参考