ABEJA で Research Engineer をやっている中川です．普段は論文読んだり，機械学習モデルを実装したり，インフラを構築したりしています．ABEJA ではインフラを構成する AWS に対するアクセス制御を容易にするため，以下の概念図のように権限だけを管理するマスターアカウントとサービスのインフラを構成するサービスアカウントに分けて AWS を運用しています．また，インフラは Terraform を用いて管理しています．
今回，さらなるセキュリティ強化のためマスターアカウントに MFA を必須にしました．それに付随して Terraform を変更しようとしたところ，なかなかにハマったのでその解決策を紹介します．
Terraform で実現したい要件
まず，Terraform で何を実現したかったのかを整理します．
- 上記のアカウント方針に従い，マスターアカウントで Terraform を実行して，サービスアカウントに asume role することでインフラを構築する．
- 各メンバーが terraform apply するため，tfstate はサービスアカウントの S3 で管理する．
- 環境差異による事故を防ぐため，Terraform の workspace を使う．
- new マスターアカウントのセキュリティ強化のため，MFA必須下で Terraform を使う．
MFA対応前
MFA対応前は以下のような構成で Terraform を実装していました．
具体的に説明すると，Prod Account に tfstate bucket を作成し，Terraform workspace の切り替えにより assume role 先も変えるような実装をすることで，workspace の変更で透過的に各サービスアカウントに対して terraform apply を実行可能にしていました．この時，Terraform の「tfstate へは assume role 前のアカウント，今回で言えば，マスターアカウントでアクセスする」という仕様により，Prod Account の tfstate bucket へのアクセス権限をマスターアカウントに与える必要があるのは注意がいります．
MFA対応後
ここからが本題です．Terraform で MFA 対応するのに，何が課題であったかというと，
- MFA + CLI は MFA code を CLI で入力する必要があったりと，そもそも面倒なことが多い．
- Terraform + assume-role + MFA は Terraform 公式では非対応となっている．
特に Terraform では CLI による対話的な操作を排除する世界観を目指そうとしているらしく，この issue にあるように闇が深そうです．
そこで取った解決策は，以下のように assume role してから terraform apply を実行するという方法です．
これにより，assume role するという手順が1コ増えてしまいますが，セキュリティを高めつつ上記の要件を達成することができます．これを実現するために，Prod Account にある tfstate bucket に Dev/Stg Account からアクセスできるように権限を付与しました．さらに，これだけだと既存 tfstate に関しては所有者がマスターアカウントであり，各サービスアカウントからアクセスすることができないので，既存 tfstate にも各サービスアカウントからアクセスできるように権限を付与しました．これで晴れて Terraform workspace + assume-role + MFA が実現されました．
なお，assume-role する方法はいくつかありますが，取り回しが比較的ラクなので ABEJA では以下の OSS を利用しています． github.com また，MFA + CLI の自体のハマりポイントは以下の記事が参考になります． dev.classmethod.jp
まとめ
assume role を明示的に実施するという手順が1コ増えてしまいましたが，今までの要件を達成しつつ MFA 対応もしてセキュリティを高めることができました．
宣言
インフラエンジニアから機械学習のスキルを伸ばしたい方，逆に機械学習エンジニアからインフラのスキルを伸ばしたい方，サービス開発に関わりながらスキルを伸ばしていける環境です．ぜひぜひご応募ください．
www.wantedly.com www.wantedly.com www.wantedly.com
ABEJAの中の人と話ししたい！オフィス見学してみたいも随時受け付けておりますので、気軽にポチッとどうぞ↓↓
