Introduce API keys to vets-api

[jeff2d2]

This one is a big effort.

In part in response to some possibly malicious probing of the Facilities Locator API, and as part of the larger zero-trust initiative, we want to introduce API authentication to vets-api.

Some rough thought about steps, absolutely subject to change:

• [ ] introduce api key support (cf https://keygen.sh/blog/how-to-implement-api-key-authentication-in-rails-without-devise/)
• [ ] log api keys with every log, sentry, etc
• [ ] introduce global legacy api key, and inject it into all FE requests
• [ ] maybe group the endpoints by app or some arbitrary taxonomy, and give each group its own unique API key. as a stepping stone to:
• [ ] introduce per-app api keys, and encourage app teams to adopt them by gradually throttling the global legacy key

[patrickvinograd]

How are you proposing to use API keys from a single page app? I.e. how do you avoid a malicious entity inspecting vets-website or using browser devtools to get their hands on the API key.

[f1337]

how do you avoid a malicious entity inspecting vets-website or using browser devtools to get their hands on the API key

Great question! The surface answer is of course, we can't prevent a malicious actor from copying an API key from their browser's request log. However, imagine an end state where every FE app on va.gov has its own API key. And then imagine a malicious actor copies one of those API keys, and starts causing trouble. With API keys in play, we will have the ability to selectively: throttle, redirect to honeypot, etc. And we can do so without resorting to shutting off an entire path/endpoint or IP range. Yes, the application under attack is still affected. But if we implement it properly, the rest of vets-api would be unaffected.

I admit I'm quite tired from the past 24+ hours of incident triage. I hope the above makes sense. We're trying to give ourselves slightly more precise tools for future games of whack-a-mole, while fully understanding that automated whack-a-mole is still whack-a-mole.

[mchelen-gov]

were we able to confirm if this API is coming from Lighthouse, which already has API key management?

[ericboehs]

This still seems like a viable project