https://blog.igeight.net/Recent content on igeight blogHugojaSun, 25 Oct 2026 00:00:00 +0000https://blog.igeight.net/posts/2026-10-25-git-commands-for-iac/Sun, 25 Oct 2026 00:00:00 +0000https://blog.igeight.net/posts/2026-10-25-git-commands-for-iac/<p>Terraform や CloudFormation を CI/CD で回していると、Git は「コードを保存する道具」ではなく <strong>変更を本番に届ける入口</strong> になります。 この記事では、インフラエンジニアが日常的に使うコマンドを、<strong>実際の出力例つき</strong> で運用の流れに沿って並べます。後半では設定とセキュリティ(名乗り・秘密情報の除外・誤コミットに気づく仕組み)も扱います。</p> <blockquote> <p>各コードブロックの上に <strong>Command</strong>(入力するもの)と <strong>Output</strong>(表示される結果)の見出しを付けています。 出力例のブランチ名・ハッシュ・ファイル名・人名・日付は説明用の架空のものです。</p> </blockquote> <h2 id="全体の流れ">全体の流れ</h2> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">main を最新にする → future- / fix- ブランチを作る → IaC を修正 </span></span><span class="line"><span class="cl"> → status/diff で確認 → add → commit → push → PR </span></span><span class="line"><span class="cl"> → (CI で plan を確認) → main にマージ → CI が apply </span></span><span class="line"><span class="cl"> → ローカルの main を pull して終わり </span></span></code></pre></div><p><strong>main に直接 push しない</strong> のが前提です。変更は必ず作業ブランチで行い、PR とレビュー、CI の <code>plan</code> を通してから main に入れます。</p> <h3 id="ブランチ名の命名ルール">ブランチ名の命名ルール</h3> <p>作業ブランチの名前は、<strong>目的を表す接頭辞 + 内容</strong> にします。</p>https://blog.igeight.net/posts/2026-10-25-aws-iam-identity-center-sso/Sun, 25 Oct 2026 00:00:00 +0000https://blog.igeight.net/posts/2026-10-25-aws-iam-identity-center-sso/<p>AWS を複数のアカウントで運用していると、アカウントごとに IAM ユーザーとアクセスキーを作って <code>~/.aws/credentials</code> に貼る、という運用になりがちです。 <strong>IAM Identity Center</strong>(旧名 <strong>AWS SSO</strong>)を使うと、アクセスキーを持たずに、ブラウザでログインするだけで複数アカウントの一時的な認証情報を取得できます。</p> <p>この記事では、<code>~/.aws/config</code> に SSO の設定がある環境を例に、次の順で整理します。</p> <ol> <li>IAM Identity Center の登場人物と全体像</li> <li>権限セットとアカウント割り当ての関係</li> <li><code>aws sso login</code> の裏側(ログインの流れ)</li> <li><code>~/.aws/config</code> の読み方</li> <li>日々の使い方</li> <li>トークンの有効期限と、つまずきやすい点</li> </ol> <blockquote> <p>旧名の名残で、CLI のコマンドや設定項目は今でも <code>sso</code> という名前です(<code>aws sso login</code>、<code>sso_start_url</code> など)。 コマンドの出力例は説明用です。アカウント ID・ユーザー名・ハッシュ値は実際の値とは異なります。</p> </blockquote> <h2 id="iam-identity-center-とは">IAM Identity Center とは</h2> <p><strong>複数の AWS アカウントへのサインインを、1 か所で管理する仕組み</strong>です。 「誰が」「どのアカウントで」「何ができるか」を Identity Center に登録しておくと、ユーザーはそこにサインインするだけで、許可されたアカウントとロールを選べます。</p> <p>IAM ユーザー方式との違いは次のとおりです。</p> <table> <thead> <tr> <th>項目</th> <th>IAM ユーザー + アクセスキー</th> <th>IAM Identity Center</th> </tr> </thead> <tbody> <tr> <td>認証情報</td> <td>長期のアクセスキー(失効させない限り有効)</td> <td><strong>一時的な認証情報</strong>(1〜12 時間で失効)</td> </tr> <tr> <td>ユーザーの管理場所</td> <td>アカウントごとに IAM ユーザーを作る</td> <td>Identity Center で 1 回だけ作る</td> </tr> <tr> <td>MFA</td> <td>アカウントごとに設定</td> <td>サインイン時に 1 回</td> </tr> <tr> <td>退職・異動時</td> <td>全アカウントで削除する</td> <td>Identity Center で無効化すれば全アカウントに効く</td> </tr> <tr> <td>キーの漏えいリスク</td> <td>ファイルに平文で残る</td> <td>残るのは期限付きのトークンだけ</td> </tr> </tbody> </table> <h2 id="登場人物">登場人物</h2> <p>まず用語を押さえます。</p>https://blog.igeight.net/posts/2026-10-25-amazon-linux-2023-package-management/Sun, 25 Oct 2026 00:00:00 +0000https://blog.igeight.net/posts/2026-10-25-amazon-linux-2023-package-management/<p>サーバーをセキュアに保つには、まず「何が動いていて、何がインストールされているか」を知る必要があります。把握していないものは、更新も削除もできないからです。</p> <p>この記事では、Amazon Linux 2023(以下 AL2023)の状態を確認する手順と、確認したあとにパッチを当てる・バージョンを上げる手順をまとめます。Ubuntu 版の記事と同じ流れで、<code>apt</code> を <code>dnf</code> / <code>rpm</code> に置き換えています。1〜5 章のコマンドはすべて読み取り専用です。システムを変更するのは 6 章と 7 章です。7 章では、2026 年 10 月に公開された PHP の脆弱性「PHP2Shell」を例に、特定のソフトウェアだけを緊急で更新する流れを追います。</p>https://blog.igeight.net/posts/2026-10-25-ubuntu-package-inventory/Sun, 25 Oct 2026 00:00:00 +0000https://blog.igeight.net/posts/2026-10-25-ubuntu-package-inventory/<p>サーバーをセキュアに保つには、まず「何が動いていて、何がインストールされているか」を知る必要があります。把握していないものは、更新も削除もできないからです。</p> <p>この記事では、Ubuntu の状態を確認する手順と、確認したあとにパッチを当てる・バージョンを上げる手順をまとめます。1〜5 章のコマンドはすべて読み取り専用です。システムを変更するのは 6 章と 7 章です。7 章では、2026 年 10 月に公開された PHP の脆弱性「PHP2Shell」を例に、特定のソフトウェアだけを緊急で更新する流れを追います。</p>https://blog.igeight.net/posts/2026-10-25-github-actions-oidc/Sun, 25 Oct 2026 00:00:00 +0000https://blog.igeight.net/posts/2026-10-25-github-actions-oidc/<p>GitHub Actions から AWS を操作したいとき、IAM ユーザーのアクセスキーを GitHub Secrets に入れていませんか。 <strong>OIDC</strong> を使うと、長期のキーを一切持たずに、実行のたびに短命の認証情報を受け取れます。</p> <p>この記事では、次の順で整理します。</p> <ol> <li>OIDC とは何か</li> <li>GitHub Actions と AWS はどうつながるのか</li> <li>自分の環境で試せる、最小限のテスト(所要時間は 15 分ほど)</li> <li>OIDC が使われるほかの場面</li> </ol> <h2 id="oidc-とは">OIDC とは</h2> <p><strong>OIDC(OpenID Connect)</strong> は、「ある主体が誰なのか」を、信頼できる第三者が <strong>署名付きの身分証</strong> で証明するための仕組みです。 身近な例は「Google でログイン」です。サイト側はあなたのパスワードを知らなくても、Google が「この人は確かに本人です」と署名付きで保証してくれるので、ログインを許可できます。</p> <p>ここで出てくる言葉は 4 つだけ覚えれば十分です。</p> <table> <thead> <tr> <th>言葉</th> <th>意味</th> <th>「Google でログイン」の場合</th> </tr> </thead> <tbody> <tr> <td>IdP(身分を証明する側)</td> <td>身分証を発行する</td> <td>Google</td> </tr> <tr> <td>利用する側</td> <td>IdP を信頼して、身分証を受け取る</td> <td>ログインしたいサイト</td> </tr> <tr> <td>トークン(JWT)</td> <td>署名付きの身分証。「誰が」「どこから」などの情報が入っている</td> <td>ログイン用のトークン</td> </tr> <tr> <td>クレーム</td> <td>トークンに入っている個々の情報</td> <td>メールアドレス、名前など</td> </tr> </tbody> </table> <p>GitHub Actions の OIDC は、これを <strong>人ではなくワークフロー(ジョブ)</strong> に当てはめたものです。 GitHub が IdP になり、「このジョブは、このリポジトリの、このブランチで動いています」という身分証をジョブごとに発行します。</p> <h2 id="github-actions-と-aws-の関係">GitHub Actions と AWS の関係</h2> <p>役割を整理すると、次のようになります。</p>