旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。
GCP Secret Manager
Kong Gatewayの実装の現在のバージョンでは、2つの方法でGCP Secret Managerの構成をサポートしています。
- 環境変数
- ワークロードID
GCP Secret Managerを構成する
GCP Secret Managerを構成するには、GCP_SERVICE_ACCOUNT
環境変数をサービスアカウントの認証情報を参照するJSONドキュメントに設定する必要があります。
export GCP_SERVICE_ACCOUNT=$(cat gcp-project-c61f2411f321.json)
Kong Gatewayはキーを使用して自動的にGCP APIを認証し、アクセス権を付与します。
GKE クラスタで、GCP Secret Manager を Workload Identity と一緒に使用するには、ポッドの仕様を更新して、サービスアカウントをポッドに関連付けます。構成情報については、Workload Identity の構成に関するドキュメントを参照してください。
注:
- Workload Identity では、
GCP_SERVICE_ACCOUNT
を設定する必要はありません。- GCP Vault をバックエンドとして使用する場合は、公式の GCP API が使用する SSL 証明書を Kong が信頼できるように、
lua_ssl_trusted_certificate
構成ディレクティブの一部としてsystem
が構成されていることを確認してください。
例:
secret-name
という名前でGCP Secret Managerのシークレットを使用するには、以下のように1つ以上のプロパティを含むJSONオブジェクトをGCPで作成します。
{
"foo": "bar",
"snip": "snap"
}
以下のように、シークレットの個々のリソースを参照できるようになりました。
{vault://gcp/secret-name/foo?project_id=project_id}
{vault://gcp/secret-name/snip?project_id=project_id}
プロバイダー(gcp
)とGCPプロジェクトID(project_id
)の両方を指定する必要があります。Kong Gatewayを起動する前に、環境変数を使用してプロジェクトIDを構成できます。
export KONG_VAULT_GCP_PROJECT_ID=project_id
その後、参照でそれを繰り返す必要はありません。
{vault://gcp/secret-name/foo}
{vault://gcp/secret-name/snip}
Vaults エンティティによる構成
データベースが初期化されると、プロバイダーとGCPプロジェクトIDをカプセル化するVaultエンティティを作成できます。
Vaultエンティティを配置すると、それを通じてGCPシークレットを参照できます。
{vault://gcp-sm-vault/secret-name/foo}
{vault://gcp-sm-vault/secret-name/snip}
Vaultエンティティの設定オプション
サポートツールのいずれかから、次の構成オプションを使用して Vault エンティティを構成します。
- Admin API
- 宣言型構成
- Kong Manager
- Konnect
Kong Gateway の GCP Secret Manager vault の構成オプション:
パラメータ | フィールド名 | 説明 |
---|---|---|
vaults.config.project_id |
Google Project ID | Google API ConsoleのプロジェクトID。Google API Consoleにアクセスし、プロジェクトリストで すべてのプロジェクトを管理 を選択し、プロジェクトIDを確認します。 |
vaults.config.ttl |
TTL | キャッシュされた場合の、vaultからのシークレットのTime to Live(秒)。特別な値0は「回転なし」を意味し、これはデフォルトです。ゼロ以外の値を使用する場合は、少なくとも1分にすることをお勧めします。 |
vaults.config.neg_ttl |
ネガティブ TTL | Vault のミス(シークレットが存在しない)の Time to Live(秒単位)。ネガティブキャッシュされたシークレットは、neg_ttl に達するまで有効です。その後、Kong はシークレットのリフレッシュを試行します。neg_ttl のデフォルト値は 0 で、ネガティブキャッシュは発生しないことを意味します。 |
vaults.config.resurrect_ttl |
Resurrect TTL | シークレットが期限切れになった(config.ttl が終了した)後もシークレットが使用され続ける時間(秒単位)。これは、Vaultにアクセスできなくなった場合、またはシークレットがVaultから削除されてすぐに置き換えられない場合に役立ちます。どちらの場合も、ゲートウェイはresurrect_ttl 秒間シークレットの更新を試行し続けます。その後、更新の試みは停止します。Vault に予期しない問題が発生した場合にシームレスな移行を確実に行うために、この構成オプションに十分に高い値を割り当てることをお勧めします。resurrect_ttl のデフォルト値は1e8秒で、これは約3年に相当します。 |
一般的なオプション:
パラメータ | フィールド名 | 説明 |
---|---|---|
vaults.description オプション |
説明 | Vaultの説明(オプション)。 |
vaults.name |
名前 | Vaultのタイプ。env 、gcp 、aws 、またはhcv のいずれかを受け入れます。GCP Secret Managerにgcp を設定します。 |
vaults.prefix |
Prefix | 参照プレフィックス(接頭辞)。このボールトに保存されているシークレットにアクセスするには、この接頭辞が必要です。たとえば、 {vault://gcp-sm-vault/<some-secret id="sl-md0000000">} などです。 |