Add additional option for kiro-cli apikey usage (multi Tennant support)#212
Add additional option for kiro-cli apikey usage (multi Tennant support)#212marcelloceschia wants to merge 7 commits into
Conversation
|
Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: Marcello Ceschia.
|
|
Thanks for the PR! 🎉 Before merge, we need a one-time CLA confirmation. Full CLA text: Please reply once with: You need to write once, all further messages from me can be ignored. |
|
I have read the CLA and I accept its terms |
|
Thanks for the PR! 🎉 Before merge, we need a one-time CLA confirmation. Full CLA text: Please reply once with: You need to write once, all further messages from me can be ignored. |
|
I have read the CLA and I accept its terms |
|
Thanks for the PR! 🎉 Before merge, we need a one-time CLA confirmation. Full CLA text: Please reply once with: You need to write once, all further messages from me can be ignored. |
|
Thanks for the PR! 🎉 Before merge, we need a one-time CLA confirmation. Full CLA text: Please reply once with: You need to write once, all further messages from me can be ignored. |
|
Thanks for the PR! 🎉 Before merge, we need a one-time CLA confirmation. Full CLA text: Please reply once with: You need to write once, all further messages from me can be ignored. |
Adds support for Kiro API keys (ksk_*) as a new authentication method. The gateway can now run in fully stateless mode — no server-side credentials required. Users pass their own API key as a Bearer token, and it's forwarded directly to Kiro API with the tokentype: API_KEY header.
Motivation
Enable a single shared gateway instance where multiple users connect with their own Kiro subscription via API keys generated from kiro-cli settings.