こんにちは。DevOpsの世界へようこそ。
GitHub Actionsを触り始めると、必ず突き当たる「壁」があります。それが「秘匿情報の管理」です。
APIキーやDBのパスワードをコードに直書きするなんて論外ですが、GitHubのどこに隠せばいいのか？ `Organization Secret`？ `Environment Secret`？ 名前が似ていて混乱しますよね。
今日は、この「Secrets」の迷宮を攻略し、「本番環境でうっかりステージングのDBを破壊する」なんて事故を永久に防ぐための、プロの使い分け戦略を伝授します。
—
1. そもそも「Secrets」のスコープを理解する
GitHubのSecretsには、大きく分けて3つのスコープがあります。これらは「誰が・どこで・何のために」使うかを基準に選ぶのが鉄則です。
- Organization Secret (組織全体):
- 役割: 組織内の全リポジトリで共通して使うもの。
- 例: Slack通知用のWebhook URL、共通のクラウド認証情報（AWSのRole ARNなど）。
- Repository Secret (リポジトリ単位):
- 役割: 特定のリポジトリだけで使うもの。
- 例: そのプロジェクト専用のAPIトークン、テスト用DBの接続情報。
- Environment Secret (環境単位):
- 役割: 「ステージング」や「本番」など、特定の環境にデプロイする時だけ使うもの。
- 例: 本番用のDBパスワード、本番のAPIキー。
賢い先輩の教訓:
「とりあえず全部リポジトリに突っ込む」のは危険です。本番環境の認証情報は、必ず `Environment Secret` に隔離してください。これが「もしもの時の被害」を最小限にする防波堤になります。
—
2. 【実践】Environmentを使った極限の環境分離
GitHubの「Environments」機能を使うと、本番デプロイ時に「承認プロセス」を挟んだり、環境ごとに Secrets を分離したりできます。
ステップ1: 環境の作成
1. GitHubのリポジトリの `Settings` > `Environments` > `New environment` へ。
2. `production` という名前で作成し、`Required reviewers` に自分やチームの承認者を設定します。
3. `Environment secrets` を開き、本番用の秘匿情報を登録しましょう。
ステップ2: Workflowでの利用
以下は、環境ごとにSecretsを切り替える理想的なYAMLの設定です。
name: Deploy Pipeline
jobs:
deploy:
runs-on: ubuntu-latest
# ここで環境を指定。これだけで指定環境のSecretsしか読み込めなくなります
environment: production
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Deploy to Production
env:
# 本番環境のSecretのみがここに注入されます
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
run: |
echo “デプロイを開始します…”
# 本番環境へのデプロイスクリプトを実行
—
3. 「うっかりログ出力」を絶対防ぐフィルタリング技術
一番怖いのは、デバッグ時に `echo $DB_PASSWORD` して、ログにパスワードが丸見えになることです。GitHub Actionsは優秀なので、Secretsを環境変数にセットすると、自動的にログをマスク（ に置換）してくれます。
しかし、プロとして念のため、以下のテクニックも覚えておいてください。
1. スクリプト内で生の文字列を扱わない:
可能な限り、CLIツール（AWS CLIなど）の標準機能に渡すようにしましょう。
2. 独自のマスキング:
どうしてもログに出力せざるを得ない場合は、以下の魔法のコマンドを使います。
- name: Protect sensitive data
run: |
# 秘匿情報をマスクするコマンド
echo “::add-mask::${{ secrets.API_KEY }}”
# これを実行した後に echo $API_KEY しても、ログには と表示されます
—
4. 最後に：初心者が陥る「罠」へのアドバイス
最後に、これからCI/CDを組む皆さんに一つだけ伝えたいことがあります。
「Secretsは、リポジトリの設定画面で一度設定したら、二度と中身は見られない」という仕様を覚えておいてください。もし間違えたら、削除して作り直すのがルールです。これがセキュリティの「本質」です。
最初は面倒に感じるかもしれません。しかし、この「環境ごとの厳格な分離」こそが、チーム開発において「深夜のデプロイ」を怖くないものにする唯一の方法です。
まずは、自分のリポジトリで `production` 環境を作り、そこに一つだけダミーのSecretを入れて、Workflowから呼び出す練習をしてみてください。たったこれだけで、あなたは「コードを安全に動かす」ための第一歩を、確実に踏み出したことになります。
応援しています。困ったことがあれば、またいつでも聞きに来てくださいね。