開発者は今でも API トークン、パスワード、認証情報をコードや .env ファイルに直接書き込み、Git にプッシュしています。個人プロジェクトでも本番でも同じです。
理由は単純です。自動化やデプロイのワークフローにシークレットを渡す適切な方法がないと、Git が唯一信頼できる選択肢に見えます。「あとで片付ける」。しかし Git に入ったものが本当に消えることはありません。
Git がシークレットに危険な理由
Git はバージョン管理システムです。コミットしたものはすべて履歴の一部になります。最新のコミットからトークンを消しても、過去のコミットには残っています。履歴はローカルリポジトリ、自動化エージェント、ミラー、フォークにコピーされます。シークレットがコミットに含まれた瞬間、それは露出したと考えるべきです。
リポジトリへのアクセスは、必要以上に広くなりがちです。外部委託者、一時的なコントリビュータ、テスト用フォーク — 見るべきでない認証情報を誰かが見られる可能性があります。
GitHub と GitLab は認証情報のスキャンを積極的に行います。プラットフォームがトークンを検知したら、侵害されたものとして直ちに失効させてください。
Git の代わりに必要なもの
シークレットは静的ファイルではありません。コードの外に置き、権限を制御し、ローテーションでき、環境ごとに分離できるアクセス資格情報です。
Vault や OpenBao を運用することもできますが、インフラ、保守、運用の負荷が伴います。
Semaphore には自動化ワークフローに直接組み込まれた Key Store があります。シークレットは次のいずれかに置けます。
- Semaphore の暗号化データベース（デフォルト）
- HashiCorp Vault、Devolutions、OpenBao などの外部ストア（PRO 機能）
シンプルな内蔵オプションを選ぶか、既存の企業向けシークレット管理と接続します。すぐ使えます。
Key Store が保存するもの
- API トークン
- SSH キー
- パスワード
- 環境変数
- JSON などの設定ファイル
シークレットはコードベースに触れません。ジョブの実行時にだけ注入されます。開発、ステージング、本番で別の認証情報を定義し、特定のユーザー、チーム、ワークフローにスコープできます。
実際の流れ
Key Store を作成し、シークレットを追加し、ワークフロー設定で参照します。Semaphore が実行時に値を注入します。
AWS へのデプロイでは、例えばアクセスキーはそのジョブが動いている間だけ、そのジョブを実行するエージェント上にだけ存在します。開発者はシークレットを見ません。Git には載りません。
例
UI から Secret を作成: Secrets → New Secret で変数を追加します。
AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY
ワークフローでシークレット名を参照すると、Semaphore が実行時に環境変数として注入します。
blocks:
- name: Deploy
task:
secrets:
- name: aws-credentials
jobs:
- name: deploy
commands:
- aws s3 sync ./dist s3://my-bucket
SSH 用には秘密鍵ファイルを含むシークレットを作成します。Semaphore が自動的に ~/.ssh/ に配置します。
blocks:
- name: Deploy via SSH
task:
secrets:
- name: production-ssh-key
jobs:
- name: deploy
commands:
- ssh deploy@production-server "cd /app && git pull"
Key Store と他の方法
| 方法 | 安全 | 可視性 | 失効可能 |
|---|---|---|---|
Git 内の .env |
いいえ | チーム全体 | いいえ |
| GitHub Actions Secrets | 条件付き | 場合による | はい |
| Semaphore Key Store | はい | スコープ付き | はい |
さらに、コードを触らずにトークンをローテーションし、ロールやチームでアクセスを制御し、環境ごとに別のシークレットを使えます。
まとめ
Git にコミットされたトークンは侵害されたものとして扱うべきです。履歴はコントリビュータ、フォーク、ミラー、自動化エージェントに広がり — コピーごとに露出ポイントが増えます。
Key Store はシークレットをリポジトリの外に保ち、実行時にだけ注入し、ローテーションとアクセスを制御します。Ansible、Terraform、OpenTofu、PowerShell の自動化を行うチームにとって、これはオプションのインフラではなく基盤です。
案 1
Git にシークレット = シークレットは露出。永遠に。
Git の履歴はフォーク、ミラー、CI エージェントに複製されます。コミットされた 1 つのトークンは、いつまでも侵害されたままです。
なぜ繰り返されるのか、Semaphore Key Store がどう解決するかを書きました。
案 2
Semaphore Key Store のシークレットの扱い:
→ トークン、SSH キー、環境変数をリポジトリ外に保存
→ ジョブ設定で {{ your_secret }} と参照
→ 実行時、そのジョブ用にエージェント上だけ注入
開発者は見えません。Git には載りません。
詳細記事 → [リンク]
Semaphore Key Store の仕組みと、なぜそれがあるのかをまとめた記事を公開しました。
要約: シークレットは Git に置くべきではありません。決して。しかし適切な代替がないと、開発者はそこに置き続けます。
Key Store は Semaphore の自動化ワークフローに直接組み込まれます。流れは次のとおりです。
- UI で Key Store を作成
- シークレットを追加 — API トークン、SSH キー、環境変数、設定ファイル
- ジョブ設定で
{{ your_secret }}と参照 - Semaphore が実行時に、エージェント上で、そのジョブのためだけに注入
開発者はシークレットを見ません。リポジトリにも載りません。ジョブが終われば実行環境から消えます。
ユーザー、チーム、環境ごとにアクセスを制限できます。コード 1 行も変えずにトークンをローテーション。dev、ステージング、本番で別の認証情報。
Ansible、Terraform、OpenTofu を使うチームにとって、「動く」と「本当に安全」の間に欠けていたピースです。
詳細記事 →
