agentgateway: http ext authz api #13044
Conversation
Signed-off-by: John Howard <[email protected]>
gateway-bot
added
kind/feature
| // | ||
| // +optional | ||
| // +kubebuilder:validation:MaxItems=64 | ||
| AllowedRequestHeaders []ShortString `json:"allowedRequestHeaders,omitempty"` |
There was a problem hiding this comment.
on the envoy side this was a shared type between gRPC and HTTP, is it useful to do the same here?
i.e. should we move this out of the HTTP-specific type?
There was a problem hiding this comment.
I kind of like it split since the docs are differnt for each (one defaults to all, the other does not) but I am fine either way.
tbh I don't get why anyone would not send all for gRPC but 🤷
There was a problem hiding this comment.
I can buy the split for the different defaults (it was very hard to accurately portray that in the shared envoy type!) but just to make sure I'm not missing something, I don't see this current in the gRPC extauth type yet, correct?
And separately, given:
I kind of like it split since the docs are differnt for each (one defaults to all, the other does not) but I am fine either way.
I'm assuming this is to maintain the weird behavior envoy currently to e.g. enable compatibility with existing extauth servers?
| // | ||
| // +optional | ||
| // +kubebuilder:validation:MaxProperties=64 | ||
| Metadata map[string]shared.CELExpression `json:"metadata,omitempty"` |
There was a problem hiding this comment.
since this is a duplicated type between HTTP and gRPC is it worth moving up a level?
There was a problem hiding this comment.
Its duplicated type but has entirely different behavior. One is the metadata to populate in the grpc request, and the grpc server returns the response metadata. In http, there is no metadata to send in the request or response, and this field instead sets response metadata based on the HTTP response.
Perhaps more explicit naming would help
There was a problem hiding this comment.
Yeah, I wasn't paying close enough attention as was tricked by the similar naming.
Is there a more specific term for the agentgateway metadata?
There was a problem hiding this comment.
it's long but maybe metadataFromResponse or something like that?
| // | ||
| // +optional | ||
| // +kubebuilder:validation:MaxItems=64 | ||
| AllowedRequestHeaders []ShortString `json:"allowedRequestHeaders,omitempty"` |
There was a problem hiding this comment.
I can buy the split for the different defaults (it was very hard to accurately portray that in the shared envoy type!) but just to make sure I'm not missing something, I don't see this current in the gRPC extauth type yet, correct?
And separately, given:
I kind of like it split since the docs are differnt for each (one defaults to all, the other does not) but I am fine either way.
I'm assuming this is to maintain the weird behavior envoy currently to e.g. enable compatibility with existing extauth servers?
| // | ||
| // +optional | ||
| // +kubebuilder:validation:MaxProperties=64 | ||
| Metadata map[string]shared.CELExpression `json:"metadata,omitempty"` |
There was a problem hiding this comment.
Yeah, I wasn't paying close enough attention as was tricked by the similar naming.
Is there a more specific term for the agentgateway metadata?
| // If unset, by default the `envoy.filters.http.jwt_authn` key is set if the JWT policy is used as well, for compatibility. | ||
| // +kubebuilder:validation:MaxProperties=64 | ||
| // +optional | ||
| Metadata map[string]shared.CELExpression `json:"metadata,omitempty"` |
| // | ||
| // +optional | ||
| // +kubebuilder:validation:MaxProperties=64 | ||
| Metadata map[string]shared.CELExpression `json:"metadata,omitempty"` |
There was a problem hiding this comment.
it's long but maybe metadataFromResponse or something like that?
3 participants
Description
Blocked by agentgateway/agentgateway#696
This adds HTTP as an ext_authz mode for Agentgateway
Change Type
/kind feature
Changelog
Additional Notes