さらば、静的クレデンシャル。GitHub OIDC連携で構築する「究極のセキュアCI/CD」
「GitHub SecretsにAWSのアクセスキーを保存している」というエンジニア諸君。今すぐその運用を捨てろ。
それは単なる怠慢ではない。「いつか漏洩する」という時限爆弾を自ら抱えているのと同じだ。 キーのローテーション忘れ、開発者の退職、ログへの誤出力。静的な認証情報は、どんなに厳重に管理してもリスクをゼロにはできない。
真のDevOpsエンジニアにとって、認証とは「管理するもの」ではなく「動的に生成するもの」だ。今回は、OpenID Connect (OIDC) を活用し、GitHub ActionsとAWSをパスワードレスで繋ぐ、現場レベルで即導入可能な「最強の認証基盤」を構築する。
—
1. なぜ「キー管理」は悪なのか？
GitHub Secretsに保存されたIAMユーザーキーは、一度流出すると被害範囲を特定するのが困難だ。一方で、OIDCを利用すれば、GitHub ActionsがAWSに対して「私はこのリポジトリの特定のブランチで動いているGitHub Actionsです」と身分証明を行い、AWSから一時的なロールを引き受ける。
この方式の圧倒的なメリット：
- 認証情報の排除: 長期的なキーがこの世に存在しない。
- 権限の最小化: アクションごとに有効期限付きの権限を付与できる。
- 監査ログの明確化: 誰が、いつ、どのワークフローでアクセスしたかAWS CloudTrailに完全記録される。
—
2. AWS側の設定：OIDCプロバイダーの構築
まずはAWS側でGitHubを信頼する門番を作る。Terraformで構築するのがベストプラクティスだ。
AWSへの信頼設定（GitHub OIDC Provider）
resource “aws_iam_openid_connect_provider” “github” {
url = “https://token.actions.githubusercontent.com”
client_id_list = [“sts.amazonaws.com”]
# GitHubの証明書サムプリント（固定値）
thumbprint_list = [“6938fd4d98bab03faadb97b34396831e3780aea1”]
}
特定のリポジトリのみを許可するIAMロール
resource “aws_iam_role” “github_actions_role” {
name = “github-actions-role”
assume_role_policy = jsonencode({
Version = “2012-10-17”
Statement = [{
Action = “sts:AssumeRoleWithWebIdentity”
Effect = “Allow”
Principal = { Federated = aws_iam_openid_connect_provider.github.arn }
Condition = {
StringLike = {
# 特定のリポジトリ、特定のブランチのみに限定するのが鉄則
“token.actions.githubusercontent.com:sub”: “repo:my-org/my-repo:ref:refs/heads/main”
}
}
}]
})
}
—
3. GitHub Actions設定：極限のYAML構成
設定ファイルは簡潔かつ再利用可能にするのがプロの流儀だ。`aws-actions/configure-aws-credentials` を使えば、魔法のように一時トークンが降ってくる。
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write # OIDCトークンの発行に必須
contents: read
steps:
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/github-actions-role
aws-region: ap-northeast-1
- name: Deploy to S3
run: aws s3 sync ./dist s3://my-production-bucket
—
4. プロの現場で差がつく「隠れたテクニック」
① GitHub CLI (`gh`) は必須ツール
ブラウザでポチポチするのはやめよう。`gh` を使いこなせ。
- `gh repo clone` は当然として、`gh run watch` を使うと、CIのログをターミナルから離れずに監視できる。
- 特に `gh pr checks` で失敗したテストを即座に確認するクセをつけるだけで、開発サイクルは2倍速くなる。
② VS Code 神プラグイン「GitHub Pull Requests and Issues」
ブラウザとエディタを行き来するのは時間の無駄だ。このプラグインを入れれば、エディタ内でPRのレビュー、フィードバック、コメントへの返信が完結する。コンテキストスイッチを最小化せよ。
③ `.github/CODEOWNERS` の徹底活用
「誰がどのファイルを触れるか」をコードで明示する。このファイルがあるだけで、チーム開発の心理的安全性は劇的に向上する。
.github/CODEOWNERS
/infra/ @devops-team
/src/ @frontend-team
.yaml @lead-engineer
—
結論：脱キー管理は「スタートライン」に過ぎない
OIDCによる認証の自動化は、セキュリティリスクを劇的に減らすだけでなく、「手動での鍵更新」という無駄なエンジニアリングコストを永久に消滅させる。
あなたが今書いているコードは、本当に「未来のメンテナンス性」を考慮しているか？
「動けばいい」という段階は卒業しよう。ツールを支配し、自動化の先にある「自動化すら意識しない開発体験」を目指せ。それが、我々エンジニアが目指すべき高みだ。
さあ、今すぐSecretsからAWSキーを削除し、IaCでOIDCプロバイダーを構築してほしい。それが、君のチームが「一流」になるための最初のステップだ。