Repository navigation
feat(atenet): tell the actor why a credential was refused - #112
Merged
Merged
Conversation
A credential the egress gateway cannot fetch fails the request closed. Every refusal reached the actor as "egress denied", and a provider bug answered 403 like a refusal, which an agent reads as a permission problem. The FetchSecret contract now specifies what the actor sees, as a text/plain body git prints as "remote:" lines: NotFound, PermissionDenied, FailedPrecondition and Unauthenticated deny as 403 with the provider's message, escaped and cut to 512 bytes; Unavailable, DeadlineExceeded and ResourceExhausted fail as a retryable 503; anything else, and an empty or unusable secret, is a 502. Every body names the provider and nothing of the transport; the full error stays in the gateway's log. No answer becomes 404 or 400, which clients read as a missing destination or a malformed request. Signed-off-by: QuentinBisson <quentin@giantswarm.io>
QuentinBisson
force-pushed
the
feat/credential-provider-errors
branch
from
October 2, 2026 10:33
5ef0ce8 to
0925bae
Compare
QuentinBisson
marked this pull request as ready for review
October 2, 2026 13:04
Member
|
@QuentinBisson this change is in v1.4.0-rc.7, which I'm about to promote to 1.4.0 stable: an agent run on a kind lab with kagent 1.3.0-rc.15 boots and serves on rc.7, but that run doesn't exercise a refused credential. Is #112 ready to go out as stable, or should it wait? (Written by Timo's agent.) |
Author
|
#112 is fine for stable, but please do not promote rc.7. The re-pin (#119, kagent-dev/substrate v0.3.0-alpha3) carries it and everything on the branch and goes out as 1.4.0 itself: the force-push cuts 1.4.0-rc.8, stable follows after CI. Nothing stable pins rc.7, the fleet is on the 1.3 range, and kagent's one 1.3.0 tag (#159) runs on that 1.4.0. |
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A credential the egress gateway cannot fetch fails the request closed, but every refusal reached the actor as
egress denied, and a provider bug answered 403 like a refusal. kagent's caller credential provider refuses for reasons a person can act on (no turn running, no grant at the token broker), and the coding agent never sees them.Change
The
FetchSecretcontract incredprovider.protonow specifies what the actor sees, and atenet applies it:NotFound,PermissionDenied,FailedPreconditionandUnauthenticateddeny as 403 with the provider's message (escaped, cut to 512 bytes, printed by git asremote:lines),Unavailable,DeadlineExceededandResourceExhaustedas 503, anything else and an unusable secret as 502. No body carries transport detail, and no answer becomes 404 or 400. The 502 departs from upstream's 403 for unexpected answers. The agentgateway dataplane gets the same table in giantswarm/agentgateway-upstream#39. Towards giantswarm/giantswarm#38056.