Confluent Cloud、API Keys endpoint で STS access tokens 認証に対応

Confluent Cloud は 2026年6月3日のリリースノートで、iam/v2/api-keys エンドポイント が Confluent STS access トークン による認証をサポートしたことを公開しました。API key 管理を workload identity と組み合わせるチームに関係する更新です。

要点

• iam/v2/api-keys Confluent Cloud API エンドポイント が STS access トークン 認証に対応した
• confluent-sts-access-トークン を使った API Keys API 呼び出しが可能になる
• workload identity / OAuth ベースの自動化を進めるチームに関係する
• API key 作成・管理の自動化では、権限範囲と監査ログの確認が重要になる

今回のリリースノートで語られていること

今回の更新は、Confluent Cloud の API key 管理をより現代的な認証フローに寄せるものです。従来、API key 管理の自動化では、長期的な認証情報やサービスアカウントの扱いが運用上の論点になりがちでした。STS access トークン を使える エンドポイント が増えることで、workload identity と短命なトークンを組み合わせた運用に近づきます。

特に iam/v2/api-keys は、API key の作成、参照、管理に関わる重要な API です。ここで STS access トークン が使えるようになると、CI/CD、Terraform、社内プラットフォーム、運用自動化ツールが Confluent Cloud の API key 管理をより安全に扱いやすくなります。

ただし、API key 管理は強い権限を持つ操作です。短命トークンを使うこと自体は安全性を高めますが、どの workload identity がどの API key を扱えるか、作成された key がどのリソースへアクセスできるか、失効やローテーションがどう行われるかを合わせて確認する必要があります。

AI エージェントや自動化ツールが Confluent Cloud を操作する場合も同じです。エージェントが直接 key を作る設計は慎重に扱い、必要なら承認付きのワークフローや限定された管理 API のみを許可する形が現実的です。

実務で確認したいポイント

まず、iam/v2/api-keys を使っている自動化があるか確認してください。ある場合は、STS access トークン へ移行することで長期認証情報を減らせるかを検討できます。

次に、API key 管理操作の監査ログ、ロール、対象リソースを確認します。key の作成権限は、データ読み書き権限とは別に管理し、運用自動化の実行主体を限定するのが安全です。

結局、この更新をどう見るべきか

STS access トークン 対応は、Confluent Cloud の API key 管理をより安全な自動化へ寄せる更新です。CI/CD や platform automation を使うチームは、認証方式の見直しと権限境界の確認を進めたい内容です。