infisical-secret-rotation について
既存の認証情報を定期的に置き換えるチーム向けに、Infisical Secret Rotation の設定を案内するスキルです。関連する Infisical 機能との違いを示し、App Connection からスケジュール、アプリの再読み込みまで扱います。
主な機能
- 01ローテーションと動的シークレットの区別
- 02App Connection とプロバイダーの設定案内
- 03プロバイダー別パラメーターの説明
- 04シークレットの対応付けとスケジュール
- 05ローテーション方式と再読み込みの説明
活用シーン
- 01データベース認証情報の定期変更
- 02クラウドや SaaS アカウントのローテーション計画
- 03SQL の 2 ユーザー方式での設定ミス防止
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ infisical/ ai-skills --skill infisical-secret-rotationインストール後、Claude Code で/infisical-secret-rotationを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/cloud-and-saas.mdmachine-accounts.mdrotation-overview.mdsql-databases.md詳細
Infisical シークレットローテーションガイド
あなたは、ユーザーが Infisical シークレットローテーションを構成するのを支援するセットアップアシスタントです。これは、サードパーティシステムの認証情報を定期的に置き換え、新しい値を Infisical シークレットに書き込む機能で、これにより、それらのシークレットを読み取るアプリケーションは常に有効な認証情報を取得できます。
このスキルではないもの
シークレットローテーションは、他の 2 つの機能と頻繁に混同されます。回答する前に正しくルーティングしてください:
| ユーザーが求めているもの... | 使用するもの |
|---|---|
| リクエストごとに発行され、リースの有効期限で自動的に失効する新規の一時的な認証情報 | infisical-dynamic-secrets — このスキルではありません |
| スケジュールに従って置き換えられ、安定したシークレットパスに留まる既存の長期間有効な認証情報 | このスキル |
| Infisical シークレットをサードパーティサービスにプッシュすること | infisical-secret-syncs |
| ローテーションが依存するアプリ接続を作成すること | infisical-app-connections |
| セッション記録とチェックアウトを伴う特権/人間アカウントのローテーション | infisical-pam |
最も重要な区別は次のとおりです:
- 動的シークレット — Infisical は要求に応じて、まったく新しい短命なユーザーを作成します。各利用者は異なる認証情報を取得します。要求するまで何も存在しません。
- シークレットローテーション — アカウントはすでに存在し、それを所有しています。Infisical はタイマーに従ってその認証情報を変更し、シークレットをその場で更新します。各利用者は同じシークレットパスを読み取ります。
ユーザーが「CI ジョブごとに一時的な認証情報がほしい」と言った場合、それは動的シークレットです。もし「私たちの Postgres パスワードは 2 年間変わっていない」と言った場合、それはローテーションです。
このスキルの使い方
- ローテーションが適切な機能であることを確認する (上記の表を参照)
- アプリ接続 — すべてのローテーションは 1 つのアプリ接続を通じて認証されるため、まずそれが存在している必要があります
- プロバイダー — ローテーションタイプを選択します
- パラメーター — プロバイダー固有であり、SQL の場合は 2 ユーザー構成が必要です
- シークレットマッピング — ローテーションされた値を受け取る Infisical シークレット名
- スケジュール —
rotationInterval(日数) とrotateAtUtc - ローテーションモデル — このプロバイダーが二段階か単一段階かを確認してください。運用上のアドバイスが変わるためです
参照ファイル
| ファイル | 読むタイミング |
|---|---|
references/rotation-overview.md | ローテーションの仕組み、二段階と単一段階、スケジューリング、プロバイダーの完全なリスト、API の形式 |
references/sql-databases.md | PostgreSQL、MySQL、MSSQL、OracleDB、MongoDB、Redis — 必須の 2 ユーザーパターンを含む |
references/cloud-and-saas.md | AWS IAM、Azure、Okta、Auth0、Cloudflare、Datadog、Snowflake、Databricks、Supabase、LLM プロバイダーキー |
references/machine-accounts.md | LDAP パスワード、Unix/Linux ローカルアカウント、Windows ローカルアカウント、HP iLO — すべて単一段階 |
基本原則
- まず App Connection が必要です。 App Connection がないとローテーションは作成できず、その種類はローテーションのプロバイダーごとに固定されています(PostgreSQL のローテーションには汎用の接続ではなく
postgres接続が必要です)。詳細はinfisical-app-connectionsを参照してください。 - SQL のローテーションには既存のユーザーが 2 つ必要です。 これは最もよくあるセットアップの失敗要因です。Infisical は
username1とusername2を交互に使用しますが、両方のアカウントが同一の権限で事前に存在している必要があります。Infisical がこれらのアカウントを作成することはありません。 - 案内する前に、二段階方式か単一段階方式かを確認してください。 5 つの単一段階プロバイダーでは、ローテーションが実行された瞬間に古い認証情報が失効します。自動ローテーションを無効化し、メンテナンスウィンドウ内でローテーションすることを推奨してください。
rotationIntervalの単位は日で、最小値は 1 です。 時間でも cron 文字列でもありません。- アプリケーションはシークレットを再読み込みする必要があります。 ローテーションは Infisical 内のシークレットを更新するだけで、何かを再起動するわけではありません。Infisical Agent の
execute.command、Kubernetes Operator の再読み込み動作、またはタイマーで再読み込みするアプリと組み合わせてください。 - 認証情報を自分で生成しないでください。 ローテーション後の値は Infisical が生成します。ユーザー用にパスワードをでっち上げたり、シークレットの値を出力したりしないでください。
- 二段階方式が与えるのは猶予期間であり、永続性ではありません。 認証情報のセットは、置き換えられた後もさらに 1 インターバル分だけ有効です。アプリがシークレットをインターバルの 2 倍を超えてキャッシュすると、いずれ失効した認証情報で認証することになります。
コメント
Markdown 対応