env-injector作るときに考えてたこと - okzkメモ
medium.com env-injectorが「問題がある」って言われてもうた。ツライ…… というわけで言い訳エントリです。見苦しいですね。 env-injectorの作成時、空の環境変数を作らずに「DescribeParameterでパラメータ一覧ぶっこ抜いてprefixにマッチするものをinjectする」っていうのも考えたんですけど、以下のような理由からやめました。 1. DescribeParameterはIAMのポリシーで必要となる一部のパラメータだけに制限することができない。 開発環境から本番環境のパラメータ一覧が見えたり、別アプリケーションのパラメータ一覧が見えたからって「だから何？」ってハナシもありますが、 なんとなく嬉しくないかなぁ……と。 2. 意図しない環境変数をinjectしないか？ ssm側のパラメータ一覧を全部読み込むことになるので、ちょっとした確認での実行時に
AWSで秘密定数を外部に公開せず環境変数として定義するためのGo製ツール、「ssm2env」作った
ssm2env - Environments injection tool for AWS EC2, with SSM (EC2 Parameter Store). 詳細環境ごとに異なる秘密情報をAPIに渡す際、その管理方法は、twelve-factor appにもある通りデプロイ対象のサーバー内部の環境変数として定義するべき。 ただ、自動化されたデプロイフローでは、どういった手順で秘密情報を渡せばいいか悩むことが多い。 自分が考えた範囲では、 1. AWSのSSMにTerraform経由*1でシークレットな変数を設定 2. APIのデプロイ時にSSMから特定prefixのついたパラメーターを取得 3. パラメーターを全て環境変数として読み込ませる 4. APIが起動する際に秘密情報を定数として環境変数から読み込む*1) 正確にはCircleCIの環境変数設定に事前に入れた状態で、Circ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
