c0c0n3
commented
4 years ago Here's a bit more detail about what's happening.
The instance config below tells Istio to extract the client token (the value of the "ids-dth" HTTP header of the incoming request) and put it into the client_token parameter to be sent to our adapter.
...
kind: instance
...
spec:
template: oriondata
params:
client_token: request.headers["ids-dth"]
...If you hit your local Minikube cluster (see README.md for our setup) with a token in the request:
$ curl -v "$BASE_URL"/headers -H ids-dth:my.fat.jwtThe adapter gets passed the "ids-dth" header value. Here's a snippet from the adapter logs:
... info auth request
{&InstanceMsg{ClientToken:my.fat.jwt,Name:icheck.instance.istio-system,}
...Now you could configure our Istio virtual service to drop the request header before sending the request on to the target service:
...
kind: VirtualService
...
spec:
...
http:
- route:
- destination:
...
headers:
request:
remove:
- ids-dthBut with this config, if you hit the cluster again with the same request
$ curl -v "$BASE_URL"/headers -H ids-dth:my.fat.jwtthe adapter gets an empty string as seen from the logs:
... info auth request
{&InstanceMsg{ClientToken:,Name:icheck.instance.istio-system,}
...It looks like the header gets chopped off before the request makes it to the target service's Envoy sidecar which then can't obviously add that header to the request.headers attribute map and eventually our adapter gets nada, zilch, nuffin. (This is just a theory, things may work differently under the bonnet!)
Too bad, I thought, we can still do this at the rule level---i.e. in the adapter's rule config that ties the handler to the instance---or can we? With this config
...
kind: rule
...
spec:
...
requestHeaderOperations:
- name: ids-dth
operation: REMOVE
...and the remove header directive removed (pun intended!) from the virtual service config, the adapter still gets an empty string!
We'd like to be able to ditch the request IDS-DTH header with the client token before passing on the request to Orion. It looks like that isn't the easiest thing to do with Istio if our adapter should be able to access the header's value---which it should since we've got to validate the token!
As things stand now, if we remove the header through Istio configuration then the header value (token) the adapter gets to see is an empty string. Hence token validation would always fail (even for valid tokens!) if we removed the IDS-DTH header from the request.
Since we've got to validate tokens, at the moment we are not removing the header from the client request and that header will also be in the request the Envoy forwards to Orion. Is there any way to have both token validation and header removal?