per-Application IP Address / IP Access Control
-
By default, a Cloudron App will be served on all Interfaces.
Therefore, if any Cloudron App is required to be reachable by the public internet, all Cloudron Apps on the host will be reachable by the public internet.server { listen 443 ssl http2; server_name application.cloudron-host.example.com; listen [::]:443 ssl http2; }
It would be great if it was possible to assign a dedicated IP address that an application will exclusively listen on.
That way, the application could be hidden from the public internet by restricting access to it on a network firewall.server { listen 10.10.10.10:443 ssl http2; server_name application.cloudron-host.example.com; listen [fdea:dbee::f]:443 ssl http2; }
Another way of achieving a similar goal on a single IP address/ all interfaces would be IP access control lists in the reverse proxy:
server { listen 443 ssl http2; server_name application.cloudron-host.example.com; listen [::]:443 ssl http2; allow 192.168.1.0/24; # Allowed Access deny all; }
I know that this is probably a lot more work to implement in the front end, than in these quick examples.
But anyway, these features are probably something that possibly other users would appreciate. -
@wind-gmbh Is the use case here that the server has multiple interfaces and one is public internet and another is private internet ? In that case, you want to configure the app(s) to listen only on the private internet interface? Did I get the use case right?
FWIW, I prefer the first config more then the second one i.e just restrict listening on the interface only in the first place.
-
@girish said in per-Application IP Address / IP Access Control:
@wind-gmbh Is the use case here that the server has multiple interfaces and one is public internet and another is private internet ?
Yes, exactly. It is basically the idea to limit the attack surface in a single-server scenario by excluding some apps from the public eye.
@girish said in per-Application IP Address / IP Access Control:
FWIW, I prefer the first config more then the second one i.e just restrict listening on the interface only in the first place.
I would say either has it's advantages:
listen
on IPallow
/deny
Network Layer Layer 3/4 (TCP/IP) Layer 7 (HTTP) Works with single IP no yes Network segmentation / Firewall required yes no Visible Access Barrier Not routed / dropped by Firewall HTTP 403 Cloudron needs to keep track of assigned IP addresses yes no They are differently working solutions for the same basic problem, that apply to different scenarios.
-
-
-
-
I second this request, however, is slightly different to the private interface your referencing @girish
x1 server, 5 public interfaces (eth0-5) all with public static IP's.
In my scenario, a client would be assigned a single static IP for all their applications. I'm doing this currently by spinning up an individual VPS on Runcloud for their apps. The main advantage for them is RDNS for their 'assigned' IP address.
Just my 2cents