[WIP] Restrict project access by IP address

[esoergel]

Product Description

Technical Summary

https://dimagi.atlassian.net/browse/USH-5818
https://dimagi.atlassian.net/browse/USH-5817
Design document

Feature Flag

Safety Assurance

Safety story

Automated test coverage

QA Plan

Rollback instructions

• This PR can be reverted after deploy with no further considerations

Labels & Review

• Risk label is set correctly
• The set of people pinged as reviewers is appropriate for the level of risk of the change

[esoergel]

@minhaminha here's a branch with the basic model for the IP access work - figure we can PR our respective changes into this and hopefully avoid too much conflict

[minhaminha]

is there any need for a country_denylist?

[esoergel]

I left it out for now since we don't need it and it makes the logic a bit harder to reason about. Though thinking about it again I think we could make it work by saying specificity wins (ie an IP rule beats a country rule), something like:

def is_allowed(ip):
    if ip in ip_denylist:
        return False
    if ip in ip_allowlist:
        return True
    if country_denylist and is_in_country(ip, country_denylist):
        return False
    return not country_allowlist or is_in_country(ip, country_allowlist):

That is, allowlisted IPs are always allowed even from denylisted countries.

Still, I think it's okay to hold off for now - we could always add it later if needed

[minhaminha]

@esoergel I noticed that currently, a user that's not in an allowed country according to the domain's config can trigger multiple requests if they repeatedly try to access the domain. I'm thinking we should also add a session blocklist, so that when a user fails config.is_allowed they aren't allowed to try again but wanted to get your thoughts as well.

[esoergel]

@minhaminha yeah that's a good thought - I had the same idea but was uncertain whether it'd be worth it. It certainly makes sense to cache the lookups we allow, since we expect users to make a bunch of requests in sequence. However, if their request is blocked, presumably they won't try again and again unless it's like a DOS attack, which this isn't intended to mitigate against.

Still though, I guess we wouldn't actually stick anything in the session for blocked IPs unless we do encounter one, so the cost should be trivial. I'd be on board with that.

[minhaminha]

@esoergel blocking by the IP's origin country is now working properly on staging 🎉 . Is there anything else to be done on this PR before releasing it from the drafts? I created an IP Access monitoring dashboard on datadog here, and I'll add the requests-per-day counter on their too/setup the 1000 request threshold alert after this gets merged.
I saw in the design doc we were considering checking IPs for API requests too - did we decide which of 3 approaches you described to go with?
I'm also wondering if this line from the doc is necessary:

On subsequent requests, a middleware class should check the request IP against the IP address used to initiate the session. If the IP address differs, we flush the session and force the user to log in again.