Support for fetching authorization headers?

[dzkaiten]

Hi team,

I have a use case where I need validated authorization headers in order to make requests to my application. These headers can be retrieved from a different authorization endpoint, separate from the target that I am trying to warm up. How would I go about retrieving these authorization headers and passing them into Mittens in an easy way?

[worldtiki]

Hi @dzkaiten. Is this when using Kubernetes?
I wonder if you could use an init container to obtain the auth headers and then expose them to mittens. Or alternatively to implement ordered requests where the 1st one would be the auth.

Both of these options would require making changes to Mittens.

Thoughts? Or different options?

[dzkaiten]

Yes I am using Kubernetes. I currently have a workaround solution where I've created my own Dockerfile that extends from the Mittens base image and overrides the entrypoint with my own custom script. In this script, I do the CURL request for an authorized ticket, which I then pass in as an argument to my Mittens command.

I believe you could achieve the same thing with an init container. So if that was implemented to Mittens, I think it'd be helpful for anyone who needs to obtain any auth headers before executing their warm up requests.

[dzkaiten]

On a similar but unrelated note (regarding Kubernetes) Is there a way I can prevent my application containers from accepting real production traffic before Mittens is finished warming them up? Basically sequencing traffic so that requests from Mittens come first and warm up the containers before serving real requests.

Doing a little more reading in to the Kubernetes docs actually, I may have been able to answer my own question:

The kubelet uses readiness probes to know when a container is ready to start accepting traffic. A Pod is considered ready when all of its containers are ready.

It seems I was confusing pod readiness with container readiness. If I understand correctly, by using the Mittens file readiness probe, my pods will only serve real traffic once both containers are ready. That is, my application container is up and running, and Mittens, with the file readiness probe, is finished executing all the warm up requests on that app container.

[worldtiki]

It seems I was confusing pod readiness with container readiness. If I understand correctly, by using the Mittens file readiness probe, my pods will only serve real traffic once both containers are ready. That is, my application container is up and running, and Mittens, with the file readiness probe, is finished executing all the warm up requests on that app container.

Yes, that is correct. If the mittens container is not-ready, the entire pod is also considered not-ready, and will not be put into service.

[worldtiki]

I think this overlaps a bit with #142
Maybe we could use a similar approach with ordered requests, but where the some of them run only once (and not in a loop).
We'd still need a way to propagate data from one request to another.

I'm a bit worried this is an edge case and may add complexity. I'll wait a bit longer to see if we can get more comments/feedback. But feel free to make suggestions on how this could be implemented.

[kubehe]

I have similar usecase.

I need to call external service to get auth token.
Maybe ability to call external service + jsonpath to reference token and pass it in headers / json/proto body would do the job?