@elentaure. shouldn't you be handling this in your application logic? If you are allowing your users to directly make calls to the gateway it could be a security problem for you
that said priority order is
Headers > Config > Body
So the headers override the config
Do Headers override config?
@elentaure. - today there’s no way to stop users from overriding the header.
We’re bringing custom host to the virtual key soon which should simplify part of the problem. But we’ll still let users override using headers. Don’t have a concrete way to stop certain headers from getting applied!
Hi @rohit and @sega but then this is a risk, that means that whatever a user decides to pass as a header or a parameter in the sdk will always have preference over what we configure? so we can not even enforce guardrails for example?
I mean you should ideally be restricting it in your application layer.
Is there any specific reason you're allowing your users to directly call portkey endpoints?
The use case is having portkey as the API gateway for the users to consume in a centralized and contolled way any endpoint from the different cloud providers
instead of consuming directly vertex or bedrock for example, we expose those endpoints via portkey
@sega anything to comment on this approach?
tagging @rohit , he'd be able to answer this
Fair point. Are you giving users the ability to connect via Virtual Keys?
A way to solve this we've seen with enterprises is to use Configs instead. You can define the guardrails or any other configuration needed.
Members in a workspace cannot edit configs on the UI. Overriding configs also won't work since virtual keys aren't acessible directly.
Would this work?
Meanwhile, I'm also thinking about adding stop header overrides as a security setting.
Adding that would be great yes
The idea of the use case is creating configs and associate them with api keys, ideally the api keys would be the only thing the consumers would have to pass when they consume the endpoints, that way we enforce a specific config. The config itself would use the virtual keys yes.
They would not access the UI as far as I know, so permissions there are not a concern, the concern is that they can potentially pass a config object either in the headers or in the sdk and override any control from our side. Same thing with the custom host for example
Got it.
You can configure default configs along with the user's API key today. This is possible through the UI.
Users will not be able to send any other config object since they won't have access to virtual keys, essentially restricting the override.
If a user passes a custom config object from their side, it just won't return any results today as well.
So you mean that even if they override the config, they dont know the virtual key id so that config would not authenticate to the backend services?
understood. However, also having the option to prevent header overrides would be great, there are other stuff like custom hosts that we would like to prevent
yes, totally agree there. I'll discuss this with the dev team, scope it out and come back with a timeline on this
