SUZUKI, Masashi

2026/08/15(土) JAWS-UG 茨城 #16 LT&BBQ大会https://jawsug-ibaraki.connpass.com/event/401327/ で話した内容。TerraformでSecret値を扱う際の課題とその対応の話。

2026-08-15 JAWS-UG 茨城 #16 Secrets ManagerにおけるSecret値の管理(Terraformの場合) / Secrets Manager Secrets

https://3-shake.connpass.com/event/399469/ で発表した内容

2026-07-28 3-shakeテックランチ Cloud Run のデプロイパラメータを考える / Cloud Run Deploy Parameter

社内勉強会でtfplanをざっくり調べた結果の共有https://www.hashicorp.com/ja/blog/introducing-tfpolicy-a-declarative-policy-workflow-built-for-terraformhttps://developer.hashicorp.com/terraform/policy

2026-07-24 tfpolicyを試してみたのですが、、、、

社内勉強会の内容ecspressoが便利すぎて勢い余って、自分もインスパイアされてコードを書いた話https://github.com/masasuzu/clrnd

2026-06-18 ecspressoのtfstate参照が便利すぎた話

Terraform Stateにおけるシークレットの平文保存という課題とその解決[0ベースから学ぶ、クラウドネイティブの春！ - connpass](https://jaguer-cloud-native.connpass.com/event/387350/) で発表した内容

2026-04-14 Jagu'e'r Cloud Native分科会 Terraform Stateにおけるシークレットの平文保存という課題とその解決

怠惰な人がコマンドライン操作を楽をするためのテクニック[Terminal Night #2 - connpass](https://kichijojipm.connpass.com/event/382650/)

2026-03-27 #terminalnight 変数展開とコマンド展開でターミナル作業をスマートにする方法

Ops-JAWS Meetup39 あなたの推しのSSMは？SSM運用特集https://opsjaws.connpass.com/event/383000/Session Managerを使った セキュアなサーバーアクセスに関してのスライド。

2026-03-23 Ops-JAWS Meetup39 Session Managerを使った セキュアなサーバーアクセス

JAWS-UG 茨城 #12 春の推しAWSサービスLTまつり！の資料https://jawsug-ibaraki.connpass.com/event/381293/

2026-03-11 JAWS-UG 茨城 #12 改めてALBを便利に使う

Jagu'e'r Tech Writer Meetup #19で発表した内容

2026-03-03 Jagu'e'r Tech Writer Meetup #19 登壇のネタ作りについて

2026-02-24 月末 Tech Lunch Online #10 Cloud Runのデプロイの課題から考えるアプリとインフラの境界線

今年はブログ4本(純粋なAWSの記事はなし)、登壇5本(内社内2本)という結果でした。勉強会参加自体はそこそこしてたんですが、アウトプットという点では少し物足りない結果になったなという感想です。要因としてはGoogle Cloud関連の活動が比較的多くて、AWS関連にリソースを割けなかったというのもあります。第二の理由としては今年後半が特に業務が多忙で身動きが取れない月があったのも事実です。とはいえ忙しいは言い訳に過ぎないので、なんとアウトプットする仕組み作りをしていきたいとことです。来年はもっとアウトプットを増やしていきたいです。そこで以下の数値を目標にやっていきたいと考えています。社外登壇: 月0.5本AWSテーマのブログ: 月1本以上やってくぞ。以下今年のアウトプットを置いておきます。ブログAWS関連なしクラウドニュートラルblog.masasuzu.netdiary.masasuzu.netdiary.masasuzu.netblog.masasuzu.net登壇AWS関連 speakerdeck.com speakerdeck.com speakerdeck.comクラウドニュートラル speakerdeck.com speakerdeck.com

2025年AWS Community Builderの活動報告

この記事は3-shake Advent Calendar 2025です。qiita.com吉祥寺.pm #37で話した内容となります。kichijojipm.connpass.com speakerdeck.com厳密には10年以上前に行ったことあるんですが、完全に忘れているので実質今回が初回ということでお願いします。今回は業務として、KubeCon NAへ行かせてもらったのでその体験を共有いたします。セッション内容については触れません。旅程的には11/11-17となっており、KubeCon NAの開催期間としては11/12-15となっています。以下の目次で送らせていただきます。出国準備5ヶ月前1か月前前日まで随時往路現地復路事後まとめ出国準備やったことは以下のとおりです。5か月前KubeConチケット手配ホテル予約飛行機手配1ヶ月前パスポート取得ESTA申請Visit Japan登録前日まで荷物準備随時英語技術インプット5ヶ月前KubeCon自体のチケット手配はまとめて会社の方でやっていただきました。ホテルと飛行機はKubeCon割引があったのでこれを利用しました。飛行機はUnited航空の乗継便を予約しました。行きは成田=>ダラス=>ソルトレイクシティー、帰りはソルトレイクシティー=>ロサンゼルス=>成田を予約していました。飛行機が往復で26万円、ホテルが12万円でした。なかなかな値段ですね。同僚と1日違いでチケットを買ったら微妙に値段が変わっていた記憶があります。早めの行動大事ですね。ホテルも飛行機も日本語サイトがあったので特に困った記憶がないです。1か月前数年前にパスポートの期限が切れていたので、これを機に再発行しました。東京都庁地下にパスポートセンターがあるので、ここで申請しました。パスポートセンター横に写真屋さんがあるので、証明写真を準備せずに行っても安心です。だいたい1週間で発行されるので、また1週間後に赴くことになります。渡米する際にESTAを申請する必要があります。ここで注意してほしいのは、検索トップやスポンサーサイトとして出てくるサイトはそれっぽい偽物なので騙されないように注意してください。esta.cbp.dhs.govVisit Japanを事前に登録していくことで日本への帰国時にスムーズになりますのでやっておくことをおすすめします。services.digital.go.jp前日までここまででだいたいやらないといけないことは終わってるので、あとは荷造りです。大きな荷物としては手荷物で入る大きさのトランクケースとビジネスリュックサックの2つを持っていきました。それにプラスしてパスポートと財布と携帯を常に携帯するためのサコッシュも持ち込みました。4泊5日暮らせる最低限の服だけ持ち込みました。だいぶコンパクトになったと思います。基本的に外で食べるつもりはあまりなかったので、全日程の夕食を持ち込みました。オートミール、フリーズドライの味噌汁、粉末スープ類、ルイボスティーなど持っていきました。スープ類にオートミールを入れてレンジで温めればなんとかなります。ここで注意しないといけないのはアメリカは動物性成分が含まれているものは持ち込めません。魚介はOKなのでそのあたり注意しましょう。このへんは国によって違います。電子機器に関しては120V対応しているものはそのままアメリカでも使えます。コンセントの形状は日本と同じですがボルト数が違う形になります。先に言ったようにパスポート、財布、携帯はサコッシュに入れて肌身離さないようにしていました。随時英語はほんとにもっとやっておけばよかったなと思いました。Duolingoはずっとやっていましたが、リスニング、スピーキングという観点からは足りないですね。最近だとスピークバディみたいなAI英会話アプリがあるのでそのあたりもっとやり込んでおけばよかったなと後悔してます。あとやったこととしては、CNCFのyoutubeチャネルに大量の過去のKubeConアーカイブがあるのでそれでひたすら耳をならしてました。www.youtube.com往路実を言うとですね。出国する当日朝まで沖縄にいました。出国当日はこんな感じでした。11/7 午前 羽田着11/7 昼 家で荷物最終チェック11/7 夕方成田出発沖縄から帰る飛行機がちゃんと飛んで良かったと心から思います。普通はこんなことしないです。いろいろ重なって仕方なかったのでした。ということで、行きは成田発、デンバー乗り継ぎ、ソルトレイクシティーという行程です。。。。。でした。デンバー行きの飛行機に乗っていて途中で行き先がアンカレッジ(アラスカ州)に変わってることに気が付きます。急病人救護のためにアンカレッジに緊急着陸することになりました。なんやかんやあって無事デンバーには到着するのですが、当然乗継便には間に合わずなので振り返る必要がありました。自分はアンカレッジ出発時点までにかすかな電波を頼りにスマートフォンから振替を行ったのですが、同僚たちは電波がなく何もできなかったので、自動的に翌日の便に振り返られてしまいました。ちょっとそれは困るのですが、この時点ではどうにもならないのでいったんデンバーに到着し入国審査を受けることになりました。正直入国審査はかなり厳しくされるのかなと不安になっていたのですが、案外すんなり通って拍子抜けしました。デンバーの空港にてなんとか本日便で乗り継げないか交渉することになりました。どうやら現状満席の便でもウェイティングリストに入ることでキャンセル待ちに並ぶことができてうまくいけば本日便で行けそうだということがわかりました。Uniteの係員の人がウェイティングリスト登録のためにコマンドプロンプトを駆使してたのが印象的でした。コマンド操作でやるんですねと感心しました。ともあれ、初っ端からトラブルに見舞われましたが拙い英語でもなんとか乗り切ることができました。なんやかんやあって、ソルトレイクシティーまでたどり着くことができました。現地空港からホテルまではLRTで移動しました。TransitというアプリでOne-Wayチケットを購入して乗るみたいでした。チケットをActivateして乗るのですが、QRコード自体はあるのですが、最後まで誰にも見せることなく下車しました。これが信用乗車方式か。。。となりました。会場はめっちゃ広いし、めっちゃ人が多くて、これが本場か、、、と圧倒されました。飲み物はいたるところにありました。コーヒーに困ることはありませんでした。ランチボックスが無料配布されてることに4日目に気が付きました。それまで、毎回ホテルに帰ってオートミールを食べる生活をしていました。毎回ランチに必ずお菓子が含まれているのはアメリカンな文化なのでしょうか。ランチはビーフ、チキン、ベジタリアン、ビーガン、グルテンフリーから選べました。なんというか文化を感じますね。英語に自身なかったので、文字起こしと翻訳をしてくれるSaaSアプリを試してたのですが、いまいち制度が低くてあまり役に立たなかったでした。これもあとから気づいたのですが、ルームごとにQRが貼ってあって、そこにアクセスすると文字起こしと翻訳をしてくれるアプリケーションが用意されていました。今回いたるところで自分の情報弱者ぶりを感じてしまいました。KubeConのセッション自体はYoutubeにすぐ上がるので、その場で頑張りすぎずにあとで復習するのがよいです。ただ、現地でしか体験できない雰囲気を味わえたことはすごく良い経験になりました。現地での日本人交流会ではバリバリKubernetesをつかっている人たちの生の声が聞けて刺激になりました。復路特筆すべきことはないですVisit Japanをあらかじめ登録しておいたので、入国審査と税関はすんなりと通過できました。事後経費採算しっかししましょう。経費採算終わるまでが出張ですまとめ往路がこすぎてソルトレイクシティーについた瞬間もう帰っていいかなという気持ちになりました。トラブルはありつつも一つ一つこなしていけばまあなんとかなるものだなと思いました。英語はほんとにちゃんとやっておきたかったなと言う気持ちが強いです。もっとできてれはもっと実りが多かったなと。当たり前の話ですが、羽田、成田の乗り継ぎはやめたほうが望ましいです。社会人は余裕持った行動をしましょう(?)いろいろもっとうまくやりたかったという気持ちはありつつも本場のでっかいカンファレンスに参加して色んな意味で刺激を受けました。また英語もそうですし、知識レベルを上げて海外カンファレンス再挑戦したいです。来年はre:Invent行たいです!さて、真面目なまとめは同僚が書いてるのでこちらを参照してください。sreake.comそれでは。

初めての海外カンファレンス(KubeCon NA 2024 in Salt Lake City)

社内勉強会で発表したVPC Endpointの説明資料

2025-11-21 社内エンジニア勉強会 改めて理解するVPC Endpoint

11/14に Google Cloudで目指すクラウド二刀流エンジニア講座第3回 に登壇してきました。cloudonair.withgoogle.com第1回でパネルディスカッションに出てきたのに引き続き、今回は Fargate との差分で理解する、Cloud Run のシンプルな魅力 と題して登壇させていただきました。AWSをもうすでに使ってる方向けにECS Fargateと比較しつつCloud Runのシンプルな魅力を紹介するセッションとなっていました。視聴登録すればこちらから動画が見れるかと思います。資料も後ほどこちらに上がると思います。内容としては以下のような話をしました。Cloud Runの概要紹介ECS FargateとCloud Runのアプリケーションアーキテクチャ比較ネットワーク機能の紹介セキュリティ機能の紹介運用監視機能の紹介今回はCloud Runを使ってない人向けに概要紹介するセッションだったので、深入りできていない部分や説明不足、端折ったところがたくさんあります。これについてはどこかでエントリ書きたいと思ってます。とにかくCloud Runはいいぞ!ということが伝わっていれば何よりです。Cloud Runの良さを伝えたつもりですが、あくまでなんでも適材適所でFargateが向いているコンテキストに無理やり変える必要はなく、比較検討できる選択肢の一つとしてCloud Runを入れていただけたらと思います。スライドにもう少し図表を入れた方が伝わったかなとか反省点はありつつも、40分トークは初めてだったのですごくいい経験になりました。今後ももっと大きなところで登壇できるように精進していきます。

Google Cloud で目指す クラウド二刀流エンジニア講座第3回に登壇してきました。

[[IAMスペシャル！]Security-JAWS【第39回】 勉強会 2025年11月08日(土) - connpass](https://s-jaws.connpass.com/event/366395/) の発表資料

2025-11-08 Security JAWS TerraformによるIAM Policy記述ガイド

[3-shake SRE Tech Talk #13 オンサイト - connpass](https://3-shake.connpass.com/event/362683/)でLTした内容。Conftestを軽く試してみた内容。もう少し深堀りして、再度発表したいところ。

2025-09-25 SRETT #13 ConftestによるTerraformのPolicy as Codeを試してみる

この内容は、社内のエンジニア勉強会で話した内容です。 speakerdeck.comみなさん。プロダクション環境のシークレット情報をどう扱っていますか?クラウドネイティブなアプリケーション開発において、DBのパスワードや外部APIキーといったシークレットの管理は、セキュリティを確保する上で避けては通れない課題です。この記事では、アプリケーションとインフラそれぞれの視点から、クラウド環境におけるシークレット管理のアンチパターンとベストプラクティスを探っていきます。ここで言うシークレットとはDBのパスワードやAPIキーなどの秘匿すべき情報のことを指します。アプリケーション側の視点まずは、アプリケーションがどのようにシークレットを扱うべきかを見ていきましょう。管理のアンチパターン最初に管理方法のアンチパターンとしては以下のものがありますソースコードに直接記述設定ファイルに平文で記述環境変数に平文で記述(Dockerfileや.envファイルでgit管理するなど)base64エンコードして保存ソースコードに記述すれば、すべての環境で同じ値しか使えず柔軟性がありません。設定ファイルや環境変数に平文で記述し、それをGitで管理してしまうと、何かのミスでリポジトリが流出した際にシークレットも漏れてしまいます。また、隠しているつもりでBase64エンコードするのも同様に危険です。Base64は暗号化ではなく、誰でも簡単に元の文字列に戻せるため、平文で保存しているのと大差ありません。KMSによる暗号化の検討次に考えられるのが、暗号鍵を使った暗号化です。AWSのKMSやGoogle CloudのCloud KMSといった鍵管理サービスを利用する方法が考えられます。フローとしては以下のようになりますでしょうかアプリケーション起動時にKMSのから鍵を取得取得した鍵を利用して暗号化されたシークレットを復号平文のシークレット情報をアプリで利用する一見これで良さそうですが、復号処理をアプリケーションの責務にすると、コードが複雑になるだけでなく、KMSの復号権限をアプリケーション自体に付与する必要があり、管理の懸念点が増えてしまいます。クラウド側のシークレットストアの利用そこで推奨されるのが、クラウドが提供するシークレット管理の仕組みを利用することです。AWSAWS Secrets ManagerAWS Systems Manager Parameter Store(SecureString)Google CloudSecret Managerこれらのサービスは、ECS FargateやCloud Runなどのコンテナ実行環境と統合されています。コンテナの起動時に、これらのストアに保存されたシークレットを、自動的に環境変数やファイルとしてマウントしてくれるのです。これによりアプリケーション側では、シークレットがどこで管理されているかを意識することなく、従来通り環境変数やファイルから値を読み込むだけで済むようになり、責務をシンプルに保つことができます。インフラ側の視点さて、アプリケーションの課題は解決しました。次に、インフラ側で、そのシークレットストアをどう管理するかという課題に移りましょう。取れる手段としては主に以下ものが考えられます。手動でコンソールから設定シークレットの値を平文でIaC管理(tfvarsファイルをgit管理から外す)シークレットの値を暗号化してIaCで管理シークレットストアをIaCで管理、値は手動設定まず手動で管理ですが、これはこれでありだと思ってます。ただし、扱うシークレットの数が増えてきたときに作業が煩雑であったり、手作業がゆえに起こるリソースタグなどの付け間違いなどのミスが発生しうるので、規模が大きくなると現実的ではありません。2つ目ですが、シークレットの値だけあつかるtfvarsファイルをgitignoreしてあげることでレポジトリが漏れてもシークレットの値が漏れないことになります。が、うっかりシークレットの値を人為的なミスでコミットしうるので完全に安全とはいいにくいです。3つ目ですが、これはsops providerを利用するパターンです。これを使うことでKMSキーを利用して暗号/復号がterraformとシームレスに統合できます。一見これで良さそうですが、2点課題があります。KMSリソースを余計に管理なくてはならないStateには平文で保存される前者は必要経費としていいとして、後者は課題となります。Terraformにおいてはstateを見る権限がある人にはシークレットも見れてしまうという懸念があります。シークレットのリソースと値を分離するこの方法の利点は、IaCでシークレット リソースが存在することは管理しつつ、その実際の値はGitの管理下から完全に分離できる点です。初回適用後にコンソールから実際のシークレット値を設定すれば、それ以降 terraform apply を実行しても値がダミー値で上書きされることはありません。これにより、コードレビューなどで誤ってシークレットが漏洩するリスクを原理的に防ぐことができ、非常にバランスの取れた管理方法と言えます。以下サンプルコードです。resource "aws_ssm_parameter" "db_password" {  type     = "SecureString"  name     = "/test/db_password"  value    =  "Dummy"  lifecycle {    ignore_changes = [value]  }}まとめ現時点でのクラウドにおけるシークレット管理のベストプラクティスは、以下のようにまとめることができるでしょう。アプリケーションクラウドのシークレットストア(Secrets Managerなど)と実行環境(ECS, Cloud Runなど)の統合機能を使い、環境変数またはファイルとしてシークレットを読み込む。インフラ(IaC)クラウドのシークレットストアのリソース自体はTerraformで管理する。実際のシークレットの値は ignore_changes を活用して手動で設定し、Gitの管理から分離する。もちろん要件によって取りうる手段は変わるとは思います。他になにか良い方法をご存知でしたら教えて下さい。それでは良いシークレットライフを!関連ページblog.masasuzu.net

クラウド環境におけるシークレットの扱い

スリーシェイク社内のエンジニア勉強会で発表した資料クラウドにおいてプロダクション環境でのシークレットの扱い方についてアプリケーションおよびインフラ側でどう管理していくのが望ましいかを詳解

2025-09-19 クラウドにおけるシークレット管理

2025-08-05 Google Cloud Next Tokyo 2025 Cloud RunとCloud SQLの接続方式と事例

先日、2025年6月4日に開催された 「Google Cloud で目指すクラウド二刀流エンジニア講座」 の第1回にて、「スペシャリストが語る！Google Cloud のメリットを活かすネットワーク、セキュリティのあり方とは？」 と題したパネルディスカッションに登壇いたしました。イベントから少し時間が経ちましたが、当日の内容を振り返り、話したことや、時間の都合上話しきれなかった点などをまとめていきたいと思います。cloudonair.withgoogle.comページとセッションでの資料は以下のとおりです。Session 3 : スペシャリストが語る！Google Cloud のメリットを活かすネットワーク、セキュリティのあり方とは？Session 3 : スペシャリストが語る！Google Cloud のメリットを活かすネットワーク、セキュリティのあり方とは？(スライド)以下パネルディスカッションでお話しした内容と補足を記載します。Question 1 :現在のハイブリッドクラウド構成時のトレンドとお客様が気にされるポイント大規模なシステムではオンプレミスとクラウドを組み合わせたハイブリッド構成を、中規模以下のシステムではオンプレミスからクラウドへ完全に移行する、あるいは最初からクラウドで構築する「クラウドネイティブ」な構成が多い傾向にあります。可用性向上のために、同じサービスをマルチクラウドで構築するケースは少なく、まずは単一クラウド内でのマルチリージョン構成が検討されることが多い印象です。しかし、私が担当するサービスではマルチリージョンが必要なほどクリティカルなものはそれほど多くなく、多くは単一リージョン内のマルチAZ(ゾーン)構成を採用しています。冗長性が目的ではなく、特定の機能を使いたいので一部のサービス（例: 特にBigQuery、Vertex AI）のみをGoogle Cloudで利用するケースがあります。メインクラウドがどちらかに偏っており、Google Cloudを補完的に利用するケースが多いようです。また、可用性向上という目的とは別に、特定の機能（特にBigQueryやVertex AIなど）を利用するために、一部のサービスのみGoogle Cloudを補完的に利用する、というケースでマルチクラウドを使用してる例が多いです。お客様が特に重視されるポイントとしては、コスト、セキュリティ、そして可用性の担保が挙げられます。Question 2 :クラウドのネットワーク設計、セキュリティ実装において押さえておくべきポイント最適な設計や実装は、お客様の組織体制やチーム体制、そして運用するサービスの性質によって大きく変わります。そのため、まずはどのような運用体制を目指すのかを分析・定義し、それに合った構成を提案することが重要です。考慮すべき観点としては、以下のような点が挙げられます。フォルダやプロジェクトの構成可用性の取り方過剰な可用性を求めていないか、サービスの要件と合っているかセキュリティの要求ネットワーク構成そして何よりも、設計した構成が、実際のチームで「運用可能」であることが最も重要だと考えています。Question 3 :ネットワーク、セキュリティの課題とアプローチここでは、ネットワークの課題を解決した事例を一つご紹介します。Cloud Run、MemoryStore (Redis)、Cloud SQLで構成されたアプリケーションで、Cloud RunとCloud SQL間のネットワーク性能が上がらないという問題が発生しました。Cloud RunはVPCの外部にあるリソースのため、VPC内にあるCloud SQLと接続するにはServerless VPC Connectorを経由していました。調査の結果、性能が出ない原因は、このServerless VPC Connectorのインスタンス数を固定で設定していたことでした。一時的な対処として、Serverless VPC Connectorの最大インスタンス数とインスタンスタイプを引き上げました。このサービスはサーバーレスという名前ですが、実際にはインスタンス数やタイプを指定する必要があります。(ここで言うサーバレスは、サーバレスなリソースへのコネクタという意です)しかし、この対処法では課題が残ります。Serverless VPC Connectorは一度スケールアウトすると自動でスケールインしないため、ピーク時に合わせたインスタンス数のコストを常に払い続けることになってしまいます。そこで根本的な解決策として、Direct VPC Egressへの移行を実施しました。Direct VPC Egressは、パフォーマンスが高く、コストもネットワーク転送料金のみに抑えられるというメリットがあります。ただし、VPCに直接接続するため、使用するIPアドレス数が多くなる点には注意が必要です。この事例では、Cloud Runのデプロイ設定でコネクタを切り替えるだけだったため、移行は比較的スムーズでした。また、インフラがコード化(IaC)されていたため、何か問題があってもすぐに切り戻しができる状態だったことも成功の要因です。この経験から言えるのは、本番稼働しているネットワークの変更は容易ではないということです。そのため、初期設計は慎重に行う必要があります。とはいえ、サービスの成長に伴う構成変更は避けられません。将来の変更を見越して、変更しやすい設計を心がけ、変更を安全に試せる環境を準備しておくことが重要です。具体的には、インフラを可能な限りIaC化して変更や切り戻しを容易にすること、検証環境をすぐに構築できるよう準備しておくこと、そして何よりも 現在のチームメンバーで運用できる方法を選択すること が大切です。チームのスキルレベルや人数、体制を考慮した現実的なアプローチを常に考えていく必要があります。(この事例の話、若干ずれてて長くなってしまった感があります。反省)Question 4 :Google Cloud のネットワーク・セキュリティ領域でのおすすめのサービス・機能ここでは3つのサービスをあげさせてもらいました。IAP限定公開の Google アクセス共有VPCIAPアプリケーションにGoogle認証を簡単に追加できる非常に便利なサービスです。最近、ALBなしでCloud Runに直接設定できるようになりました(プレビュー機能)。ただし、ALBを利用する場合と異なり、Cloud ArmorによるWAF保護が適用できないため、ユースケースに応じた注意が必要です。限定公開の Google アクセス通常、Compute EngineなどのリソースからGoogle系のAPI（Cloud Storageなど）にアクセスするには、外部IPアドレスを持つか、Cloud NATなどを経由する必要がありました。しかし、サブネットでこの「限定公開のGoogleアクセス」を有効にすると、追加費用なしで、外部IPを持たないリソースから直接Google APIにアクセスできるようになります。AWSではVPC EndpointをAPIごとに作成する必要があり、管理が煩雑でコストもかかりますが、Google Cloudではこの機能によって非常にシンプルかつ低コストにプライベートなアクセスが実現できます。共有 VPC(Shared VPC)誰にでもおすすめできるわけではありませんが、特定の要件には非常に有効な機能です。共有VPCを利用すると、ネットワークとセキュリティの管理をインフラチームに集約し、各サービス開発チームは払い出されたサブネット上で開発に専念する、といった職掌の分離が可能になります。これにより、開発チームはインフラを意識することなくアプリケーション開発に集中できます。一つの大規模なシステムを複数のチームで開発する場合や、複数のプロジェクトでVPC上のリソースを共有したい場合に特に便利です。一方で、ネットワークの独立性が失われるため、ファイアウォールの設定をより厳密に行う必要があります。また、開発チームがネットワーク設定を直接変更できないため、変更の都度インフラチームへの依頼が必要になるというデメリットもあります。Question 5 :おすすめのクラウドのネットワーク、セキュリティのベストプラクティスのキャッチアップ方法セキュリティ分野に限りませんが、日々の情報収集が重要です。私のチームでは、Google CloudのリリースノートやAWSのアップデート情報を定期的に確認する会を社内で実施し、効率的に新しい情報をキャッチアップしています。また、資格試験の勉強や更新も、知識を体系的にアップデートする良い機会になります。コミュニティや勉強会イベントへの参加も非常に有効です。Google Cloud関連では、主に以下の2つのコミュニティが活発です。Jagu’e’r (Japan Google Cloud Usergroup for Enterprise)GCPUG(Google Cloud Platform User Group)Jagu'e'rは、ユーザー企業とパートナー企業の従業員で構成されるコミュニティで、各分科会での活動が活発です。私自身もクラウドネイティブ分科会の運営に携わっています。GCPUGは、特にShonan支部が活発に活動されている印象です。他の支部は活動が緩やかになっている面もありますが、Slackワークスペースは現在も動いており、各サービスのチャンネルでは最新アップデートに関する議論が行われています。まとめ今回、初めてパネルディスカッションという形式で登壇させていただきました。至らない点も多々ありましたが、大変貴重な経験となりました。技術に関する議論はやはり楽しいと感じました。今後もこのような機会があれば、ぜひ参加していきたいです。

Google Cloud で目指す クラウド二刀流エンジニア講座 第1回 でパネルディスカッションに出てきました。

2025-06-20 PrivateLinkがNLBなしで作れるようになり便利になった

この記事はSRETT #11で発表されたものに加筆修正したものです。OpenTofuに関して調べたこととなります。3-shake SRE Tech Talk #11 オンサイト - connpass speakerdeck.com先日KubeCon + CloudNativeCon North America 2024に行ってきてました。その中で共同開催されていたOpenTofu Dayを見てOpenTofuに関して興味を持ちました。普段はTerraformを利用しており、あまりOpenTofuについては触ってきてないので、この機会に深堀りをしてみたいと思いました。参考: OpenTofu Dayまた、社内活動として技術検証を行っており、私の検証テーマとしてTerraformを中心としたIaC周りの技術調査を行ってるので、ちょうどいい機会だとも思いました。おことわりOpenTofuとはライセンス問題HashiCorp社の言い分コミュニティの懸念OpenTofuとTerraformの違いコマンドファイルRegistryremovedブロックState Encryptionbackendブロックの変数参照バージョン管理Security checkLinterCI/CDまとめ参考リンクライセンス変更フォークソースコード問題OpenTofuを使うためにHachiCorp買収おことわりこの記事はTerraformを知っている前提で書かれています。そのため細かい説明を省略している箇所があります。また筆者は普段はTerraformをメインで使用しており、OpenTofuを業務利用はしていません。OpenTofuとは2023年8月にTerraformを含めたHashiCorp製品のライセンスの変更を発表したことにより、これを懸念した企業やコミュニティによりOpenTFとしてフォークされます。その後OpenTFの名称はHashiCorp社の商標権への懸念からOpenTofuに改名されます。そのときの議論はissueを見るとたどることができます。参考: https://github.com/opentofu/opentofu/issues/2962023年9月にLinux Foundation傘下となります。参考: Linux Foundation Launches OpenTofu: A New Open Source Alternative to TerraformTerraformをフォークしたものなので基本的な使い勝手は同じです。コマンド名が terraform から  tofu に差し替えられています。ライセンス問題前項でさらっとライセンス変更と言いましたが、HashiCorp社は2023年8月に今後のリリースに関してライセンスを変更する旨を発表しました。これはオープンソースライセンスであるMozilla Public License（MPL） v2.0から商用サービスでの利用を制限するBusiness Source License（BUSLあるいはBSL） v1.1に変更するものです。参考: HashiCorp adopts Business Source Licenseこれに対して、利用企業およびコミュニティが懸念を示し、OpenTofuをフォークしたという流れになります。HashiCorp社の言い分従来BSLは本番使用(production use)が制限されます。ただし、ライセンスのParameterとして追加使用許可(Additional Use Grant)をすることによりTerraformと「競合製品」でなければ本番利用の制限はないとしてます。参考: https://github.com/hashicorp/terraform/blob/v1.11/LICENSE「競合製品」とは、有料サポート契約を含む第三者に販売される製品で、HashiCorp のライセンス対象製品の有料版の機能と大幅に重複する製品を指します。TerraformでいうところのHCP Terraform(Terraform Cloud)を想定しているのかと思います。また組織内でTerraformをホストして利用することは「競合製品」とはみなされなません。そのため利用者としては基本的には問題なく利用できるとしてます。参考: HashiCorp Licensing FAQ問題となるのはTerraformの機能を有償で提供しているSaaSと読み取れます。コミュニティの懸念HashiCorp社が説明したBSLと追加使用許可はあいまいであるとしてます。そのため、自身の行動が許諾範囲内か判断が困難である。「競合製品」の定義やライセンス自体が今後変更されるか不確実であると懸念を示してます。また、TerraformはOSSの恩恵を受けて成長してきてため、これからもオープンソースソフトウェアであるべきだと信じていると表明しています。参考: OpenTofu FAQOpenTofuのスポンサー企業としては以下のとおりです。HarnessGruntworkSpaceliftenv0ScalrHarnessはCI/CDまわりのSaaS製品、Gruntworksはterragruntの開発元、Specelift、env0、ScalrはTerraformをホストするSaaSサービスを運営しています。OpenTofuとTerraformの違いこの項ではそれぞれの違いについて説明していきます。OpenTofuはTerraform1.6-alphaからフォークされているのでそれまでに実装されていたものは互換があります。また、Terraform 1.6以降に追加された機能に関しても随時取り込まれています。そのため、1.5までの機能を使っているのであれば素直に移行できるかとは思います。バージョンごとに移行ガイドがあるので細かくはそれを参照すると良いです。参考: https://opentofu.org/docs/intro/migration/ただし、別のコードベースで開発がされているので、OpenTofuのみの独自実装もあります。ここではいくつか個人的に気になる違いについてあげていきます。コマンド基本的には terraform を tofuに置き換えていただければよいです。サブコマンドは一緒です。# Terraformterraform initterraform planterraform applyterraform destroy# OpenTofutofu inittofu plantofu applytofu destroyファイルterraform由来の .tf または .tofu の拡張子のファイルを設定ファイルとして認識します。json形式の .tf.json または .tofu.json の拡張子のファイルも同様です。同じディレクトリ内に.tf と .tofu の両方のファイルがあった場合、.tofu ファイルだけ認識して、.tf ファイルは無視されます。foo.tf  # <=== このファイルは無視されるfoo.tofuRegistryTerraform同様OpenTofuにもプロバイダーやモジュールのレジストリがあります。Terraform: https://registry.terraform.io/OpenTofu: https://registry.opentofu.orgOpenTofu Registryが登場したときに存在したTerraform Providerは反映されています。反映されていないものに関してもissueを立てれば反映されるようですhttps://github.com/opentofu/registryremovedブロックremovedブロックは既存のリソースを削除することなく、stateから削除することができます。それぞれ下記のように記述できます。下記の例ではAWSインスタンス自体は削除せず、stateから外すことを意図してます。# Terraformremoved {  from = aws_instance.example  lifecycle {    destroy = false  }}# OpenTofuremoved {  from = aws_instance.example}Terraformではlifecyleブロックでdestroy=falseの記述が必須です。参考: https://developer.hashicorp.com/terraform/language/resources/syntax#removing-resourcesOpenTofuではremovedブロックを書くだけで stateから削除されます。参考: https://opentofu.org/docs/language/resources/syntax/#removing-resourcesremovedブロックでやりたいことはstateから削除することなので、単純にリソースを削除したいなら対象resouceブロックを削除すればいいので、Terraformの記述方法のほうがへんな気がします。State EncryptionTerraformでは平文でStateに保存されてしまうという問題がありましたが、OpenTofuではクライアントサイドで暗号化する機能が追加されてます。クラウドプロバイダーの KMSキーなどを利用してStateを暗号化することができます。参考: State and Plan Encryption | OpenTofuTerraformではたとえsopsプロバイダーで機密情報を暗号化しても、Stateファイルには平文で保存されているので権限があれば機密情報が見えてしまう状態にありました。State自体が暗号化されることにより機密情報をよりセキュアに扱えるようになります。参考: Terraformのsopsプロバイダーを使用するだけで機密情報は守られるのか - 目の前に僕らの道があるbackendブロックの変数参照OpenTofuではbackendブロックで変数参照ができます参考: https://opentofu.org/docs/language/settings/backends/configuration/#variables-and-localsvariable "env" {  type    = string}locals {  path = "${var.env}/terraform.tfstate"}terraform {  backend "local" {    path = local.path  }}tofu init -var="env=dev" -reconfiguretofu plan -var="env=dev"Terraformで同じことをしたい場合、-backend-configを渡さないといけないため、backendを切り替える際に不便となります。terraform init -backend-config=./envs/dev/terraform.backend -reconfigureterraform plan -vars-file=./envs/dev/terraform.tfvarsOpenTofu DayのLTで紹介されてた環境名だけを渡して挙動を切り替えるパターンが現状だとterraformでは使えません参考:On Best Practices with OpenTofu Structuringバージョン管理複数プロジェクトでTerraform or OpenTofuを使う場合、プロジェクトごとに使用バージョンを管理する必要があります。いくつか選択肢を見ていきます。Terraformのバージョン管理ツールとしてよく使われるtfenvはOpenTofuには対応しません。参考:https://github.com/tfutils/tfenv/issues/409代わりにTerraformとOpenTofuに対応したtenvができました。こちらを利用すると良さそうです。https://github.com/tofuutils/tenv私はTerraformも合わせてプロジェクト内のツールのバージョン管理をまとめてasdfでやってますが、こちらは対応しています。https://github.com/virtualroot/asdf-opentofu自分はあまり使わないのですが、同じようなツールのaquaやmiseも両対応しています。https://aquaproj.github.io/https://github.com/jdx/miseSecurity checkTerraformだとtfsec(現 trivy config)がセキュリティチェックとして使われてるかと思います。ディスカッションはされており優先順位をつけて対応するとのことです。参考: https://github.com/aquasecurity/trivy/discussions/5069LintertflintはOpenTofuをサポートしないようです。参考: https://github.com/terraform-linters/tflint/issues/2037Linterの議論自体はissueで続いているようです。参考: https://github.com/opentofu/opentofu/issues/2213CI/CDHCP Terraform(旧Terraform Cloud)に相当するSaaSとしては、OpenTofuスポンサーのSpacelift、env0、Scalrなどがあります。tfactions、atlantis、diggerもOpenTofuに対応している模様です。まとめ現時点でOpenTofuに移行するするべきか?の問については、利用者側として現状では引き続き様子見かと思います。足回りも概ね揃ってきているが、まだ足りないエコシステムもあります。気になるところではIBM社にHashiCorp社の買収による統合完了の様子も追っていきたいところです。予定では2025年の1-3月期に統合完了するとのことなので、その後なにか動きがあるかもしれません。参考: IBM社によるHashiCorp社買収についてとはいえ、1つのツールが使えなくなることで業務が止まるのは避けたいので常に選択肢は複数取っておきたいところです。エンジニアとしてはOpenTofuに限らず、Pulumi、CDK(AWS)なども選択肢として取っておきたいです。それはそれとして、OpenTofuはTerraformとは違う独自進化をしているので、変更を追っていきたいところです。個人的にはState暗号化とかBackendの変数参照とかTerraformに入ってほしいです。それでは良い豆腐ライフを!、、、。ここまで書いてきたのですが、minamijoyoさんのTerraform職人のためのOpenTofu再入門2024がものすごく詳しいので、この記事以上に参考になるかと思います。参考リンクライセンス変更HashiCorp adopts Business Source LicenseHashiCorp | The Infrastructure Cloud CompanyHashiCorp、全製品のライセンスを商用利用に制限があるBSLライセンスに変更すると発表 － PublickeyTerraformのライセンスの変更とその影響何故、TerraformのBUSL-1.1へのライセンス変更は反発を受けたのか？ – Shuji SadoTerraform のライセンス変更についての考察 #Azure - QiitaフォークTerraformのフォークが「OpenTofu」としてLinux Foundation傘下で正式ローンチ。OpenTFから改名 － Publickeyソースコード問題【Infostand海外ITトピックス】ライセンスをめぐって対立　HashiCorpと「Terraform」派生のOpenTofu - クラウド WatchHashiCorp、TerraformをフォークしたOpenTofuに対しコードの不正コピーを警告。OpenTofuは完全否定 － PublickeyOpenTofuを使うためにTerraform職人のためのOpenTofu再入門2024 #Terraform - QiitaTerraform職人のためのOpenTofu入門 #Terraform - QiitaOpenTofuopentofu/opentofu: OpenTofu lets you declaratively manage your cloud infrastructure.Migrating to OpenTofu 1.7.x from Terraform | OpenTofuHachiCorp買収IBMがHashiCorpを64億ドルで買収、TerraformとAnsibleのシナジー効果などを見込む | IT LeadersIBM Japan Newsroom - ニュースリリースIBM社によるHashiCorp社買収について

Terraform使いがOpenTofuについて入門してみる

KubeCon NA 2024に行ってきたのでその経験を話します。吉祥寺.pm 37で話しました。https://kichijojipm.connpass.com/event/339040/

2025-01-31 吉祥寺.pm 37 初めての海外カンファレンス

OpenTofuについて調べてみた内容SRETT #11 https://3-shake.connpass.com/event/339212/

2025-01-24-SRETT11-OpenTofuについてそろそろ調べてみるか

この記事は3-shake Advent Calendar 2024の22日目の記事です。AWS Signerを使ったコンテナイメージの署名処理を扱った案件があったのでこちらの紹介となります。ただ、後述するように完成には至ってないです。それでもAWS Signerを使った署名処理と署名検証についての概要をお伝えできるかなと思います。今回のシステムはAWS ECS で Web サービスを運用しています。GitHub Actions を利用してデプロイを行っています。構成としては至ってベーシックな形になっています。今回、コンテナイメージのセキュリティ強化のため、ECR に保存されているイメージが改竄されていないことを保証する要件が追加されました。この記事では、AWS Signer を用いたコンテナイメージの署名と検証の実装、そして現状の課題と今後について記述します。AWS SignerとはWhat is AWS Signer? - AWS SignerAWS Signer はフルマネージドなコード署名サービスです。従来は Lambda 関数などで利用されていましたが、2023年の6月にECRのイメージ署名にも対応しました。AWS がコンテナイメージへの署名を導入Notary ProjectのNotation CLIを用いることで、ECRに保存されているコンテナイメージを署名することができ、署名ファイルをコンテナイメージとともにECRに保存できます。これによりコンテナイメージの真正性と完全性を検証することができます。ECS × AWS Signer を使ったイメージ署名ワークフローを試してみた - Speaker Deckなお、AWS Signerによるイメージ署名に゙関してはNRI ネットコム様のスライドに詳しく書かれているのでこちらを参照するとより理解が深まります。デプロイフロー変更前デプロイフローとしてはGitHub Actionsでレポジトリ内のソースをdocker buildしたものをECRにpushし、ECS Serviceにデプロイするシンプルなワークフローになります。変更前変更後このワークフローにコンテナイメージ署名の処理を追加します。notationコマンドにSigner Profileのarnを指定して、署名と検証をそれぞれ行う形になります。今回は、GitHub Actions ワークフローに AWS Signer を使った処理を組み込みます。ECRにpushしたイメージに対して署名を行うように変更しました。署名したあとに署名検証を行うことになります。後述しますが、これだけだと本来は不完全なものです。変更後実装ここから実装を見て行きます。先述したワークフローに帰るために以下の変更が必要となります。インフラ側AWS Signer Profileの追加デプロイ用IAM RoleにAWS Signer Profileへのアクセス権の追加デプロイ側署名処理の追加Terraformインフラ側の変更を見ていきましょう。追加箇所としてはSigner Profileの追加とGitHub Actions用のIAM Policyへの権限追加となります。変更箇所以外は今回は割愛しています。platform_idを"Notation-OCI-SHA384-ECDSA"に指定してSigner Profileを作成します。レポジトリ名をProfile名にしており、レポジトリ名が - 区切りで、Profile名が - を使えないという事情で _ への置換処理をしています。Siner Profileresource "aws_signer_signing_profile" "main" {  platform_id = "Notation-OCI-SHA384-ECDSA"  # profile名に-が使えないので置換  name = replace(var.repository_name, "-", "_")}先に作ったSigner Profileへの"signer:GetSigningProfile"と"signer:SignPayload"の許可をデプロイ用のRoleのPolicyに付与します。GitHub Actions用IAM Roledata "aws_iam_policy_document" "deploy_policy" {  #前略  # イメージ署名  # Inline policies for Signer - AWS Signer  # https://docs.aws.amazon.com/ja_jp/signer/latest/developerguide/authen-inlinepolicies.html  statement {    sid    = "SignImage"    effect = "Allow"    actions = [      "signer:GetSigningProfile",      "signer:SignPayload"    ]    resources = [      var.signer_profile_arn    ]  }  # 後略}デプロイsigner policyのファイルをあらかじめ作っておきます。このPolicyを利用して、署名検証を行います。.github/aws/signer_policy.json{    "version":"1.0",    "trustPolicies":[      {          "name":"aws-signer-tp",          "registryScopes":[            "*"          ],          "signatureVerification":{            "level":"strict"          },          "trustStores":[            "signingAuthority:aws-signer-ts"          ],          "trustedIdentities":[            "arn:aws:signer:${region}:${account_id}:/signing-profiles/${profile_name}"          ]      }    ]}既存のECSのデプロイワークフローにnotationのインストール、イメージ署名処理、イメージ署名検証の処理を追記します。リリースブランチにpushされたことを契機にデプロイが走る形です。.github/workflows/deploy.yamlname: Deploy to ECSon:  push:    branches: ['release']env:  AWS_REGION: ap-northeast-1  ECR_REPOSITORY: ${レポジトリ名}  SIGNER_PROFILE_ARN: ${Signer Profile ARN}  SIGNER_POLICY_JSON: .github/aws/signer_policy.jsonjobs:  deploy:    name: Deploy to ECR, ECS    runs-on: ubuntu-latest    steps:      ### 前略      - name: Setup Notation        run: |          wget https://d2hvyiie56hcat.cloudfront.net/linux/amd64/installer/deb/latest/aws-signer-notation-cli_amd64.deb          sudo dpkg -i aws-signer-notation-cli_amd64.deb      - name: Sign image        env:          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}          IMAGE_TAG: ${{ github.sha }}        run: |          notation sign $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG --plugin "com.amazonaws.signer.notation.plugin" --id "$SIGNER_PROFILE_ARN"      - name: Verify image        env:          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}          IMAGE_TAG: ${{ github.sha }}        run: |          notation policy import $SIGNER_POLICY_JSON          notation verify $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG      ### 後略課題ここまででイメージの署名処理および署名検証の実装はできました。しかしながら、いくつか課題があります。CIとCDの分離先の実装を見るとわかるのですが、署名したイメージを即時署名検証していることがわかります。これは同じイメージに対して行われているため、実質的な検証にはなっていません。真の改竄検知のためには、CI/CD パイプラインを分離し、デプロイ時に別途署名検証を行う必要があります。また、pushしたコンテナイメージの脆弱性チェックもデプロイ前に行うことが望ましいです。そこで下記のように変更したいところです。ただ、デプロイのフローが変わってしまうので、調整が必要でまだ手をつけていない状態になります。理想正規手順以外でデプロイされたイメージの検証さらに、正規のデプロイフロー以外で起動されたタスクのイメージ検証も課題です。署名されていないイメージが起動されていても何もチェックができていない状態です。これに対するアプローチとしては、EventBridgeでタスクが起動したイベントを拾って、イメージの署名をチェックし、検証できなかったものに゙関しては処理を行う(タスクの停止や通知など)という方法があります。これはContainers on AWSで紹介されているので、この方法を実装できたらと考えています。Container image signing and verification using AWS Signer for Amazon ECS and AWS Fargate | Containers on AWS署名検証のサービス統合ここまで見ていて気付いたかもしれませんが、ECS Serviceがタスクを起動するときに署名されているかどうかをチェックするようにECSサービスと統合されていれば、独自に署名検証を実装する必要はありません。このへん、Google CloudのBinary Authorizationはサービスと統合されているので、署名検証を自前で書く必要がないと理解してます。AWSもサービスと統合して楽に使えるようになることを期待してます。Binary Authorization の概要  |  Google Cloudまとめ現状でできていることは以下のとおりです。ECRへpushしたイメージの署名処理現状課題となっているものは以下のとおりです。CI/CDの分離署名されていないコンテナイメージが起動されていないかのチェックこの記事では、AWS Signer を用いたコンテナイメージの署名実装と、残された課題について説明しました。まだできていないことが多いですが、まずビルドしたイメージに対して署名を行うという第一歩を踏み出しました。ここから署名検証の仕組みを強化し、よりセキュアなコンテナ運用を実現するために、引き続き改善に取り組んでいきたいと思ってます。参考リンクAWS がコンテナイメージへの署名を導入AWS Signer と Amazon EKS におけるコンテナイメージ署名の提供開始 | Amazon Web Services ブログECS × AWS Signer を使ったイメージ署名ワークフローを試してみた - Speaker DeckSign container images in Signer - AWS SignerContainer image signing and verification using AWS Signer for Amazon ECS and AWS Fargate | Containers on AWSBinary Authorization の概要  |  Google Cloud

AWS Signerにおけるコンテナ署名の実装

この記事はJagu'e'r Advent Calendar 2024の8日目の記事です。日付的には大遅刻です。特に技術的な話はしません。思い出話とこれからの意気込みを書きます。Jagu'e'r(Japan Google Cloud Usergroup for Enterprise) は、Google Cloudのユーザー企業やパートナー企業が集まるユーザー会です。私はパートナー企業であるスリーシェイクに所属し、Jagu'e'rに参加しています。実は入会自体は結構前で、メールを遡ると2023年8月10日でした。当時Google Cloudに関わる案件が始まり、情報収集のために登録した記憶があります。しかし、「Enterprise」や「分科会」といった言葉から、何となく堅苦しいイメージを抱いてしまい、Slackには入ったものの、あまり活動には参加していませんでした。転機が訪れたのは、今年2024年の春から夏頃のこと。同僚が分科会の運営に入り、別の同僚もJagu'e'rのMeetupで発表するようになったんです。身近な人が関わるようになると、自然と興味が湧いてきて、今年の後半はオンライン・オフライン問わず、Meetupに参加するようになりました。そして先日、Jagu'e'r Park '24 Winter!に参加しました。そこで行われたJagu'e'r Award選出のためのピッチ発表に、私は深く感銘を受けました。どの発表者の方も、Jagu'e'rコミュニティへの熱い思いや感謝の気持ちが溢れていて、本当に心を動かされました。特に、中外製薬の方とDatadogの方のピッチは強く印象に残っています。これまでJagu'e'rコミュニティに深く関わってきませんでしたが、こんなにも熱い思いを持つ人たちと一緒に活動したい！という気持ちが湧き上がってきました。「善は急げ」と、ピッチを聞いたその場で、社内でJagu'e'rの分科会運営に携わっている人に連絡を取り、運営を手伝えないか相談しました。さらに懇親会では、弊社担当のGoogle Cloudパートナーエンジニアの方にも相談し、同じ分科会の運営の方につなげてもらいました。問題がなければ、来年から某分科会の運営に携わる予定です。正直なところ、勢いで走り出した部分もあるので、まだ何ができるか、何をしていきたいかは漠然としています。それでも、来年はコミュニティの活性化に貢献できるような成果を残せるよう、精一杯頑張りたいと思っています。

私とJagu'e'rと2025年から...

ECSのタグ付け認可とはアカウント単位のオプトアウトの廃止確認影響がある例対応まとめ関連リソースECSのタグ付け認可とはECS関連のリソース作成時にリソースタグを付けることができます。その際 ecs:tagResource の権限が必要となります。なお、リソースタグを設定しないECSリソース作成の際は権限不要です。この権限の有無のチェックをタグ付け認可と言います。具体的にECSリソースの作成のアクションは以下の通りです。CreateCapacityProviderCreateClusterCreateServiceCreateTaskSetRegisterContainerInstanceRegisterTaskDefinitionRunTaskStartTaskタグ付け認可の仕組みは2023年4月18日に導入されました。しかしながら従来からECSリソースを作成する際にタグ付けしていたAWSアカウントに関しては影響があるため、アカウントレベルでタグ付け認可の機能を無効(オプトアウト)することができました。つまりアカウントレベルで無効にしていれば ecs:tagResource の権限がなくてもタグ付けをすることが可能でした。しかしながらアカウント単位のオプトアウト設定は2024年3月9日に廃止されます。アカウント単位のオプトアウトの廃止タグ付け認可におけるタイムラインは以下のとおりです2023年4月18日 タグ付け認可の導入とアカウント単位での有効化設定の導入2024年2月9日- 2月28日 新規アカウントおよび影響を受けないアカウントに関してデフォルトでタグ付け認可の有効化が行われる2024年2月29日 アカウント単位で有効にしている場合、無効に変更できなくなる2024年3月29日 すべてのアカウントでタグ付け認可が有効になり、アカウント単位での設定が不可能になる現時点(2024/03/20)であまり時間がありません。現在タグ付け認可に影響あるAWSアカウントに関しては、Personal Health Dashboadに以下のような通知が来ているはずです。▼ElasticContainerService security notification (クリックで展開)▼English follows Japanese | 英語のメッセージは日本語の後にございますお客様のアカウントにて過去 1 年以内に ecs:TagResource の許可無しに ECS リソースの作成時にタグを付けていることが判明したため、ご連絡差し上げます。Amazon ECS は、2023 年 4 月 18 日にリソース作成のタグ付け認証を導入しました [1]。新規および既存のお客様は、ECS Console または API の ECS アカウント設定ページを使用して、この新機能の使用をオプトインする必要があります。このセキュリティ制御により、ECS リソースの作成時にタグをつけることをユーザーに拒否または許可できます。2024 年 3 月 29 日以降もお客様の IAM プリンシパルが新しく作成された ECS リソースに引き続きタグを適用できるように、IAM ポリシーを更新して ecs:TagResource アクションを明示的に許可することを強くお勧めします。2024 年 2 月 9 日以降、AWS コンソール の ECS アカウント設定ページにて tagResourceAuthorization アカウント設定を明示的に off に設定していないすべてのお客様のアカウントは、自動的にこの設定にオプトインされました。お客様の AWS アカウントは一時的に許可リストに載せているため、2024 年 3 月 29 日まではタグリソース認証の off の動作が継続されます。2024 年 3 月 8 日、現在オプトインしているアカウントが tagResourceAuthorization をオプトアウトする機能を削除し、タグをサポートするすべての ECS リソースの作成に際して ecs:TagResource IAM 権限の使用を強制するようにしました。最終的に 2024 年 3 月 29 日をもってお客様のアカウントを許可リストから削除し、tagResourceAuthorization を有効化します。呼び出し元のプリンシパルの IAM ポリシーに ecs:TagResource アクションを含めずにタグをつけて ECS リソースを作成しようとすると、「AccessDenied」メッセージが表示されます。この変更は CreateCapacityProvider, CreateCluster, CreateService, CreateTaskSet, RegisterContainerInstance, RunTask, StartTask, および RegisterTaskDefinition の API に影響を及ぼします。ecs:TagResource を使用しない拒否レスポンスの例以下は、ecs:CreateCluster アクションを付与している IAM ポリシーの一部です。ecs:TagResource アクションは含まれていません。tagResourceAuthorization アカウント設定がオンの場合、リクエスト例では以下の AccessDenied 例外が返されます。# IAM ポリシー“Statement”: [{“Sid”: “AllowCreateCluster”,“Effect”: “Allow”,“Action”: [“ecs:CreateCluster”],“Resource”: “*”}]# クラスター作成のリクエストaws ecs create-cluster --cluster-name MyCluster --tags key=key1,value=value1# タグ付けの拒否されたレスポンスAn error occurred (AccessDeniedException) when calling the CreateCluster operation:User: is not authorized to perform: ecs:TagResource on resource: cluster/MyCluster because no identity-based policy allows the ecs:TagResource action必要なアクション:IAM プリンシパルが 2024 年 3 月 29 日以降も新しく作成された ECS リソースに引き続きタグを適用できるように、IAM ポリシーに次のステートメントを追加することを強くお勧めします。すべての ECS リソースの作成時にタグ付けを許可以下の説明に従って ecs:TagResource アクションを追加すると、ECS リソースの作成中にタグ付けが可能になります [2]。“Statement”: [{“Sid”: “AllowTagging”,“Effect”: “Allow”,“Action”: [“ecs:TagResource”],“Resource”: “*”}]単一の ECS リソースタイプ (ECS クラスタ) の作成時にタグ付けを許可条件ステートメント ecs:CreateAction を使用すると、タグ付けを特定の ECS API に制限できます。以下の例では、ECS CreateCluster API でのみタグ付けへのアクセスを許可します。タグ付きの ECS RunTask API へのリクエストは、拒否判定になります [2]。“Statement”: [{“Sid”: “AllowClusterTagging”,“Effect”: “Allow”,“Action”: [“ecs:TagResource”],“Resource”: “*”,“Condition”: {“StringEquals”: {“ecs:CreateAction” : “CreateCluster”}}}]タイムライン:2024 年 2 月 9 日（完了）- タグ付け認証はデフォルトで on になっています。これには、ホワイトリストに登録されているアカウントは含まれません。tagResourceAuthorization アカウント設定の on/off を切り替えることも可能であり、ポリシーへの準拠をテストいただけます。2024 年 3 月 8 日 - タグ付け認証を on にすると、off にすることはできなくなります。この日まではアカウント設定を切り替えることができますので、その間に IAM ポリシーをテストすることをお勧めします。2024 年 3 月 29 日 - すべての AWS アカウントでタグ付け認証が有効になります。アカウントレベルの設定は使用されなくなり、AWS コンソールの ECS アカウント設定ページから削除されます。ご質問やご不明点等ございましたら、AWS サポート [3] までお問い合わせください。[1] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-account-settings.html#tag-resources-setting[2] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/supported-iam-actions-tagging.html[3] https://aws.amazon.com/support---We are contacting you because we identified that your account has tagged ECS resources upon creation, within the past year, without the ecs:TagResource permission. Amazon ECS introduced tagging authorization for resource creation on April 18, 2023 [1]. New and existing customers must opt-in to use this new feature by using the ECS Account Settings page in the ECS Console or API. This security control allows users to deny or allow tagging ECS resources when they are created. We strongly recommend you update your IAM policies to explicitly allow the ecs:TagResource action so that your IAM principals continue applying tags to newly created ECS resources on or after March 29, 2024.From February 9, 2024, all customer accounts which have not explicitly set the tagResourceAuthorization account setting to “off” in the ECS Account Settings page in the AWS Console were automatically opted into the setting. We have temporarily allow-listed your AWS account so you will continue to have the “off” behavior for tagResourceAuthorization until March 29, 2024.On March 8, 2024, we removed the ability for currently opted-in accounts to opt-out of tagging authorization and enforced the creation of all ECS resources that support tags to use the ecs:TagResource IAM permission.Finally on March 29, 2024, we will remove your account from the allow-list and activate tagResourceAuthorization. You will experience an "AccessDenied" message if you attempt to create tagged ECS resources without including the ecs:TagResource action in the IAM policy of the calling principal. This change will affect the following APIs: CreateCapacityProvider, CreateCluster, CreateService, CreateTaskSet, RegisterContainerInstance, RunTask, StartTask, and RegisterTaskDefinition.Example Deny Response without ecs:TagResourceThe following is part of an IAM policy that is granting the ecs:CreateCluster Action. It does not include the ecs:TagResource Action. When tagResourceAuthorization Account setting is on, the example request would return the AccessDeniedException below.# IAM Policy“Statement”: [{“Sid”: “AllowCreateCluster”,“Effect”: “Allow”,“Action”: [“ecs:CreateCluster”],“Resource”: “*”}]# Create Cluster Requestaws ecs create-cluster --cluster-name MyCluster --tags key=key1,value=value1# Tagging Denied ResponseAn error occurred (AccessDeniedException) when calling the CreateCluster operation:User: is not authorized to perform: ecs:TagResource on resource: cluster/MyCluster because no identity-based policy allows the ecs:TagResource actionRequired Action:To ensure your IAM principals continue applying tags to newly created ECS resources on or after March 29, 2024, we strongly recommend adding the following statement(s) to your IAM policies:Allow Tagging during creation for all ECS ResourcesAdding the ecs:TagResource Action as described below would Allow tagging during ECS resource creation [2].“Statement”: [{“Sid”: “AllowTagging”,“Effect”: “Allow”,“Action”: [“ecs:TagResource”],“Resource”: “*”}]Allow Tagging during creation for single ECS Resource Type (ECS Cluster)Using the Conditional statement ecs:CreateAction allow you to limit the tagging to a specific ECS API. The example below grants access to tagging only on the ECS create-cluster API. A request to the ECS API run-task with tags would result in a Deny decision [2].“Statement”: [{“Sid”: “AllowClusterTagging”,“Effect”: “Allow”,“Action”: [“ecs:TagResource”],“Resource”: “*”,“Condition”: {“StringEquals”: {“ecs:CreateAction” : “CreateCluster”}}}]Timeline:February 9, 2024 (Completed) - Tagging Authorization is “on” by default. This excludes your account which is allowlisted. The tagResourceAuthorization account setting can be turned on/off to help test your policy compliance.March 8, 2024 - Tagging Authorization can no longer be turned “off” once it is turned “on”. It is recommended that you test your IAM policies before this date while you are able to toggle the account setting.March 29, 2024 - Tagging Authorization will be turned on for all AWS accounts. The account level setting will no longer be used and will be removed from the ECS Account Settings page in the AWS Console.If you have any questions, please contact AWS Support [3].[1] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-account-settings.html#tag-resources-setting[2] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/supported-iam-actions-tagging.html[3] https://aws.amazon.com/support通知が来ているアカウントは29日までに対応する必要があります。確認aws ecs list-account-settings --effective-settings --name tagResourceAuthorization を実行すると以下のような表示になると思います。ここがonであれば、すでにアカウント単位で有効になってるので影響がありません。(ただし、タグ付きのリソースを新規作成する際には権限が足りないとエラーになる可能性はあります)ここがoffになっている場合、タグ付け認可が無効になってるので3月29日以降影響を受ける可能性があります。% aws ecs list-account-settings --effective-settings --name tagResourceAuthorization{    "settings": [        {            "name": "tagResourceAuthorization",            "value": "on",            "principalArn": "arn:aws:iam::xxxxxxxxxxxx:root"        }    ]}影響がある例ユースケースにもよりますが、タグ付け認可に関連する操作は以下のようなものが考えられるかと思いますインフラ担当者によるECSリソース構築開発担当者(またはCI/CD)によるECSサービスのデプロイ前者に関しては、PowerUser相当の強い権限を付与されていることが多くここが問題になることはほとんどど無いかとは思います。後者の特にCI/CDによるデプロイに問題となることがありえます。一般的に非人間ユーザで目的が明確であれば、最小権限の原則に則り、 ecs:TagResource が付与されていない可能性があります。トライアンドエラーで権限を付与した場合、過去にうまく動いたためそのままの権限で使い続けている可能性もあります。その場合影響がある可能性あります。デプロイ時のタスク定義登録の際、タスク定義内に従来なかったtagsの記述を新規追加した際にResgisterTaskDefinitionでエラーになるという事例を私は経験しました。タスク定義にtagsがないときはタグ付け認可は実行されないのでそのまま成功していたため、ecs:TagResource が必要なことに気づいていませんでした。エラーとしては以下のような記述になるので、タグ付け認可の機能の存在を知っていて冷静に読み解けば、ecs:TagResource が足りていないことに気づけると思います。An error occurred (AccessDeniedException) when calling the RegisterTaskDefinition operation: User: arn:aws:sts::xxxx:assumed-role/deploy-github-actions/GitHubActions is not authorized to perform: ecs:TagResource on resource: arn:aws:ecs:ap-northeast-1:xxxx:task-definition/ecs-service because no identity-based policy allows the ecs:TagResource action対応まずECSサービスを利用しているIAM RoleとIAM Policyを洗い出します。その上でそれらが以下のアクションを許可している場合、ecs:TagResource を追加してあげます。CreateCapacityProviderCreateClusterCreateServiceCreateTaskSetRegisterContainerInstanceRegisterTaskDefinitionRunTaskStartTask私の場合は、ECSサービスデプロイ用のポリシーに以下のStatementを追加しました。それぞれ適切な記述を足していただけたらと思います。この場合タスク定義を登録する際にタグ付け認可を通すような許可を追加しています。        {            "Action": "ecs:TagResource",            "Condition": {                "StringEquals": {                    "ecs:CreateAction": "RegisterTaskDefinition"                }            },            "Effect": "Allow",            "Resource": "arn:aws:ecs:ap-northeast-1:xxxxxx:task-definition/yyyyyyyyyyyyyyy:*",            "Sid": "RegisterTaskDefinitionWithTag"        },まとめタグ付け認可について説明しました。タグ付け認可は2024年3月29日に強制的に全アカウントで有効になります。時間が少ないですが、影響受ける可能性があるかどうかチェックしてハマらないようにしましょう。また、これまでタグ付けしてなかったリソースにタグ付けする際にタグ付け認可に引っかかる可能性があります。デプロイやリソース作成の際にnot authorized to perform: ecs:TagResource と言われたらこの記事を思い出していただけたらと思います。それでは良いECSライフを!関連リソースアカウント設定による Amazon ECS 機能へのアクセス - Amazon Elastic Container Service タグ付け認可リソース作成時にタグ付けするための許可を付与する - Amazon Elastic Container Service

ECSのタグ付け認可とアカウント単位のオプトアウトの廃止

この記事は3-shake Advent Calendar 2023の23日目の記事となります。3-shakeのカレンダー | Advent Calendar 2023 - QiitaこちらはSRE Tech Talk #6で話した内容に補足したものです。3-shake SRE Tech Talk #6 - connpass資料はこちらとなります。    tfstateとはtfstateの課題tfstateの管理場所をどうするか問題localS3/Google Cloud StorageGitLabTerraform Cloudtfstateを管理するリソースをどう管理する問題aws/gcloud コマンドterraform + local state 管理CloudFormation / Google Deployment Managertfstateをどう分割するか問題環境分離パターンディレクトリ分離パターンbackend-configパターンworkspace環境分離以外の分割をどうするか問題分割する観点プロバイダーで分割管理権限で分割変更頻度で分割依存の方向性で分割tfstate間のリソース参照まとめtfstateとはTerraformが管理しているリソースの状態を表すjson形式のファイルです。tfstateとterraformファイルと実際のリソースの状態を比較して、terraformコマンドが実行されます。一般的には直接変更せずterraform stateコマンドを通して変更を行い、一般ユーザがtfstateに触れることはないです。参考: Backend Configuration - Configuration Language | Terraform | HashiCorp Developertfstateの課題tfstateについて以下の課題があります。それぞれについて見ていきます。tfstateの管理場所tfstateを管理するリソースの管理tfstateの分割tfstateの管理場所をどうするか問題主な保存場所候補としては以下のものがあります。local(デフォルト)クラウドのオブジェクトストレージS3/Google Cloud StorageGitレポジトリ統合GitLabSaaS利用Terraform CloudlocalTerraformのデフォルト保存先です。Terraformを実行する同じディレクトリのterraform.tfstateに保存されます。1人もしくは変更頻度が著しく低い状況など特殊なとき使えるものとなります。git管理して複数人で使うこともできるが、コンフリクトが発生しうるので、チーム開発には向かないです。基本的には複数人でterraformを使用するときは非推奨です。参考: Backend Type: local | Terraform | HashiCorp DeveloperS3/Google Cloud Storage監理するクラウドのオブジェクトストレージに保存する方法です。これが標準的(当社比)なのかなと思っています。オブジェクトストレージなので、権限があればどこからでもアクセスすることができます。それゆえ、同時にTerraformが実行されるので排他ロックの処理が必要となります。S3バックエンドを使用した場合はDynamoDBを使用してstate lockを実現します。Google Cloud Storageは単体でstate lockをサポートしています。tfstateの参照権限をクラウドのIAMで制御する必要があります。参考: Backend Type: s3 | Terraform | HashiCorp Developer参考: Backend Type: gcs | Terraform | HashiCorp DeveloperGitLabGitLabでtfstateを監理することもできます。tfstateを管理するリソースを管理する必要がないことがメリットとなります。(後述します)開発にGitLabを使っている場合、親和性が高い方法となります。参考: GitLab-managed Terraform state | GitLabTerraform CloudGitLabと同様tfstateを管理するリソースを管理する必要がないというところにメリットがあります。月間500 Managed Rsourcesまで無料で使えます。参考: HashiCorp Terraform: Enterprise Pricing, Packages & Featuresweb上からリソース差分の確認できたり、applyが可能です。SaaSにクラウドのリソース情報を預けることに抵抗がない場合は選択肢としては有望です。なおTerraformのStateのドキュメントではこういう記述があり、Terraform Cloudを推奨しているようです。This state is stored by default in a local file named "terraform.tfstate", but we recommend storing it in Terraform Cloud to version, encrypt, and securely share it with your team.参考: State | Terraform | HashiCorp Developer昔はAWSと連携するためにIAM Userのアクセスキーを使わないといけなかったが、OIDC認証もできるようになったので、よりやりやすくなったかと思います。参考: Terraform Cloud Adds Dynamic Provider Credentials for Vault and Official Cloud Providers参考: Terraform Cloud | Terraform | HashiCorp Developertfstateを管理するリソースをどう管理する問題GitLabやTerraform Cloudを使う場合には起きない問題となります。S3のようなクラウドのオブジェクトストレージを使用する場合は、このS3バケットをどう作るかということが問題となります。コマンドで作る場合、コマンドの管理、terraformで作る場合はそのtfstateはどこに保存するか、そういったことに頭を悩ませます。そこについて考えていきます。以下の方法が考えられます。aws/gcloudコマンドterraform + local state管理CloudFormationaws/gcloud コマンドそもそも作成コマンドしか打たないのであれば、スクリプトをレポジトリに含めておけば良いという考え方はあります。基本的に一度作れば変えることはないので、これで十分という風に割り切ることはできます。ただし、tfstateのバケットだけでなく、CI/CD用のIAM RoleやOIDC認証リソースなども初期リソースとして含めて管理したいというユースケースだと、スクリプト管理では力不足になりうります。terraform + local state 管理オブジェクトストレージをterraformで作る方法です。ただし、tfstateに関してはlocalに保存し、これをgitも管理します。かたくなにterraformを使いたい人に向けな方法となります。デメリットとしては、tfstateもgit管理するのでコミット忘れがあります。また、頻度低いですがterraform自体はローカルで実行せざるを得ないので変更衝突が起きうることです。CloudFormation / Google Deployment Managerクラウドごとにコードを変えないといけない。IaCツールを2種類使うというそこはかとない気持ち悪さはあるというデメリットはありますが、gitでインフラ状態管理しなくてすむというメリットがあります。気持ち悪さだけを克服できるなら無難な選択肢だとは思います。tfstateをどう分割するか問題第一に考えるのが環境の分離。この分離の仕方だけ他とは系統が違うので独立して説明します。一部差分があるだけで、以下のような形でほぼ同じ構成の環境を作ることはよくあります。開発環境ステージング環境本番環境これらについてどう分割するのかを考えていきます。環境分離パターン大きく2つのパターンを利用することが多いです。それぞれ見ていきます。ディレクトリ分離パターンbackend-configパターンディレクトリ分離パターンこれは環境ごとにディレクトリを分割して、環境ディレクトリを実行単位とします。環境の切り替えはディレクトリ移動することで行います。環境ごとの差分が大きいときに使うことが多いです。デメリットとしては環境ごとにリソース定義をそれぞれ書くので記述量が多くなるというのがあります。そのため、可能な限りモジュール化して、なるべくパラメータだけの差分にするようにします。ディレクトリ構成例としては以下の通りです。.├── envs│   ├── dev│   │   ├── locals.tf│   │   ├── main.tf│   │   ├── outputs.tf│   │   └── variables.tf│   ├── prd│   │   ├── locals.tf│   │   ├── main.tf│   │   ├── outputs.tf│   │   └── variables.tf│   └── stg│       ├── locals.tf│       ├── main.tf│       ├── outputs.tf│       └── variables.tf└── modules    ├── vpc    │   ├── locals.tf    │   ├── main.tf    │   ├── outputs.tf    │   └── variables.tf    ├── application    │   ├── locals.tf    │   ├── main.tf    │   ├── outputs.tf    │   └── variables.tfbackend-configパターンbackend-configオプションとvars-fileオプションを組み合わせて、環境を切り替えるパターンです。${ENVDIR}/terraform.tfvars に環境ごとの差分パラメータを定義して、${ENVDIR}/backend.tfvars に環境ごとのtfstate保存先を定義します。terraform init で backend.tfvars を切り替えることで環境の切り替えを行います。環境ごとに差分が少ないときに向いています。差分は terraform.tfvars に記述されているパラメータだけなので、記述量が少なくて済みます。ただし差分が多くなるとcount, for_eachで分岐やループを作ることになり読みにくくなるというものがあります。ディレクトリ構成例としては以下のようになります。.├── envs│   ├── dev│   │   ├── backend.tfvars│   │   └── terraform.tfvars│   ├── prd│   │   ├── backend.tfvars│   │   └── terraform.tfvars│   └── stg│       ├── backend.tfvars│       └── terraform.tfvars├── locals.tf├── main.tf├── modules│   └── vpc│       ├── locals.tf│       ├── main.tf│       ├── outputs.tf│       └── variables.tf├── outputs.tf├── provider.tf└── variables.tf設定ではbackendをs3と指定しておき中身はオプションで指定するようにします。terraform {  backend "s3" {}}以下のようにterraform initするたびに適用する環境を切り替えることができる。terraform init --backend-config=${ENVDIR}/backend.tfvars --reconfigureterraform apply --var-file=${ENVDIR}/terraform.tfvarsworkspaceworkspaceは同じような環境を複製するときに使ういます。シングルテナント環境を量産する場合や開発環境を複数作る場合などに使います。環境を切り替える用途には作られてないとドキュメントまでは記載されています。参考: Managing Workspaces - Terraform CLI | Terraform | HashiCorp DeveloperIn particular, organizations commonly want to create a strong separation between multiple deployments of the same infrastructure serving different development stages or different internal teams. In this case, the backend for each deployment often has different credentials and access controls. CLI workspaces within a working directory use the same backend, so they are not a suitable isolation mechanism for this scenario.自分自身がworkspaceを実運用で使ったことがないので多くは語れないです。別でちゃんと使ってから書きたいと思います。参考: State: Workspaces | Terraform | HashiCorp Developer環境分離以外の分割をどうするか問題小さいサービスでは環境を分離するだけでだいたいは問題ないことがおおいですが、terraformを運用していると運用面、管理面でいろいろ課題が出てくると思います。管理するリソースが増えるとplan/applyの時間が増えたり、リソースの見通しが悪くなったりしてきます。特に実行時間が意外に馬鹿にできなかったりします。下手するとplanに数分かかるようになったりします。そのため、ある程度大きくなったらtrstateを分割して、リソースの管理範囲を分割する必要が出てきます。これをどうやって分割するかが自分の中で答えが出ていない出てないし、分脈によって解決策は異なるとは思います。ここで、解決策を考えるうえで、分割するための観点を見ていきましょう。分割する観点分割する観点は以下のようなものがあるかと思います。プロバイダー管理権限変更頻度プロバイダーで分割プロバイダー単位で分割するパターンです。例としてはAWSとDatadogのようにプロバイダーで分割します。プロバイダー間で依存がない場合は分けやすいかと思います。また、プロバイダー間で管理主体が違うことも多いので素直な分け方だとは思います。しかしながら、アプリケーションリソースとアプリケーションの監視を近いところにおいたほうが見通しがよいのではという観点もあるので運用体制にあわせて考えるとよいでしょう。管理権限で分割チームの権限で分割するパターンです。ただし、より堅くするなら、ディレクトリではなくレポジトリ自体も分割して、コードの参照権限も分割する方が望ましい場合もあります。例ネットワーク ⇒ インフラチームアプリケーション ⇒ 開発チーム変更頻度で分割変更をあまりしないリソースを変更が頻繁なリソースと一緒のplan/applyするのは無駄なので変更の頻度でtfstateを分割するパターンもあります。例変更が少ない ⇒ DB/ネットワーク変更が多い ⇒ EC2/ECS依存の方向性で分割少し観点を変えてみます。実際に分割をした場合に問題となるのはtfstate間のリソースの依存が課題になります。tfstate間で相互に依存するようなコードを書くとtarget指定してそれぞれのstateのリソースを作成しなくてはなりません。こうすると管理が煩雑となってしまうので、原則的に片方向だけの依存になるように分割するようにするのが望ましいです。tfstate間のリソース参照terraform_remote_state を使うことで、参照元のTerraformでoutputした内容を別のTerraformで利用することができます。# 参照元 networkアカウントoutput "vpc_id" {  value = aws_vpc.main.id}# 参照先 applicationアカウント# data.terraform_remote_state.network.vpc_id の形式でVPC IDを参照できるdata "terraform_remote_state" "network" {  backend = "s3"  config {    bucket = "terraform-tfstate-network-xxxxx"    key    = "tfstate"    region = "ap-northeast-1"  }}まとめ正直tfstateをどう扱うかに正解はないです。サービス規模や性質によって選択は変わります。本当に小さい規模であれば、tfstateを分割せず一つで十分でしょうし、チーム開発せず一人で扱うなら、通常であれば推奨されないtfstateのlocal git管理という手段がふさわしい場合もあります。また、組織やサービスの成長や時間経過によっても最適な選択は変わると思います。大事なのは選んだ技術要素に関しては選定理由を説明できるようにはしておくということです。選定理由及び不採用理由を明確にしておくことで、変更時に最適な選択の助けになるでしょう。

Terraformのtfstateについて考える

この記事は3-shake Advent Calendar 2023の16日目の記事です。qiita.comこの内容はSRETT #8で発表した内容に補足しています。3-shake.connpass.com    前提語らないことモチベーションPulumiとは対応言語PulumiのアーキテクチャPulumiのコンポーネントPulumi CloudPulumi Cloud 料金Pulumi操作方法PulumiインストールPulumi CloudへログインProjectの作成変更を確認Stackデプロイリソース削除state操作Terraformからの移行TerraformとPulumiを共存する(tfstateを参照)tfstateからインポートterraformからコード変換まとめ前提筆者は以下の背景を持っています。普段はAWSをメインに触っている普段はTerraformをメインで使ってるPulumiはプロダクションでは使ったことがないちゃんとは把握できてない語らないこと以下のようなPulumi以外の基本的なことは語りませんIaCとは概要、特徴、メリット・デメリットTerraformとは概要、特徴、メリット・デメリット、操作方法モチベーションなんでPulumiを今回調べようかと思った動機について書こうと思います。Terraformの記述力に限界を感じていたというところが大きいです。以下の点がつらいかなと思っていたところです。足りない関数二重ループのためのModule使用分岐処理のためのcountと三項演算子とはいえ、記述力が低いからこそ複雑なことを抑制できて可読性が上がっている面もあると思います。冗長でも、可読性が高いというのはメリットではあります。他の選択肢としては以下のものがあるかと思います。CDKAWSに限定されるCDKTF(CDK for Terraform)結局terraformのJSONコードに変換されるので、terraformに依存しますそれ自体は悪くないが、どうせならTerraformから離れたものを学びたいそこでなにか良いものがないかと思い当たったところにPulumiがあったので調べてみようとなりました。PulumiとはPulumiはプログラミング言語でインフラを構築可能なプロビジョニングツールです。Terraformと同じようにProviderを通して複数のクラウドに対応しています。TerraformはHCLという宣言的言語を使用するのに対し、Pulumiは汎用的なプログラミング言語を使用してインフラリソースを定義します。Pulumi - Infrastructure as Code in Any Programming Language対応言語TypeScript & JavaScript (Node.js)PythonGoC#, VB, F# (.NET)JavaPulumi YAML参考: Pulumi Languages & SDKs | Pulumi DocsPulumiのアーキテクチャ以下のようの構成になっています。参考: How Pulumi Works | Pulumi DocsLanguage hostインフラリソースの定義を Program (後述)として好きな言語で定義します。Deployment Engine希望する状態に変更するための操作セットを実行する役割を果たします。Resource Providerクラウドサービスとの通信を処理して、Programで定義したリソースの変更処理を行います。上記の例だと、Programにリソースの定義がある場合、Stateと比較して、管理されているリソースであるかを確認します。存在すれば、プロバイダーを通して実際のクラウドのリソースの状態と比較して差分があれば適用。存在しない場合、プロバイダーを通してリソースを作成。PulumiのコンポーネントWhat is Pulumi? | Pulumi DocsPulumiのコンポーネントは以下のようになっています。ProjectProgramのソースコードとメタデータ(Programの実行方法)を格納したディレクトリProgramインフラのあるべき姿を定義したものResourceインフラを構成するオブジェクト。ResourceのプロバティはOutputとして他のResourceのInputに使用することができますStackProgramを実行すると作成されるインスタンス。同一のProgramから開発、ステージング、本番環境のStackを個別に作成することができます。Pulumi CloudTerraform Cloudのようなものと考えていただいて良いです。デプロイの状態、履歴やシークレットを管理して、CI/CDやGitHubと連携してデプロイを実行することもできます。Pulumi CLIはバックエンドを明示的に指定しない限りはでデフォルトでPulumi Cloudを使用します。Terraformはデフォルトでlocalバックエンドを使用します。以下はPulumi Cloudの画面です。Pulumi Cloud 料金個人で使う限りは無料で使用することができます。※2023/12/18現在Pulumi操作方法ここからPulumiの操作方法を見て行きたいと思いますPulumiインストール個人的にはバージョン管理したいのでasdfでインストールします。brewでもインストールできます。# .tool-versionspulumi 3.97.0 asdf installPulumi CloudへログインデフォルトではPulumi Cloudへログインします。以下のコマンドを実行するとブラウザが起動するので、ログイン処理をします。pulumi loginPulumi Cloudを使わず、ローカルにstateを保存したい場合は以下のとおりです。pulumi logoutpulumi loign --localProjectの作成pulumi new コマンドで新しいProjectを作成できます。同時にStackも作成されます。引数にテンプレートを指定できます。ウィザード形式で設定をすることができます。以下の例は awsプロバイダーを使用して、言語はTypeScriptを使用するテンプレートとなります。ディレクトリ内にはPulumi実行に必要な各種ファイルが生成されます。ここで見るべきは以下の3ファイルです。Pulumi.yamlプロジェクト設定Pulumi.dev.yamlStack(dev)設定index.tsリソース定義# Pulumi.yamlname: sampleruntime: nodejsdescription: A minimal AWS TypeScript Pulumi program# Pulumi.dev.yamlconfig:aws:region: us-east-1// index.tsimport * as pulumi from "@pulumi/pulumi";import * as aws from "@pulumi/aws";import * as awsx from "@pulumi/awsx";// Create an AWS resource (S3 Bucket)const bucket = new aws.s3.Bucket("my-bucket");// Export the name of the bucketexport const bucketName = bucket.id;変更を確認plumi preview コマンドでStackの変更差分を確認できます。 terraform plan を似ていますが、こちらは差分の詳細は表示されません。Stackデプロイpulumi up コマンドでStackをデプロイできます。 terraform plan と terraform apply を組み合わせた挙動になります。実行すると選択肢が出ます。details を選択すると変更差分の詳細が表示されます。yesを選択すると、変更が適用されます。リソース削除pulumi destroy でStackを削除できます。pulumi up と同じようにdetailsで詳細表示、 yes で削除実行ができますstate操作PulumiではStackごとにStateが保存されています。Stateを操作するコマンドは以下のとおりです。state出力(terraform state pull 相当 )pulumi stack exportstate インポート(terraform import相当)pululmi import <TYPE> <NAME> <ID>state 削除(terraform state rm 相当)pulumi state delete <URN>Terraformからの移行Terraformからの移行オプションは以下の通りとなります。terraformとPulumiを共存するPulumiからtfstateを参照するtfstateからリソースをPulumiへインポートするTerraformのコードをPulumiのコードに変換する参考: Adopting Pulumi | Pulumi Docs参考: Migrating from Terraform | Pulumi DocsTerraformとPulumiを共存する(tfstateを参照)networkリソースに関しては既存のterraformを使いつつ、そのoutputをPulumiで使うイメージになります。以下のようなコードでlocalのtfstateが参照できるので、値を参照して利用することができます。import * as aws from "@pulumi/aws";import * as terraform from "@pulumi/terraform";// Reference the Terraform state file:const networkState = new terraform.state.RemoteStateReference("network", {    backendType: "local",    path: "/path/to/terraform.tfstate",});// Read the VPC and subnet IDs into variables:const vpcId = networkState.getOutput("vpc_id");const publicSubnetIds = networkState.getOutput("public_subnet_ids");// Now spin up servers in the first two subnets:for (let i = 0; i < 2; i++) {    new aws.ec2.Instance(`instance-${i}`, {        ami: "ami-7172b611",        instanceType: "t2.medium",        subnetId: publicSubnetIds[i],    });}tfstateからインポートpulumi import --from terraform ./terraform.tfstate のようにすることによってtfstateからリソースをインポートすることができます。terraformからコード変換pulumi convert --from terraform コマンドを使用することで、既存のTerraformのコードをPulumiのコードに変換することができます。ただし、変換できないコードはTODOコメントが付く。90%~95%は変換が対応しているとのこと。pulumi convert --from terraform --language typescriptまとめPulumiの概要と基本操作をTerraformと対比しながら説明してきました。新規プロジェクトである程度複雑な処理をしたい。プログラミング言語に精通している人がメンバーにいる。そういった場合にはPulumiは良さそうに思えます。しかしながら、ある程度Terraformで出来上がっているプロジェクトをPulumiに移行するのはそれなりに大変なので、プロジェクトの規模感とコストに見合うかを考えて導入するか考えると良いでしょう。また、複雑なことをしたいというのは、本当に必要とされていることなのでしょうか?冗長でも簡易的な書き方をした方が望ましい場合もあるかと思います。そのあたりの目利きをちゃんと考えたいところです。自分自身まだまだ使いこなせていないですし、追いきれてないPulumiのトピックもあるので、今後も選択肢の一つとして調べていきたいところです。

Terraform使いがPulumiに入門しました

qiita.comこの記事は、3-shake Advent Calendar 2023の9日目の記事となります。sops プロバイダーとは本当に安心?ドキュメントを調べる挙動を実験する結論ワークアラウンドsops プロバイダーとはcarlpett/terraform-provider-sops: A Terraform provider for reading Mozilla sops filesDocs overview | carlpett/sops | Terraform | Terraform RegistrysopsプロバイダーはMozilla sopsを使用して暗号化されたファイルから機密情報を取り出して、terraform上で使用できるようにしたものです。暗号化の鍵をAWS KMS等を使うことにより、KMSキーを使う権限を持つ人だけ機密情報にアクセスできるようにするものです。sopsで機密情報を暗号化することにより、平文で機密情報をgitレポジトリに保存することがなくなり安全ということになります。機密情報を管理したい。でも平文では保存したくない。そういう用途にこちらは使用されます。本当に安心?SOPSを使って機密情報を暗号化することによりgitレポジトリには機密情報が平文で残らない。これで安心と言われていますが、よく考えると機密情報をterraform実行時にはリソースに対して平文で与えているはずです。つまり、tfstate上は機密情報が平文で保存されています。例えば、tfstateがS3に保存されているとして、KMSキーへの権限がない人でもS3バケットにアクセスする権限があれば、平文の機密情報が見れてしまいます。あまりないと思いますが、tfstateをlocalに保存するようにしていてそれをgit管理していてらなんのために暗号化しているのか。。。。ということになります。こう考えると組織のポリシーによるが、sopsプロバイダーによる暗号化では不十分ではないかという疑問が生まれます。ドキュメントを調べるまずプロバイダードキュメントを当たってみます。Docs overview | carlpett/sops | Terraform | Terraform RegistryTo prevent plaintext secrets from being written to disk, you must use a secure remote state backend. See the official docs on Sensitive Data in State for more information.これが意味してるのはバックエンドをlocalにした場合平文で機密情報が書かれるので、安全なリモートバックエンドを利用すべきということだと思います。State: Sensitive Data | Terraform | HashiCorp Developer参照しろと言われたドキュメントの該当部分を読んでみましょう。ローカルディスクにtfstateを保存した場合は、機密情報が平文で保存されます。リモートにtfstateを保存する場合、保存時に暗号化されるかはバックエンドに依存します。基本的にリモートステートを使うことを推奨しています。例えば、Terraform Cloudを使う場合、tfstateは暗号化され、転送時もTLSで暗号化されます。S3を使う場合もSSE-S3やSSE-KMS等でサーバサイド暗号化を有効にしておくことで、保管時の暗号化がされます。バケットポリシーでHTTPSを強制することで通信時の暗号化も保証することができます。参考: 暗号化によるデータの保護 - Amazon Simple Storage Service参考: Amazon S3 のセキュリティのベストプラクティス - Amazon Simple Storage Serviceところがですね。保存時、通信時の暗号化をしても、terraform state pullすると平文でtfstateが手に入ってしまうんですよ。。。後述します。挙動を実験する以下のような設定ファイルを作ります。sopsで暗号化したdb_userとdb_passwordをパラメータストアに設定するものになります。tools-versionsterraform 1.5.5sops 3.7.3main.tfterraform {  required_version = "~> 1.5.5"  required_providers {    aws = {      source  = "hashicorp/aws"      version = "~> 5.15"    }    sops = {      source  = "carlpett/sops"      version = "~> 0.7.2"    }  }  backend "s3" {    region  = "ap-northeast-1"    bucket  = "xxxxxxxxxx"    key     = "test.tfstate"  }}provider "sops" {}provider "aws" {  region = "ap-northeast-1"}data "sops_file" "secrets" {  source_file = "secrets.yaml"}resource "aws_ssm_parameter" "db_user" {  type     = "String"  name     = "/test/db_user"  value    = data.sops_file.secrets.data.db_user}resource "aws_ssm_parameter" "db_password" {  type     = "SecureString"  name     = "/test/db_password"  value    = data.sops_file.secrets.data.db_password}暗号化前の secrets.yamldb_user: userdb_password: passwordapply結果がこちらとなります。terraform apply% export SOPS_KMS_ARN=arn:aws:kms:ap-northeast-1:xxxxxxxxx:key/yyyyyyyyyyyyyyyyyy% terraform applydata.sops_file.secrets: Reading...data.sops_file.secrets: Read complete after 1s [id=-]Terraform used the selected providers to generate the following execution plan. Resource actions areindicated with the following symbols:  + createTerraform will perform the following actions:  # aws_ssm_parameter.db_password will be created  + resource "aws_ssm_parameter" "db_password" {      + arn            = (known after apply)      + data_type      = (known after apply)      + id             = (known after apply)      + insecure_value = (known after apply)      + key_id         = (known after apply)      + name           = "/test/db_password"      + tags_all       = (known after apply)      + tier           = (known after apply)      + type           = "SecureString"      + value          = (sensitive value)      + version        = (known after apply)    }  # aws_ssm_parameter.db_user will be created  + resource "aws_ssm_parameter" "db_user" {      + arn            = (known after apply)      + data_type      = (known after apply)      + id             = (known after apply)      + insecure_value = (known after apply)      + key_id         = (known after apply)      + name           = "/test/db_user"      + tags_all       = (known after apply)      + tier           = (known after apply)      + type           = "String"      + value          = (sensitive value)      + version        = (known after apply)    }Plan: 2 to add, 0 to change, 0 to destroy.Do you want to perform these actions?  Terraform will perform the actions described above.  Only 'yes' will be accepted to approve.  Enter a value: yesaws_ssm_parameter.db_password: Creating...aws_ssm_parameter.db_user: Creating...aws_ssm_parameter.db_user: Creation complete after 0s [id=/test/db_user]aws_ssm_parameter.db_password: Creation complete after 0s [id=/test/db_password]Apply complete! Resources: 2 added, 0 changed, 0 destroyed.terraform apply  8.91s user 0.78s system 124% cpu 7.811 totalstate showするとパラメータストアなのでsensitive扱いになっていて、見れません。これはいけるか?terraform state show% terraform state show aws_ssm_parameter.db_password# aws_ssm_parameter.db_password:resource "aws_ssm_parameter" "db_password" {    arn       = "arn:aws:ssm:ap-northeast-1:xxxxxxxxx:parameter/test/db_password"    data_type = "text"    id        = "/test/db_password"    key_id    = "alias/aws/ssm"    name      = "/test/db_password"    tags_all  = {}    tier      = "Standard"    type      = "SecureString"    value     = (sensitive value)    version   = 1}% terraform state show aws_ssm_parameter.db_user    # aws_ssm_parameter.db_user:resource "aws_ssm_parameter" "db_user" {    arn       = "arn:aws:ssm:ap-northeast-1:xxxxxxxxx:parameter/test/db_user"    data_type = "text"    id        = "/test/db_user"    name      = "/test/db_user"    tags_all  = {}    tier      = "Standard"    type      = "String"    value     = (sensitive value)    version   = 1}ここで、terraform state pullをしてみて、tfstateファイルをローカルにダウンロードします。そのtfstateファイルの中の該当部分はこちらとなります。    {      "mode": "managed",      "type": "aws_ssm_parameter",      "name": "db_password",      "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",      "instances": [        {          "schema_version": 0,          "attributes": {            "allowed_pattern": "",            "arn": "arn:aws:ssm:ap-northeast-1:xxxxxxxxx:parameter/test/db_password",            "data_type": "text",            "description": "",            "id": "/test/db_password",            "insecure_value": null,            "key_id": "alias/aws/ssm",            "name": "/test/db_password",            "overwrite": null,            "tags": null,            "tags_all": {},            "tier": "Standard",            "type": "SecureString",            "value": "password",            "version": 1          },          "sensitive_attributes": [            [              {                "type": "get_attr",                "value": "value"              }            ]          ],          "private": "bnVsbA==",          "dependencies": [            "data.sops_file.secrets"          ]        }      ]    },tfstateファイルの中身をよく確認するとしっかり平文で見えています。残念。"value": "password",結論sopsプロバイダーを使用することによりgitレポジトリ上に機密情報を平文で保存することはなくなります。しかしながら、tfstateのデータ上では設定値が平文で保存されることを防ぐことはできません。terraform state pullする権限があれば、機密情報が見れてしまいます。運用組織のポリシーで、tfstateへのアクセス権限を適切に権限管理することができるのであれば、選択肢としては取りうります。暗号化のためのKMSキー、tfstateを保存するS3バケットを機密情報をアクセス可能な人のみ権限を与えることが徹底できればよいです。しかしながら、機密情報をいかなる場合でもローカルに平文で保存することが許容されない組織であれば、機密情報は手動で設定することを選択したほうが望ましいと思います。どうしても機密情報をterraformで管理したのであれば、クライアントサイドで暗号化した機密情報をterraformで管理し、アプリ等で使用時にクライアントサイドで復号を行う形も考えられます。安全かどうかは、tfstateの保存場所、tfstateへのアクセス権限、暗号化鍵のアクセス権限それぞれが適切に設定されているかどうかが鍵となります。他に何かうまい方法で機密情報を管理しているという方がいらっしゃれば、ご意見ください。ワークアラウンドこれは自分がよく使う手段となります。リソースの箱だけ作って、作成時にダミーの値を入れておき、実際の値は手動で設定するという手法です。ignore_changesを入れておくことで、手動で値を変更しても、terraform的には差分ができないようにしています。これにより、機密情報をterraformの外に追い出しつつも、機密情報を入れるリソース自体は監理するということが実現できます。resource "aws_ssm_parameter" "db_password" {  type     = "SecureString"  name     = "/test/db_password"  value    =  "Dummy"  lifecycle {    ignore_changes = [value]  }}

Terraformのsopsプロバイダーを使用するだけで機密情報は守られるのか

吉祥寺.pm こと 句会吉祥寺.pm35 に参加して、LTしてきました。kichijojipm.connpass.com資料はこちら。言いたいこととしてはベストプラクティスなんてないよ。一般的によりよいプラクティスやパターンはあるけど、どんなときには適用できる銀の弾丸的なものはないから、自身の組織とサービスに合わせてくみ上げていきましょうということ。正解はひとつ!じゃない!!その上で、ざっくりとどんな選択肢と選択するための観点を述べていきました。まだ全然ブラッシュアップできるのでどこかでまとめてブログに書きたいところです。ちなみに最後に出てくる あなたらしく○○ は同僚のスライドのパロディです。毎回時間オーバーするのでトークで申し込んだ方が良いのでは?というツッコミはごもっともです。懇親会でもTerraformのお悩みとか短いですが話せて楽しかったです。また参加したいですね。

吉祥寺.pm35 でLTしてきました。 #kichijojipm

これは  3-shake Advent Calendar 2022 10日目の記事です仕事の中でAWSで複数のアカウントを管理したいという要件あり、その中でAWS Control Towerが使えないかなと調べたものをざっくりと書いていきます。AWS Control TowerとはAWS Control TowerとはLanding Zoneを実装するためのAWSのマネージドサービスです。そもそもLanding Zoneって何って話になりますね。Landing Zoneとはセキュリティとコンプライアンスのベストプラクティスに基づきアーキテクチャ設計とマルチアカウント環境を管理する仕組みを指します。Landing Zoneは、下記機能から構成されます。アカウントの発行必要な初期設定の済んだアカウントを作成管理用権限の発行対象アカウントを管理するための権限を作成AWS ログの集約監査用ログをセキュアに一元保存ガードレールの設置実施してはいけない操作の禁止危険な設定の監視Landing Zoneの実装方法AWS Control TowerAWSサービスとして提供される Landing Zoneです。容易に利用可能ですが、カスタマイズするには制限があります。(必須のガードレールを外せなかったり)主にこれからAWSを利用する場合に利用できます。既存アカウントにも適用可能です。独自実装の Landing Zone自組織で独自実装するパターンです。自組織の方針に従って自由にカスタマイズできるのが強みです。ただし、自由にカスタマイズはできますが、自身でメンテナンスしないといけないので、コストはかかります。主に既存アカウントに適用する場合に利用できます。自組織でアカウント発行の仕組みや管理の仕組みができあがってる場合などです。そもそもなんでマルチアカウントにするのかAWSをマルチアカウントにする観点として以下のものが考えられます。環境の分離開発、テスト、本番を分離することによるセキュリティおよび統制の確保請求の分離部門やシステム単位でのコスト明確化権限の分離部門間での権限分離およびアカウントへの権限移譲複雑性の分離アカウントの目的を明確に絞ることで、構成がシンプルになるAWS Organizationsだけでもできることマルチアカウント管理するだけならOrganizationだけでもある程度はできます。むしろAWS Control TowerはOrganizationの機能を利用しています。複数AWSアカウントの一元管理Organization Unit(OU)の作成複数アカウントのグルーピング化AWSアカウントの発行Service Control Policyの作成、OUへの適用複数アカウントの一括請求AWS Control Towerだと何ができるのかControl Towerで提供される機能として以下のものがあります。Landing Zoneの提供AWS Organizationを使用してマルチアカウントを作成デフォルトでSandbox、SecurityのOUを作成AWS IAM アイデンティティセンターを利用したID管理を提供Account FactoryAWSアカウントのプロビジョニングの自動化設定可能なテンプレートを提供CloudTrailとConfigログの保存Log Archiveアカウント内のS3バケットに一元的に保存されるガードレールの提供必須と任意の観点の2種類と予防的と発見的の2種類の組み合わせがありControl Towerにより管理下のアカウントに適用される参考: ガードレールの仕組み予防的ガードレール(Service Control Policy)禁止されたアクションの実行が拒否される仕組みControl Tower管理下のアカウントは必須の予防的ガードレールで禁止されているアクションが不可能発見的ガードレール(Config)特定のイベントが発生したときにCloudTrailに記録される仕組みダッシュボードOUやアカウント、ガードレール違反などが一覧表示できるAWS Control TowerではできないことAWS Control Towerでは提供されてない機能もあります。GuardDutyやSecurity Hubなどのセキュリティ機能を組織全体適用するにはOrganizationsの機能を利用する必要があります。AWS Control Towerの注意点、制約事項いろいろ資料を見てみてこの辺注意が必要かなという点を書いていきます。注意点既存アカウントの Control Tower への受入処理時にエラーになった場合、スタックセット内で自動実行される作業の一部手作業が必要になる参考:トラブルシューティング - AWS Control Tower独自ガードレールの追加は可能だが、容易ではない。必須ガードレールを外せない参考:必須のガードレール - AWS Control Tower各種セキュリティー機能は自動で有効化されないため、Control Towerの範囲外のセキュリティ機能は Control Tower の機能の外で管理が必要になる範囲内の機能: Config, CloudTrail, SCP範囲外の機能: GuardDuty, Security Hub, IAM Access Analyzer, DetectiveControl Tower 未対応リージョンを使用している場合、Control Tower適用リージョンと適用外リージョンが混在して管理が煩雑になる大阪リージョン未対応なのでマルチリージョンを考えるときに注意Control Towerはマネージドサービスであるが追加機能によっては手動バージョンアップ が必要になるケースがある参考: ランディングゾーンを更新する - AWS Control Tower参考: 更新について - AWS Control Towerログアーカイブアカウントで独自のログバケットを作成可能だが、非推奨参考: ランディングゾーンのセットアップに関する管理上のヒントリージョンの使用を制限する SCP の併用に注意が必要参考: AWS Control Tower リソースの作成および変更に関するガイダンスIaC との境界の検討が必要アカウント発行に関してはControl Tower(Account Factory)で手動で行い、その後のアカウント設定はTerraformで行うなどAccount Factory for Terraformを利用することでAWSアカウント発行は可能参考: AWS Control Tower Account Factory for Terraform によるアカウントのプロビジョニングどこまでTerraformで対応するかは別途検討が必要制限とクォータS３へのログの保存期間は、最大15年間保存可能(最近アップデートされた)Security OU の共有アカウントの E メールアドレスは変更可能だが、これらの変更を AWS Control Tower コンソールで確認するには、Landing Zone を更新する必要があるAWS Control Tower Landing zone の OU には、OU あたり5個のSCPの制限が適用される300超のアカウントを持つ既存の OU は、AWS Control Tower に登録することはできない300を超える場合はOUを分ける必要があるOUのネストは２段階まで、孫OUを持つことはできない参考: AWS Organizations における組織単位のベストプラクティスAWS Control Towerを使うべきなのかマルチアカウントを展開していくのであれば、AWSのベストプラクティスに乗れるので、使用するのが無難です。ただし、独自のLanding Zoneをすでに構築しており、Account Factoryの仕組みも独自で構築できているのであれば、移行コストを鑑みてそのままでも問題ないです。必須の予防的ガードレールが許容できない、OUなどの制限にひっかるなどの運用上の制約がある場合は使えないので、組織のポリシーを見直すか、独自でLanding Zoneを作るかを考える必要があります。発展もっと調査したかったが、時間が足りなかったことや今後調べたいことです。コンソールからAccount Factory実行するとService Catalogの設定項目がありますが、Service Catalog自体の理解不足でどう扱うのかが把握できてないのでこの辺調べたいです。Account Factory for Terraform(AFT)を使うとアカウント発行そのものもIaC化できるので試したい。参考: AWS Control Tower Account Factory for Terraform によるアカウントのプロビジョニング参考: ついにControl Towerのアカウント発行からカスタマイズまでIaC対応！Account Factory for Terraform (AFT)が新登場 #reinvent | DevelopersIOCustomization for Control Tower(CfCT)を使うとアカウント発行のイベントをトリガーにCloudFormationを実行できるので、これも実験したい。参考: AWS Control Tower のカスタマイズ (CfCT) の概要 - AWS Control Tower参考: Control Towerカスタマイズソリューション(CfCT)を使ってガードレールとCloudFormationを自動展開してみた | DevelopersIOまとめControl Towerについて調べたことを書いていきました。実運用自体はまだしてないので、これから触ってみて知見が溜まってきたらまたそれも共有できたらと思います。

AWS Control Towerを調べる

7年ぶりにふり返りするような気がします。これぶりですかね。blog.masasuzu.net10月は思い立って細かいことでも記録に残すようにし始めたのでサブブログの月間投稿数が増えてます。このまま続けたいところです。メインブログは相変わらず0なのでちゃんと書きたいところではあります。2022-10-01から1ヶ月間の記事一覧 - ふり返る暇なんて無いね仕事10月は端境期だったので、技術検証をメインでやってました。技術メインブログの方はどちらかというとパブリック向けに書いてます。ただ、この方針だと記事がゆるい記事が書きにくくなってきたので、サブブログを作った経緯があります。サブブログの技術記事は他の誰かのためではなく未来の自分が思い出すために書くをモットーに書いてます。なのでゆるく、細かい系のことも気軽に書いてます。分からないことは分からないと明示する。途中でも経過を残す。恥も残す。そんな感じです。以前とくらべてGoogle Cloud回りを10月はいじってた感じですね。build-in commandのmanが引けなくて困った - ふり返る暇なんて無いねt3系インスタンスのスペックについて - ふり返る暇なんて無いねGoogle Cloudの外部HTTP(S)ロードバランサと外部HTTP(S)ロードバランサ(従来型)の違いがわからなかった。 - ふり返る暇なんて無いね未解決: Google Cloud Storageの静的配信でnginxで言うところのtry_files的なことをしたかった。。。。 - ふり返る暇なんて無いねはてなブログのカテゴリごとのRSSフィード - ふり返る暇なんて無いねGitHub Actionsで save-state とset-output が廃止されるようです。 - ふり返る暇なんて無いね故障と障害の違いがわからずに困惑してた - ふり返る暇なんて無いね資格PCA取りました!11月にはPCA、KCNA、年内にCKA、CKADを取ることを目標に業務とは別に学習してます。なお、業務ではGoogle CloudもKubernetesも今のところ触る余地ないです。が、将来の投資として学習してます。近い未来で使うのが目に見えてるので。Google Cloud認定 Professional Cloud Architect合格してた - ふり返る暇なんて無いね11月末ターゲットで2個資格試験受けます - ふり返る暇なんて無いね旅土曜日の午前中に温泉入るのにはまってます。休日の早い時間に行動すると時間の有効活用ができるなとしみじみ感じてます。人生に疲れたので熱海で温泉入ってきた - ふり返る暇なんて無いね横須賀で温泉入ってきた - ふり返る暇なんて無いね江ノ島に行ってきて午前中だけで満足した - ふり返る暇なんて無いね生活寒くなりましたが、がんばります。今季初暖房使いました。 - ふり返る暇なんて無いね技術書を複数回読むということ - ふり返る暇なんて無いねワクチン4回目打った💉💉💉💉 - ふり返る暇なんて無いね11月に向けてといっても11月始まってますが。11月は資格の勉強もあるし、新しい固めのお仕事も始まるので、だいぶヘビーになる予感を感じてます。寒くなる季節なので体調には気を付けつつも、引き続き温泉につかり、ブログ書くのも続けて行きたいですね。

2022年10月のふりかえり、まとめ

kichijojipm.connpass.com久しぶりにLTしてきました。久しぶりに外で発表したいなと思いつつ、だいぶブランクあるのでちょうどいいリハビリできるところがないかな。— masasuzu (@masasuz) 2022年4月9日  こんなこと考えてたら良いタイミングできちぴーが開催されるので、LT申し込んでみました。#kichijojipm 7年ぶりにLTしたので緊張した。というのと、前回の発表調べて7年前もきちぴーあったのかという驚きもあった。— masasuzu (@masasuz) 2022年4月12日  どうやら7年ぶりだったみたいです。タイミング的に最終出社日の翌日だったので、キャリアの話をしました。diary.masasuzu.net正直、LTにおさまる量じゃなかったのは反省点です。資料ももうちょっとなんとかできたかなあという気持ちがあります。少しずつ登壇回数増やして、勘を取り戻していきたいところ。

吉祥寺.pm29で久しぶりにLTしてきました #kichijojipm

jawsug-sre.connpass.com聞いてきましたのでメモと感想を残しておきます。LTマネーフォーワードのマイクロサービス基盤のこれまでとこれから by マネーフォワード @grezarjpマネーフォワードのマイクロサービス基盤の移り変わりの紹介。中央集権構造 => 権限移譲フェーズ => これから中央集権構造サービスごとに開発チームが存在、サービスにまたがってインフラチームが存在開発チームはインフラを気にしなくてもすんだ。メンバーが少ないうちはなんとかなった組織の規模に対してインフラチームがスケールしなくなった責務の分解点を再定義 DevOpsへ権限移譲フェーズ開発チームに権限を渡していくAWSとKubernatesを使用ランタイム、ミドルウェアも開発チームが管理サービスごとにNamespaceを切る、Namespace内で開発チームは権限を持つマイクロサービスごとにAWSアカウント管理して、リソースを管理するこれから権限は渡したが、運用まではむつかしい開発の運用を負荷を下げるためにTerraformのモジュール化、設定のバリデーションの整備AWSアカウントの統制、コスト可視化を進めたいアプリケーションランタイムのSnadbox化特殊要件なアプリケーションで使えるように開発チームにここまでインフラの権限を渡せて、運用できるのはすごいなと思った。QAQ: 開発チームの権限移譲の苦労、運用面、技術面A: マルチアカウントをつかって 技術上の考慮点があった人と人とのかかわりに関しては銀の弾丸はないので、地道な作業が必要ドキュメントとかで監視項目を揃えてあげるのに力を入れたQ: 開発とインフラでスキルセットの違いはあった?A:インフラはアプリをあんまり見てこなかったのでそのへんのギャップはあったQ: EKSのテナント分割の単位A: 権限分類と障害の影響範囲の最小化はシングルテナントが有利とは言われるが運用負荷を下げるためにマルチテナントを選んだSREグループのマネージャーという立場になって真っ先にやったこと by ミクシィ@isaoshimizu内容に関しては、スライドに詳しく書いてあるので参照。SREのミッション・バリューいいなあと思った。うちのチームでもちゃんと考えたい。SRE Lounge #13 LTでも今回と近いことを書いてるので参照してほしいとのこと↓組織にSREの文化を作り上げていくEnabling SRE | Money Forward Engineers' BlogQAQ: SRE主導でやるべきではなかったことA: SREは万能な人がおおくでできてしまう開発側のリソースが足りなくて急がないといけないことをSREがやってしまう本来はそうじゃないよねって話自分としては、SREでも開発分野でも巻き取れることはやってしまってもいいと思うんですよね。線を引きすぎるとセクショナリズムになってあまり良くない気がしてる。組織のあり方はそれぞれで、コンテキスト分かってないので、言い切ることはできないですが。Containerサービス と Toil と by スリーシェイク  @tt0603ECSとEKSについてToilと紐付けての話題。Toilの削減ステップ特定計測削減ただこのプロセスはつらい。SREとしては長期的なエンジニアリング に時間を使いたい。本質的なことをすることが目的。Toilを削減することが目的ではない。技術選定として、まずマネージドで考える。チームとして何を大事にしているかを考える。自分たちの”サイズ”で技術選定をして価値あるエンジニアリングをする。個人的にはEKSとECSのまとめがわかりやすくてよかった。QAQ: セルフホステッドを選択する場合は?A: 監視するとき Prometheus使うときとかつらいのでFargateは起動が遅い スケールが遅い技術選定において、自分たちの「サイズ」っていう要素が存在するというのは暗黙的なものになりがちなので、ちゃんと具体的に捉えておくの大事な気がした。 #jawsug_sre— Tomoya Kitaura (@kitta0108) 2022年2月25日  先程はパッと答えられませんでしたが、弊社の場合はMicroServiceを運用する際にはIstioを利用するケースが非常に多く、現状では対応していないため、EKSの場合はSelf Hostedを利用するケースが多いですー#jawsug_sre— TakuyaTezuka@3-shake (@tt0603) 2022年2月25日  パネルディスカッションMFのSREの組織のやり方で工夫してるところもともと中央集権的だった、開発に権限移譲していった権限を渡していっていながらそれ以上にプロダクトが開発が増えてしまったので負荷が増えてしまったenabling SREを広げる役割もつくるSREというポジションじゃなくてもSRE的な動きができるように組織にSREの文化を作り上げていくEnabling SRE | Money Forward Engineers' Blog技術支援からSREの組織変数がいくつか システムの規模 性質 組織規模、レベル感などpure sreではじめて権限移譲していく自分たちのサイズに合わせて組織を作っていく開発とSREのベストの距離感タイミングによって違う固定されたものじゃない構成をいかにシンプルにできるかが大事SREが開発に使いやすいサービスを提供するSREのAPIを提供するので好きに使って的な横断組織SREと開発チーム内SREというパターンもあるお互いのコミュニケーションは大事採用する際に求めるスキルセットやレベル感なんでもかんでも能力を持ってる人はいない。特定の領域に得意を持ってるといい、最低限のレベル感はほしいコミュニケーション 大事 ソフトスキルの担保が大事会社のバリューにあってるかSREワークブックの最後の方求められるスキル書いてあるすべてのインフラコードはIaCに寄せたい、チームにはソフトウェアスキル、インフラスキルそれぞれ持つメンバーがほしい変更時のトラブルシューティングはできるべきコードレビューできるスキルを持っていてほしいコーディングあるていどできる人組織による開発をSREに興味をもってもらうはどうしたらいいのだろうかSLOを決めて共通言語で話す留学すると面白いかもお互いがどういう観点で仕事してるかがわかってよいどこまで開発に移譲するかエラーバジェット、SLO、SLIは必要SREが設定するSLOより開発者が設定するSLOの方がいい開発者にとってうまいところを教えるアプローチ開発者にとってもバグが出ないことによって、気持ちよく開発できるよ!開発者の観点じゃなくてビジネス観点でSLO設定するんじゃないのかなって思う。。。?あと、留学いいなあと思った。開発チームに留学したい。SREチームが存在しない。どんなフェーズになったらSREチームを作ったほうがいいというしきい値あります?開発者が開発以外に手を取られて開発スピードが落ちてるのが目に見えたら兼務の限界値がある。得意なことにバリューを出せるようにしたい開発しながらAWSの新機能をキャッチアップするのはたいへんdevとopsのバランスが崩れているとき SREのプラクティスをいれるといいのかもエラーバジェットが判断軸になるかもどれくらいのチームが困ってるかが判断軸になるToil撲滅の意味で費用対効果高かったLambdaランキング今Lambdaを殆ど使ってないchatbotが出たのでLambdaの役割を終えたEKS上にアプリケーションを作ってしまうことが多い必要悪としてのLambda コードを書くのは最終手段。書いた瞬間に負債になる時刻でEC2終了するLambdaオートスケーリングでいいのでは?terrafromでLambda扱いにくい問題SREとしてセキュリティに対しての役割サービスInspectorECRのイメージスキャンCI/CD成立してからじゃないとイメージスキャンできないGuardDutySSOIAM Userを撲滅できたただ個別要件に対応しにくいSREが見てるケースが多いコーポレートセキュリティは範疇じゃないが、アプリケーションセキュリティは範疇5,6人目にセキュリティが強い人がほしい着想の段階からセキュリティの観点をいれておきたいモニタリングロギングの観点で使用してるAWSのサービスAMPEKS使ってるのでコスパが良かったCloudWatch log通知考えるとLambda使わないとAthenaわずらわしい検索しにくいLokiとかに寄せたいログをどこにおくS3Lokiってこれかな?Grafana Loki | Grafana Labs雑感他の会社のSREの話を今まであまり聞くことがなかったので、気づきを得る部分が多かった。SREのミッション・ビジョン・バリューはちょっと考えてみたいなと思った。オンライン開催の形式はYouTube Liveがいいなあって思った。聞き逃しても巻き戻して聞き返せるのがすごい体験として良い。

JAWS-UG SRE支部 #2 突撃！となりのSRE

future.connpass.com久しぶりにちゃんと勉強会の感想ブログ書きます。① State の分割戦略 〜ModulesとWorkspacesを利用して〜StateはTerraform上での管理を分ける意味では非常に重要な要素であり、適切に分けることで不慮の事故や予期せぬ変更からクラウドリソースを守ることができます。このセッションでは演者が実際にTerraformを利用して感じたことを交えながら、適切なStateの分割戦略とは？について話します。Stateの分割についてModuleによるアプローチとWorkspacesによるアプローチ、そしてそのあわせ技についての説明がありました。Workspacesは使ったことないのであまり知見がなかったので、いろいろ参考になる部分がありました。今のterraform運用だと環境ごとにディレクトリを切ってstateを分割してます。で、環境ごとの差異としてパラメータだけでなく、作るリソース作らないリソースが若干まちまちなので、そのままだとWorkspacesは向かないなと感じました。絶対に作るリソース、RDSやVPCなどは分割した上でWorkspacesで管理するのはありなのかなとは思いました。ただ、同じシステムで、環境毎のディレクトリとリソース毎のディレクトリが混在するのはわかりにくくならないかなという懸念はあります。悩ましいですねあと、ブランチ戦略も難しいですね。現状はmasterでprdをapplyするように、stagingでそれ以外の環境をapplyするようになってますが、全部masterでやるようにしても良いのではと思ったりもしてる今日このごろです。② クラウドリソース自体をdestroy/createdせずに、Terraformリソース定義の記述場所を変更する方法クラウドサービス上で稼働するリソースには一切手を付けずに、Terraformの定義記載場所だけを変更する方法を話します。Terraformを利用していると「このディレクトリ配置じゃダメだ。配置変えしたいのだけれど、リソースの再作成はできない。次にインフラ設計するときは、〇〇に注意しよう」という運用ナレッジが貯まると思います。スタート時点で完璧なTerraformディレクトリ設計ができれば御の字ですが、それが不可能なことは、この分野でベストプラクティスが確立されていないことにより証明されています。本パートでは「Terraformのディレクトリ配置には定石がないのだから、運用状況に合わせて柔軟に配置換えすべき」という観点から、「動作中リソースに影響なく、Terraform定義箇所を移植する方法」について話します。20220217_FutureTechNight_#20_TerraformState縛りの勉強会.pptx - Google スライドこんなふうに別のtfstateファイルにリソースをmvすることによって、Stateにリソースを移動できる手法を説明してました。terraform state mv -state-out=${moved_resource.tfstate} ${moved_resource}terraform state pull > ${to.tfstate}terraofm state mv -state=${moved_resource.tfstate} -state-out=${to.tfstate}terraform state push ${to.tfstate}State間でのリソース移動に関しては、terraform state rmとterraform importのあわせ技しか知らなかったので、新しい知見を得ました。まだ試せてないないんですが、State内での移動であれば、moved block使うのもありなのかなと思いました。ちなみリソースが消えた場合にもmove blockって使えるんですかね?なかなか他の会社のterraform運用の話を聞く機会があまりなかったので、楽しかったですね。最近勉強会出てもメモすら残さないことが多くて、せっかく参加したのにあまり有意義に時間を使えていなかったので、薄くてもいいので今後ちゃんと感想、意見を書き残していきたいと思いました。

Future Tech Night #20 Terraform State縛りの勉強会 #future_tech_night

株式会社モバイルファクトリーを3/31で退職してました。2010年6月入社なので9年10ヶ月になりますね。今は新しい会社のSREチームで働いています。前半数年間はケータイ向けのサイト(いわゆる着メロサイト)やソーシャルアプリの開発運用をしていました。後半数年間は社内全体の開発基盤・運用基盤の整備をしていました。いわゆるインフラよりのお仕事ですね。入社当時Webアプリケーション開発をまったく分かってなかったところからなんとか人並みに運用開発できる力をこの会社で身につけることが出来たと思います。今なんとかwebエンジニアをやれてるのはこの会社のおかげと言っても過言では無いと思っています。入社当時SQLをまともに書けなかったくらいのレベルだったのでよく採用されたなと。。。お仕事的には回りのレベルも高いし、自身の仕事のやり方も裁量を与えられていたし、社内環境も、待遇も悪くなかった。むしろ良かったくらいでした。ただ、長年勤めていく内に悪い意味での慣れが出てきて、自分自身停滞感を感じることが出てきました。ここ数年が特に感じることが多く、停滞感から来る焦りを日々感じていました。どうにか停滞感を解消するために副業として他社のお仕事を請け負ったりしていましたが、どうにも解消ができずにいました。そんな折に現職のSREチームの話をいただきました。実際に面談、面接を受けて、課題や環境の話を聞くにつれて、ここでなら一歩進めるのではないかという感触を得ました。もちろん焦燥感、停滞感はあれど、居心地が良いと感じてた今までの環境を変えることにはかなりの葛藤がありました。いろんな決め手はあったのですが、新しい場所の方が一番の下手*1でいれそう、なにより事業的にも業務的にも仲間的にもワクワクできそうというあたりが決定打になりました。入社して2週間しかも、初日以外ずっと在宅勤務なのでまだ様子が摑めてないですが、早くキャッチアップしてバリバリ成果を出していきたい所存です。これからもよろしくお願いします。例のもの置いておきます。気が向いたらでよいです。https://www.amazon.jp/hz/wishlist/ls/3S4C1LCDWKCTM?ref_=wl_share*1:情熱プログラマ参照

3月末日で退職してました

tech.mobilefactory.jpだいぶ前に受けたArchitecting on AWSの聴講記録です。

キャリアアップ支援制度を利用してArchitecting on AWSを受講しましたというアドベントカレンダー書いてました

tokyo.gdgjapan.org珍しく、何も予定が入ってない土曜日だったので、行ってきました。最近GCPを触る機運が出てきたのでちょうどいいタイミングでした。以下メモGCP 101 | 坂田 純 | GDG DevFest Tokyo 2019主にCloudRunの話。HTTPをlistenするコンテナを起動するサービス。使った分だけ課金対象となる。リクエスト数次第で自動的にスケールする。とお手軽にできそうな印象。インターフェースがHTTPなので基本的にはパブリックでアクセス出来てしまうが、--no-allow-unauthticatedオプションをつけてデプロイするとで限られた人だけ実行できるようになります。これでバッチ的なことができそう?マイクロサービスの開発とテストファースト/テスト駆動開発 | 柴田 芳樹 | GDG DevFest Tokyo 2019ちょいちょいブログとかは見てましたが、話を聞くのは初めてでした。還暦を迎えてもコードをバリバリ書いてるのは素直に尊敬します。メルペイのマイクロサービスのテストにも興味深かったですが、組み込みでのテストの話も興味深く聴かせてもらいました。ツールや環境の充実度の差はあれど、組み込みでもウェブでもやるべきことは同じなのだなと思いました。CloudNative 時代における GKE/Kubernetes ではじめる開発 | 青山 真也 | GDG DevFest Tokyo 2019k8sの紹介的な話。k8s好きになりました。話がすごいうまくて、めんどくさそうだなあと思ってたkubernetesの印象が変わりました。その他:D社のブースを覗いたらMOVの構成図が展示されていて、IoT関連だけAWSを使っていてそれ以外はGCPを使ってるのが興味深かった。IoT関連のものも別で実装して、AWSからは引き上げるようなことを言ってて、なるほどなあとなりました。基本的にAWSで構成されたインフラばかり見てたのでなかなか新鮮でした。

GDG DevFest Tokyo 2019に行ってきた

ちょっと過去の話ですが、会社の技術ブログで書いてました。tech.mobilefactory.jp

モバイルファクトリーのインフラアーキテクチャというアドベントカレンダー書いてました

この記事は、モバイルファクトリー Advent Calendar 2015 18日目の記事です昨日は@yashims85さんのAndroid drawableは画像を入れておくだけじゃないでした。今日は障碍の話です。普段障碍対応しているときにやってること考えてることをざっくりと時系列を追って書いていきたいと思います。コンテキストとしてはLinuxサーバでwebサービスをやっていると思っていただければと思います。障碍の検知webサービスを運営していれば、何かしらの監視システムからSlackなりIRCなりメールなり電話なりでアラートの通知が来ると思います。対応報告障碍対応をしている旨をメールなり、何かの連絡手段で伝えます。同じく見ている人がいれば調査作業の分担もできます。状況把握どこで障碍?アラートの通知内容にどのサーバで何が起きた的なことが書いてあるはずなので、それを確認します。だいたいの組織に於いてはサーバ管理表的なものがwebなりExcelなり設定ファイルなりにあるはずなので、そこと照らし合わせてどのプロジェクトのどのロールなのかを把握します。直前に何をした? いつもと違うことは何?webアプリケーションであれば直前に入れた変更が原因かもしれません。また、ちょっと前に入れていた変更だが、cronで時限発火したというケースも考えられるかも知れません。イベント開始で急にトラフィックが上がったと言うことも考えられるかも知れません。普段と変わったことは何かということが把握出来れば対処の幅が広がります。影響範囲は?サービス全体なのか、サービスの1機能の障碍なのか、ミドルウェア障碍なのか、影響がどの範囲に及んでいるのかを見ます。ミドルウェア障碍であれば、最近であれば、冗長化されてるのが普通なので、サービスから切り離して、監視から外せば終わりというパターンも多いです。サービス全体が落ちている場合は、ひとまず重要な関係者に状況の1次連絡すぐにした方が良いでしょう。接続出来る?そもそも、該当サーバに接続出来ない場合は、できることはほぼないので、該当サーバをサービスから外した上で、監視対象から外します。(単体のサーバ障碍の場合)# pingは通る?ping ${IP}# sshできる?ssh ${IP}ログの確認該当サーバ上で動いているミドルウェアやアプリケーションサーバのエラーログを主に見ます。だいたいこの辺に重要な情報が出力されている可能性があります。システムのログも確認した方が良いです。主にsyslogやkernelログを見ると良いでしょう。# syslogを見るless /var/log/syslog# kernelログを見るless /var/log/kern.log# kernelログを見る2dmesgサーバ状態の確認負荷の関係で障碍が起きているのであれば、現在のサーバの状態を確認しましょう。以下のようなコマンドが現状把握に役立つでしょう。# loadaverageおよびログイン中のユーザを見るw# 変なプロセス無いか見るps -ef# orps auxwwww# 開いているポートを確認するnetstat -tlnp# ネットワークコネクションを確認するnetstat -taopen# なにかCPU使いまくってないか見るtop# 現在の負荷の経過を見るdstat -tamsl 5# 過去の負荷情報を見る## CPUsar## memorysar -r## lasar -q対処直前のコミットにバグを入れ込んでしまったのであればリバートすれば解決するでしょうし、特定のサーバ落ちたのであれば、サービスから外してあげるだけで良いかも知れません。障碍の内容によって対処方法は様々です。ここで気を付けたいのは二次災害を起こさないことです。可能であれば、コマンドなり対処スクリプトのレビューをしてもらったり、現状認識に間違いがないかを周りの人にしてもらうと良いでしょう。(往々にして一人で障碍対応せざるを得ない場合もありますが。。)事後報告障碍対応が終わったら、記憶が新鮮なうちに下記の内容をまとめてしかるべき場所に投稿します。この辺の報告のフォーマットはだいたいの組織において決まっていることが多いでしょう。障碍内容影響範囲経過対処方法将来の対策面倒くさがらずに事実をなるべく詳細に書いておくと未来の自分や自組織のためになると思います。私の組織でも過去の障碍報告がだいぶ良い感じにデータベースになっており、たまに読み返すと気付きが得られます。また、この障碍報告を元に、同種の障碍をなるべく起こさない仕組み作りをしていくことが肝要だと思います。終わりに自分が障碍対応しているときにやってること、考えてることをざっくり書いてきました。誰にやり方を教わったわけでもないので、そこは違うとかこうした方がいいとかあれば、いただけると幸いです。明日は、@lycoris102さんのGameJam部 活動年間活動報告です。きっと面白い話なのではないでしょうか。

障碍対応と私

参加しました。雑なスライドですみません。スライド中に出てきてるやつはどれも五反田のお店で出てきます。五反田企業のガイアックスさんとかモバイルファクトリーさんはPerlの会社なので、美味しいごはんを食べたい人は検討してみてはいかがでしょうか。そういえば、Chiba.pmの開催回数がKichijoji.pm、Gotanda.pmに抜かされそうです。。

#chibapm Chiba.pm#7に参加しました。

この記事は、モバイルファクトリー Advent Calendar 2015 11日目の記事です※ 投稿内容は私個人の意見であり、所属企業・部門見解ならびに技術戦略を代表するものではありません。昨日は@rymizukiさんのnpmライブラリの運用と管理についてでした。今日はPerlの話です。お仕事やプライベートでPerlのwebアプリケーションを書くことが多く、いろいろ知見が溜まってきてるので、ここで少し紹介しようと思います。今回はPlack/PSGIなwebアプリケーションの実行環境の話です。mod_perlなアプリケーションとはちょっとコンテキストが違います。少しかっちりコンテキストに近いです。個人で軽くwebアプリケーション立てるならもう少しゆるふわでも問題ないはずです。OSUbuntuのLTSを使うことが多いです。Ubuntu前提の内容が後に続きます。PerlSystem Perlは使ってません。OS/ディストリビューションが変わってもなるべくそのまま動くようにしたいためです。perl-buildで独自ビルドしたPerlを使います。インストール場所としては、 /usr/local/perl/perl-5.${VERSION} に置きます。Perlを独自ビルドしたものをDebian package化して実行環境にはインストールします。他の方法としては、ビルド済みのperlをtarで固めて、配布するというのもあります。どちらでも構わないのですが、ローカルネットワークにaptサーバ立てている関係で、Debian packageの方が運用しやすいのです。また、perlのマイナーバージョンアップの際もDebian packageを作り直した上で、 apt-get upgrade (or aptitude safe-upgrade)で完結するので、aptの操作に慣れていて楽というのもあります。モジュール管理今風にcpanfileでモジュール管理してます。モジュールインストールはCartonを使ってます。Cartonの後継でCarmelも開発されてます。個人的にはそろそろ触っておきたいところです。また、cpanfile.snapshotもレポジトリに入れています。一般的なモジュールは特定の(古い)バージョンに依存せずに動くべきですが、依存モジュールのバージョン違いによって現在動いているアプリケーションが壊れるのを防ぐために、バージョン固定します。cpanfile.snapshotがある状態で下記のように carton install してあげると、どの環境でも同じバージョンのモジュールがインストールされます。carton install --deployment --without develop,test今やってないですが、別方法としては、モジュールがインストール済みの状態で、 carton bundle すると vendar/ にモジュールのtarが固められるので、それもレポジトリ管理した上で、下記の様にインストールするという手もあります。インストールの際は vendor/bin/carton  にfatpackされたcartonコマンドが入るのでそれを使います。(アプリ実行環境にcartonを敢えて入れる必要は無い)# 依存モジュールを固めるcarton bundle# インストール# env.shは後述./script/env.sh vendor/bin/carton install --cached --deployment --without develop,testさらに別方法としては、ビルドサーバで依存モジュールをビルドした上で、ディレクトリごと実行環境にrsyncしてあげる方法です。ビルドサーバを運用しているならば、この方法でも良いでしょう。参照Carton考2014carton bundle && carton install --cachedの使いどころ独自モジュールなるべく、独自モジュールは使わない方が良いのですが、個人的な事情などで、CPANに公開出来ないモジュールに関しては、OrePAN2 でDarkpanを作ってそこからローカルに配信するようにしてます。OrePAN2のサーバを簡単に立ち上げられるOrePAN2::Serverがありますが、一時期は使っていましたが、モジュールのアップロード機能は別にいらないなどの理由で今はwebサーバから静的配信してます。環境変数プロジェクトのレポジトリに config/env.rc という名前で、アプリケーションを動かすために必要な環境変数を定義したファイルを作ります。PERL5_VERSION="22"export PROJECT_BASE="/path/to/project"export PERL_CARTON_MIRROR="http://orepan.local/"export PERL5LIB="${PROJECT_BASE}/local/lib/perl5:${PROJECT_BASE}/lib"export PATH="${PROJECT_BASE}/local/bin:/usr/local/perl/perl-5.${PERL5_VERSION}/bin:${PATH}"export PLACK_PORT=5555また、 script/env.sh という名前で config/env.rc を読み込んだ上で、プログラムを実行するラッパースクリプトを作ります。スクリプトなどは基本的にこれを通して実行します。#!/bin/bash -ue# 諸々環境変数を設定した上でコマンドを実行する君##       env.sh perl hogehoge.pl#source /path/to/project/config/env.rcexec "$@"開発環境で、いちいちラッパースクリプト通すのが面倒な場合は、config/env.rc のsymlinkをプロジェクトルートに .envrc として張った上で、direnv使って済ましてしまう場合もあります。web サーバ起動スクリプトpsgiファイルを plackup するのではなく、こんな感じのスクリプトをscript/web みたいな名前で 用意してアプリケーションサーバを起動するようにしてます。#!/usr/bin/env perluse strict;use warnings;use lib "$ENV{PROJECT_BASE}/lib";use Plack::Loader;use SomeApplication::Config;use SomeApplication::Web::Handler;my $config = SomeApplication::Config->load();my $app    = SomeApplication::Web->to_app();Plack::Loader->load(    $config->{psgi}->{server},    %{ $config->{psgi}->{config} },)->run($app);また、このスクリプトをstart_serverを経由して起動することで、(graceful restartによる)ホットデプロイをできるようにしてます。start_server のプロセスにSIGHUPを送ると子プロセスのアプリケーションサーバを再起動してくれるのですが、 plackup コマンドで起動してると start_server に渡した引数をそのまま使ってplackup を再起動するので、 max_workers の数を変えたいときなど、 start_server 自体のプロセスを再起動しなくてはならないので不便です。なので、起動スクリプトを作ってます。そのほかにも理由があるのですが、参照リンクに詳しくあります。サーバ実装としては、StarletやGazelleを使ってます。参照PSGI/Plackアプリケーションの起動方法いろいろと本番環境アレコレ普通に使う Plack/PSGI ServerGraduate from .psgiデーモン管理現在はUpstartでアプリケーションサーバのデーモン管理してます。以下の理由で、個人的には好きでした(過去形)。最新のUbuntuはSystemdに変わってしまったので、将来的にはSystemdに移行することになるでしょう。Ubuntuに標準で入っていてサーバ起動時の自動起動してくれてデーモン異常終了時に自動再起動してくれて設定はわりかしわかりやすい/etc/init/web-some-application.conf みたいな名前でこんな設定ファイルを作りますdescription 'some web application'author 'masasuzu <hogehoge@masasuzu.net>'start on runlevel [2345]stop on starting rc RUNLEVEL=[016]setuid webappsetgid webapp# 異常時に再起動するrespawnscript    . /path/to/project/config/env.rc    export PLACK_ENV="production"    exec ${PROJECT_BASE}/local/bin/start_server \        --interval 10           \        --port ${PLACK_PORT}    \        -- ${PROJECT_BASE}/script/service/webend script上記のファイルを作ると以下のように操作出来ます。reloadでSIGHUPが送れるので、アプリケーションサーバのstart_server経由のgraceful restartができます。# 起動service web-some-application start# 停止service web-some-application stop# (start_serverのプロセスごと)再起動service web-some-application restart# Plackサーバを再起動service web-some-application reloadアプリケーションサーバ以外も、ジョブのワーカーなども、独自に設定ファイルを作って、Upstart経由で起動したりしてます。Upstart以外の選択肢としては、先に挙げたSystemdの他、以下のものがあるでしょう。好みと要件に合わせて使えば良いと思います。daemontoolsSuvpervisordSystemd参照Server::Starterから学ぶhot deployの仕組みServer::Starter の --interval オプションは大切Upstart を使ってお手軽 daemon 化Upstart Intro, Cookbook and Best PractisesおわりにWAF(Web Application Framework)やログの話など膨らまそうと思えばもっと膨らませられますが、実行環境の話なので、ここまでで抑えておきます。ざっくりと、Plack/PSGIなアプリケーションの実行環境について説明してきました。PerlでWebアプリケーションを作る時に何か参考になれば幸いです。また、もっと良い方法があれば、教えていただけるとありがたいです。明日は、@nekobato さんです webpackのなにか面白い話があるんじゃないかとわくどきしてます。

Plack/PSGIなwebアプリケーションの実行環境

この記事は、モバイルファクトリー Advent Calendar 2015 4日目の記事です今日は、Github APIの話です。Githubの管理作業は他のWebサービスと同じく基本Webコンソールでできます。ただ、Organizationとかを管理してる場合、ある程度以上規模が大きくなると、定型的な管理作業が増えて、Webでぽちぽちやるには煩雑でつらくなってきます。ここで怠惰エンジニア*1はどうにかこの定型作業を自動化/スクリプト化できないかなと考え始めます。幸い、GithubにはAPIがあるので、これを利用して要件に合わせて、実装することができます。ドキュメントは以下の場所にあるので、各APIの使い方などはそちらを参照してください。GitHub API v3 | GitHub Developer Guideapiアクセスを投げるpublicな情報を取得するには普通にcurlでGET発行するだけで、取得出来ます。curl https://api.github.com/users/masasuzu/reposが、これだけでは、privateな情報にアクセスできません。ので、Basic認証をしてアクセスをします。curl -u ${USER}:${PASSWORD} https://api.github.com/orgs/some_privete/reposただ、この場合、このアカウントで出来ることが全て実行出来てしまうので、下記のリンクからアクセストークンを発行して、権限を絞ってAPIにアクセスするのが望ましいです。アクセストークンは作成時にしか見れないので、ちゃんと書き留めておくようにしましょう。Personal access tokensアクセストークンを使用した場合、下記の3つの方法で認証出来ます。curl -u :${ACCESS_TOKEN} https://api.github.com/orgs/some_privete/reposcurl -H 'Authorization: token ${ACCESS_TOKEN}' https://api.github.com/orgs/some_privete/reposcurl 'https://api.github.com/orgs/some_private/repos?access_token=${ACCESS_TOKEN}'ドキュメントに各API発行に必要なscope(権限)が書いてあるので必要なscopeだけ付与してあげると良いです。perlでの選択肢今までで、APIアクセスする手段を得ることはできましたが、シェルスクリプトで処理を組み立てるのは、無謀なので、使い慣れてるプログラミング言語で実装したいところです。当社ではPerlを使い慣れてるエンジニアが多いので、ここではPerlのクライアントを紹介します。現在のところ以下の2つの選択肢があります。PithubNet::Github私はPithubを使っています。使い始めた時期においてPithubの方が更新されてそうだったからです。が、今見るとNet::Githubも更新されてるように見えます。他の言語での選択肢特にプログラミング言語にこだわりが無いのであれば、githubがメンテナンスしてるoctokitを使うと良いと思います。RubyとObjective C、.Netに対応してます。たぶん鉄板だと思います。(しかし、octokitのこのサンライズというかバンダイに怒られそうなデザインは大丈夫なのでしょうか?まとめ煩雑で定型的な作業はGithub APIで自動化すると良いPrivateな情報の操作はアクセストークンを発行してAPIを発行するPerlにはPithubとNet::Githubのクライアントライブラリがあるこだわりがなければ、クライアントはoctokit使うと良い明日は、 @mihyaeru21 さんです。iOS回りの面白いエントリが見れそうです。*1:プログラマの3大美徳の1つ

Github APIを使おう

gotanda-pm.connpass.comGotanda.pmでLTしてきました。今回のテーマは障碍でした。半分ネタのトークです。JSTQB Foundation Level のシラバスに載っているソフトウェアテストの7原則をもじったやつです。JSTQB認定テスト技術者資格-シラバス（学習事項）・用語集-言ってみれば、サービスに対して継続的にテストするのが監視なのでテストに対する原則が監視に対しても言えるんじゃないかなーという軽い思いつきから生まれました。無理矢理な部分もありましたが、わりかし当てはまってる部分もあったのではないかと思いました。トーク中美味しいにおいがしてきてつらかったです。(このエントリは懇親会の前に書かれてます)#gotandapm 美味しそうなにおいがして辛い。。。。— masasuzu? (@masasuz) September 17, 2015ガイアックスさん会場提供ありがとうございました。

#gotandapm Gotanda.pm Perl Technology Conference #6 でLTしてきました。

今年のYAPC::Asiaは終わった。つつがなく終わりました。過去のエントリを見直すと2011、2012年は書くのサボっていたみたいでした。私のYAPC::Asia初参加は2010年で6回目の参加でした。#yapcasia YAPC::Asia 2014でボランティアスタッフやってきました - 目の前に僕らの道があるmasasuzu.hatenablog.jp#yapcasia YAPC::Asia Tokyo 2013に参加してきました。 - 目の前に僕らの道があるmasasuzu.hatenablog.jpYAPC::Asia 2010へ行ってきたよ。 - 目の前に僕らの道があるmasasuzu.hatenablog.jp今年のYAPCとの関わり方は個人スポンサー+ボランティアスタッフとして参加しました。個人スポンサーとしては4年目、ボランティアスタッフとしては3年目でした。今年のYAPCもすごい楽しかったです。特にここ1,2年でPerl関係の人たちの知り合いがすごい増えたので、いろんな人と話ができてすごい楽しかったです。トークの方は例年スタッフ業をやっていると聞けないので、(会場にいてもスタッフのお仕事に意識が行くので内容を聞き取れてないことが多い)、動画が上がったら気になっていたトークを追いたいと思います。さて、だいたい6年前からWebで、Perlでお仕事するようになってからYAPCにはいろいろなものをもらってきました。だからこそ、ボランティアスタッフをやったり、個人スポンサーになって自分がもらったものを間接的に他の人に与えられたらいいなと思ってやってきました。自分がもらったものを他の人も受け取ってもらえたらなら良いなと思います。YAPC::Asiaはいったん終わります。それ自体いろいろ思うところがありますし、残念ではあります。YAPC::Asiaが無くなっても地域PMなどのPerlのコミュニティ自体が無くなるわけではないので私も細々とコミュニティ活動していきます。ただ、全国的にPerlな人が集まってくるイベントが今のところ来年無いのは寂しいところです。もしどこかで動きがあるならお手伝いさせていただければなと思います。YAPC::Asiaお疲れ様でした。(初日の懇親会の後の二次会でいろんな人に迷惑かけてしまったようなのでものすごく反省しています。すみません。お酒気を付けます。。。会期中のつぶやきいくつかおしゃれなカップだ #yapcasia pic.twitter.com/NwWw30i3HW— masasuzu? (@masasuz) August 22, 2015#yapcasia Perl6！ pic.twitter.com/2tJh6irctZ— masasuzu? (@masasuz) August 22, 2015#yapcasia  壇上から。お疲れさまでした！！ pic.twitter.com/1MiU56gE4R— masasuzu? (@masasuz) August 22, 2015

#yapcasia YAPC::Asia 2015でボランティアスタッフしてきた

吉祥寺.pm (kichijojipm) #4 : ATNDatnd.org今回はPerlとPerl以外ということで、Perlの外の世界をつないでるもので一番最初に思いついたのがテンプレートエンジンだったので今回の発表になりました。自分のテンプレートの利用シーンは設定ファイルの自動生成ですね。テンプレートがあることで手作業で設定ファイルをいじる必要が基本的にはないので、手作業に起因ミスがないのが良いですよね。そのほかくりかえしの記述が必要なものもテンプレート使うと便利な場面が多いと思います。前回のLTが長すぎたので、真姫進行で行ったら、巻きすぎてしまいました。時間配分難しい。#kichijojipm 真姫すぎた。。— masasuzu? (@masasuz) July 10, 2015#kichijojipm 巻きすぎた。。— masasuzu? (@masasuz) July 10, 2015懇親会のお店はおしゃれな感じでさすが吉祥寺という感じでした。五反田とは違う。#kichijojipm 炙りマカレル pic.twitter.com/wpJTTnIvZF— masasuzu? (@masasuz) July 10, 2015他の人のスライドはこちらページからたどれると思います。吉祥寺.pm4終わりました - kichijojipm’s blogkichijojipm.hatenablog.com今回の吉祥寺.pmも楽しかったです。次回も参加したいです。余談1今回のKeynoteはAzusa Colorsを元にスライドを作りました。だいぶ良い感じにできました。ありがたいです。茜屋さんのイメージカラーのパープルを基調にしています。http://memo.sanographix.net/post/113681262780memo.sanographix.net余談2LTの途中で宣伝してましたが、五反田のモバイルファクトリーさんで7/31にCrystalの勉強会やるしいですよ。東京 Crystal 勉強会 #1 in 五反田 (2015/07/31 19:30〜)crystal.connpass.comGotandaは今技術的に熱い街です。そのほかGotanda.pmや五反田Perlみたいな勉強会も様々行われてます。

#kichijojipm 吉祥寺.pmでLTしてきた

7月にとうとうなりました。ざっくりふり返ります。お仕事mod_perl to PSGI/Plackこの四半期のメインタスクでした。弊社2事業部あるんですが、そのうちの片方の事業部のmod_perlアプリをPSGI/Plack化しました。後は事業部の人がちゃんとテストして、本番反映するだけです。もう一個の事業部のmod_perlアプリケーションは次の四半期に取りかかる予定です。雑感としては、mod_perl特有の機能はほぼ使ってないので、そんなに辛くは無かったです。どちらかというと、使っているモジュールが古すぎたり、SledgeのPlugin地獄だったりしてアプリの実装の方でちょこちょこはまることが多かったです。このあたりの話です。#gotandapm Gotanda.pm Perl Technology Conference #4 話してきた話 - 目の前に僕らの道があるmasasuzu.hatenablog.jpGitbucket地味にアップデートが出る度に追従してました。しかしながら、そこそこでかいレポジトリをGitbucketで管理するのはだいぶつらいことが見えてきました。まず、レポジトリブラウザが鬼のように重い。1日数10コミットするようなレポジトリだとまともに使えないので、ちょっと移行先を考えてます。Elasticsearch  + Kibana4Kibana4入れました。Kibana3もまだ稼働中ですが、Kibana4で十分かなという気分です。Kibana4はすごい便利なので、そのあたりの話もどこかで一度したいです。開発環境の改善OrePAN2::Serverを廃止して、社内モジュールは静的サーバ置いたり、一つサーバでマルチユーザが同居するようなレガシーな開発環境の改善とかもろもろやってました。この辺もあとでエントリ書きたいところ。新卒技術者のメンタリング新卒技術者に対して仕事外で困ってる事とかのお悩みの相談乗ったり、成長を促すお手伝いをしたいたりします。会社としてもメンター制度できたばっかりで、組織的にも自分的にもいろいろ手探り感があるのは確かです。自分が見ている人はかなり優秀で日々成長が見て取れるので、そこをさらに促せるようにしていけたらと思います。書いた記事こう見るとあまりエントリ残してないですね。もう少し書きたいところ。4月勉強会#kichijojipm 吉祥寺.pm #3 に参加してきました。 - 目の前に僕らの道がある技術ubuntu12.04でruby2.2.1のビルド失敗するのはlibffi-devが入ってないから - ふり返る暇なんて無いね$PATHを見やすく表示したい - ふり返る暇なんて無いね5月技術ポートが空いてるか調べたいとき - ふり返る暇なんて無いねサーバ起動時に/etc/init.d/ に設定があるデーモンを自動起動したい - ふり返る暇なんて無いねElasticsearchを1.4以上に上げたらkibana3がElasticsearchにConnection Failedする際の対処 - ふり返る暇なんて無いねポエム縮退運用という考え方 - ふり返る暇なんて無いねあなたは嫌いですか。でも僕は好きです。 - ふり返る暇なんて無いね6月勉強会#gotandapm Gotanda.pm Perl Technology Conference #5 でLTの高速化に失敗しました - 目の前に僕らの道がある技術MySQLのLINEAR KEY パーティションでPKで検索しても遅い場合 - ふり返る暇なんて無いねPerlモジュールのバージョン比較したい - ふり返る暇なんて無いねポエム普段の行動がものをいう - ふり返る暇なんて無いね判断と判断の変更 - ふり返る暇なんて無いね感覚値はあくまで感覚値 - ふり返る暇なんて無いね次の四半期お仕事的にはもう一個の事業部のPSGI/Plack化と開発環境の改善をメインにやってくと思います。ここ最近ちょっといろいろ腹に貯めすぎなので、もう少し心にゆとりをもっていけたらなとは思いまする。

SUZUKI, Masashi

2026-08-15 JAWS-UG 茨城 #16 Secrets ManagerにおけるSecret値の管理(Terraformの場合) / Secrets Manager Secrets

2026-07-28 3-shakeテックランチ Cloud Run のデプロイパラメータを考える / Cloud Run Deploy Parameter

2026-07-24 tfpolicyを試してみたのですが、、、、

2026-06-18 ecspressoのtfstate参照が便利すぎた話

2026-04-14 Jagu'e'r Cloud Native分科会 Terraform Stateにおけるシークレットの平文保存という課題とその解決

2026-03-27 #terminalnight 変数展開とコマンド展開でターミナル作業をスマートにする方法

2026-03-23 Ops-JAWS Meetup39 Session Managerを使ったセキュアなサーバーアクセス

2026-03-11 JAWS-UG 茨城 #12 改めてALBを便利に使う

2026-03-03 Jagu'e'r Tech Writer Meetup #19 登壇のネタ作りについて

2026-02-24 月末 Tech Lunch Online #10 Cloud Runのデプロイの課題から考えるアプリとインフラの境界線

2025年AWS Community Builderの活動報告

初めての海外カンファレンス(KubeCon NA 2024 in Salt Lake City)

2025-11-21 社内エンジニア勉強会改めて理解するVPC Endpoint

Google Cloud で目指すクラウド二刀流エンジニア講座第3回に登壇してきました。

2025-11-08 Security JAWS TerraformによるIAM Policy記述ガイド

2025-09-25 SRETT #13 ConftestによるTerraformのPolicy as Codeを試してみる

クラウド環境におけるシークレットの扱い

2025-09-19 クラウドにおけるシークレット管理

2025-08-05 Google Cloud Next Tokyo 2025 Cloud RunとCloud SQLの接続方式と事例

Google Cloud で目指すクラウド二刀流エンジニア講座第1回でパネルディスカッションに出てきました。

2025-06-20 PrivateLinkがNLBなしで作れるようになり便利になった

Terraform使いがOpenTofuについて入門してみる

2025-01-31 吉祥寺.pm 37 初めての海外カンファレンス

2025-01-24-SRETT11-OpenTofuについてそろそろ調べてみるか

AWS Signerにおけるコンテナ署名の実装

私とJagu'e'rと2025年から...

ECSのタグ付け認可とアカウント単位のオプトアウトの廃止

Terraformのtfstateについて考える

Terraform使いがPulumiに入門しました

Terraformのsopsプロバイダーを使用するだけで機密情報は守られるのか

吉祥寺.pm35 でLTしてきました。 #kichijojipm

AWS Control Towerを調べる

2026-08-15 JAWS-UG 茨城 #16 Secrets ManagerにおけるSecret値の管理(Terraformの場合) / Secrets Manager Secrets

2026-07-28 3-shakeテックランチ Cloud Run のデプロイパラメータを考える / Cloud Run Deploy Parameter

2026-07-24 tfpolicyを試してみたのですが、、、、

2026-06-18 ecspressoのtfstate参照が便利すぎた話

2026-04-14 Jagu'e'r Cloud Native分科会 Terraform Stateにおけるシークレットの平文保存という課題とその解決

2026-03-27 #terminalnight 変数展開とコマンド展開でターミナル作業をスマートにする方法

2026-03-23 Ops-JAWS Meetup39 Session Managerを使った セキュアなサーバーアクセス

2026-03-11 JAWS-UG 茨城 #12 改めてALBを便利に使う

2026-03-03 Jagu'e'r Tech Writer Meetup #19 登壇のネタ作りについて

2026-02-24 月末 Tech Lunch Online #10 Cloud Runのデプロイの課題から考えるアプリとインフラの境界線

2025年AWS Community Builderの活動報告

初めての海外カンファレンス(KubeCon NA 2024 in Salt Lake City)

2025-11-21 社内エンジニア勉強会 改めて理解するVPC Endpoint

Google Cloud で目指す クラウド二刀流エンジニア講座第3回に登壇してきました。

2025-11-08 Security JAWS TerraformによるIAM Policy記述ガイド

2025-09-25 SRETT #13 ConftestによるTerraformのPolicy as Codeを試してみる

クラウド環境におけるシークレットの扱い

2025-09-19 クラウドにおけるシークレット管理

2025-08-05 Google Cloud Next Tokyo 2025 Cloud RunとCloud SQLの接続方式と事例

Google Cloud で目指す クラウド二刀流エンジニア講座 第1回 でパネルディスカッションに出てきました。

2025-06-20 PrivateLinkがNLBなしで作れるようになり便利になった

Terraform使いがOpenTofuについて入門してみる

2025-01-31 吉祥寺.pm 37 初めての海外カンファレンス

2025-01-24-SRETT11-OpenTofuについてそろそろ調べてみるか

AWS Signerにおけるコンテナ署名の実装

私とJagu'e'rと2025年から...

ECSのタグ付け認可とアカウント単位のオプトアウトの廃止

Terraformのtfstateについて考える

Terraform使いがPulumiに入門しました

Terraformのsopsプロバイダーを使用するだけで機密情報は守られるのか

吉祥寺.pm35 でLTしてきました。 #kichijojipm

AWS Control Towerを調べる

2026-03-23 Ops-JAWS Meetup39 Session Managerを使ったセキュアなサーバーアクセス

2025-11-21 社内エンジニア勉強会改めて理解するVPC Endpoint

Google Cloud で目指すクラウド二刀流エンジニア講座第3回に登壇してきました。

Google Cloud で目指すクラウド二刀流エンジニア講座第1回でパネルディスカッションに出てきました。