🔏

AWS Secrets Managerへの接続がうまく行かなかったとき。

2 min read

こんにちは。
先日、Fargateによるバッチ実行をしようと思って色々と調べていたのですが原因がすぐにわからなかったので、ここに書き留めておこうと思います。

何をやろうとしていたのか

FargateでEmbulkを利用してデータをBigQueryに転送するタスクを実行しようとしていた。
主に参考にしてたのは以下の記事

https://labs.gree.jp/blog/2019/03/17834/

何が起きたのか

以下のエラーがFargateのタスクのPending時に起きた。

ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve secret from asm: service call has been retried 5 time(s): failed to fetch secret arn:aws:secretsmanager:ap-northeast-1:111111...

調べてみると以下の記事にたどり着きます。

https://dev.classmethod.jp/articles/tsnote-ecs-resourceinitializationerror/

しかしながら他にも同じように立てていたFargateタスクは問題なく実行できていました。
また、secrets managerを経由せずに直接値を渡せば該当Fargateタスクは問題なく実行できた。
ただ違うとすれば今回Fargateのバージョンを1.4.0で動かしていた(以前は1.3.0)ことと、ValueFromに渡す際にパラメータとして渡していただけです。

Fargate 1.4.0からSecrets Managerの各パラメータを個別に環境変数にわたすことができるようになってるのでこれを使いたかったのです。

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/specifying-sensitive-data-secrets.html

以下の様にValueFromにわたすことで、username1がKeyのパラメータの値を環境変数にわたすことができるんですね。

arn:aws:secretsmanager:region:aws_account_id:secret:appauthexample-AbCdEf:username1::

Fargate 1.4.0 による変更点

過去に動かしていたFargateは1.3.0でした。
1.4.0の変更は以下の記事に載ってあります。

https://aws.amazon.com/jp/blogs/news/aws-fargate-launches-platform-version-1-4/

この記事で大きく変更があったのはタスク実行の際のElastic Network Interface(ENI)がFargate ENIからTask ENIに変わることです。

そして色々記事を探してみると、プライベートサブネットに配置する場合はPrivateLink機能を利用してapi.ecrも設定しろという記事が多数でした。
しかしながら今回実行していたFargateタスクはパブリックサブネットに配置して実行していたのでこの件には当たりませんでした。

なんとなくわかってきた?

いままでの流れから、
Fargate 1.3.0で動かしているタスクは動いていたので、Fargate 1.4.0で変わったことに何か問題があるのは大体わかってきました。
怪しいのはsecrets managerの値を取ってくるのがFargate ENIからTask ENIに変わったことです。

AWSの保守をしている会社にも聞いたものの設定はおかしくない。との返事で行き詰まっておりました。

やっとわかる

色々探してみて、Fargate ENIはAWS管理のVPCを経由してアクセスしていることを理解し、Task ENIは自分で指定したVPC上からアクセスしていることを理解しました。

設定自体は間違えてないことは判断できたので、色々とりあえずsecrets manager側でネットワークで何かないか追っかけたところsecrets managerをVPCエンドポイント経由でアクセスすることができるという記事を発見。

https://docs.aws.amazon.com/ja_jp/secretsmanager/latest/userguide/vpc-endpoint-overview.html

しかもこれはプライベートDNSが設定されるので、対象のVPC上であればどこからでもこのエンドポイントのIPにアクセスしようとします。

そして実際にsecrets managerのVPCエンドポイントが設定されていることを確認。
最初はサブネットが別のプライベートサブネットに対してしかIPが振られてなかったのでDNSは返却しないんじゃないか?と疑っていたのですが実際に動いているpublic subnetなサーバー上でdigしてみるとプライベートIPが返ってきました。ええ。

原因

結果的に原因としてはsecrets managerのVPCエンドポイントのセキュリティグループでインバウンドを絞られていたのが原因でした。
絞られていたので、Fargateを動かす際のセキュリティグループもインバウンド許可するようにセットし無事Fargateタスクは動くようになりましたとさ。

こういった自分で設定していないけど間接的に影響が起きるような問題は気づきにくいですね。
今後もこういったことがありそうなのでなぜか繋がらないといった現象が起きたときには気にしてみようと思います。

Discussion

ログインするとコメントできます