I have configured pomerium to be used as forward-auth, ie, nginx asks it if the request is ok or not.
It doesnt make sense to define a to field in this context.
What did you expect to happen?
Being able to use pomerium as a forward-auth service, without having to define information it doesnt need.
How'd it happen?
Configure a service to use forward-auth to pomerium
Configure a rule in pomerium
If no to field is defined, it complains with validation error config: failed to parse policy: policy should have eithertoorredirectdefined
What's your environment like?
Pomerium version (retrieve with pomerium --version): (newest helm chart, 32.0.5)
Server Operating System/Architecture/Cloud: kubernetes
What's your config.yaml?
Not complete, but included the most important part of values.yaml
{"level":"fatal","error":"config: options from config file \"/etc/pomerium/config.yaml\": validation error config: failed to parse policy: policy should have either `to` or `redirect` defined","time":"2022-08-21T20:54:23Z","message":"cmd/pomerium"
Additional context
I have used the operator and added ingress annotations like ingress.pomerium.io/allowed_users. I understand that this is not really possible anymore, and I am moving myself over to rules in the config instead.
The environment is complex, and I would like to not have to fields defined as well since their service-names are usually generated by other helm packages. It will make it almost impossible to do gitops in a sane way without adding additional hacks..
What happened?
I have configured pomerium to be used as forward-auth, ie, nginx asks it if the request is ok or not. It doesnt make sense to define a
to
field in this context.What did you expect to happen?
Being able to use pomerium as a forward-auth service, without having to define information it doesnt need.
How'd it happen?
to
field is defined, it complains withvalidation error config: failed to parse policy: policy should have either
toor
redirectdefined
What's your environment like?
pomerium --version
): (newest helm chart,32.0.5
)What's your config.yaml?
Not complete, but included the most important part of values.yaml
What did you see in the logs?
Additional context
I have used the operator and added ingress annotations like
ingress.pomerium.io/allowed_users
. I understand that this is not really possible anymore, and I am moving myself over to rules in the config instead.The environment is complex, and I would like to not have
to
fields defined as well since their service-names are usually generated by other helm packages. It will make it almost impossible to do gitops in a sane way without adding additional hacks..