Add skeleton for generalized IP allowlists

docs/rfcs/033-proxy-generalized-ip-allowlists.md

@@ -0,0 +1,62 @@
+# Name
+Created on 2024.04.16
+
+Implemented on -
+
+## Summary
+
+Neon allows tenants with higher security needs to allowlist IP addresses for access to their database. However, in some cases it is inconvenient because the access comes from ephemeral IP addresses (e.g., from a user's browser). Thus we are searching for a way which maintains security while also making the usage less difficult when IP allowlists are used.
+
+## Motivation
+
+When IP allowlisting is enabled only connections from the listed IP addresses are allowed. Every other incoming connection is rejected. This is increasing security when the connection is originating from another service run by the tenants which always uses a limited range of IP addresses. However there are a couple of use cases where this is not true:
+- **Console SQL editor**: The connection is orginating from a user's browser.
+- **Schema-diff**: The connection is orginating from a user's browser (*link issue*).
+- **Time-travel**:
+- **Proxy-link**: (*link issue*)
+
+In those cases a user currently needs to add the originating IP address to the IP allowlist. This requires manually obtaining the own IP address and adding it to the IP allowlist (*I believe there is a button for that right now, correct?*). Also once an IP address is allowlisted it will in many cases stay in the list because people may forget to delete it after they do not use it anymore. There is also the danger that they accidentally delete the wrong IP address when they are done.
+
+Also we should think about RLS Auth which probably will might use the same approach.
+
+## Non Goals (if relevant)
+
+## Impacted components (e.g. pageserver, safekeeper, console, etc)
+
+Proxy, console, control plane (*anything else?)
+
+## Proposed implementation
+
+If possible we would like to create a common implementation for the mentioned cases. However they might have different security requirements: Obtaining a database schema is less security sensitive than reading or even writing data to and from the database. Below are the different alternatives we consider:
+
+#### JWT Tokens
+
+A [JWT token](https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-token-structure) is used as a means to authenticate the user to the proxy. The token can hold additional fields (*how are they called?*). One such field would give an IP address and allow the proxy to admit the access even if the IP address is not allowlisted. For example in the case of the console SQL editor a JWT token would be created by the console and sent to the proxy for authentication. 
+
+#### Restricting allowed query types for not allowlisted IP addresses
+
+We could solve the issue for schema-diff by allowing only the schema queries if the IP address is not allowlisted. This would solve the schema-diff problem but no other.
+
+#### Ephemeral nodes have a setting to ignore IP allowlist
+
+For at least time-travel we use ephemeral compute nodes. Those could be restricted to be read-only 
+
+### Reliability, failure modes and corner cases (if relevant)
+
+### Interaction/Sequence diagram (if relevant)
+
+### Scalability (if relevant)
+
+### Security implications (if relevant)
+- We are logging when an IP allowlist is added: we should also log when a token is created
+- To avoid replay attacks a JWT token should be bound to the IP address
+
+### Unresolved questions (if relevant)
+
+- In SQL editor how is authentciation working right now?
+
+## Alternative implementation (if relevant)
+
+## Pros/cons of proposed approaches (if relevant)
+
+## Definition of Done (if relevant)