[FEAT]: Improve Service-Isolation

[madejackson]

Feature Description

This is a FR for multiple details concerning better service-isolation and better security. I believe this features would align well with cosmos' focus on security while retaining high usability.

1. Multiple Entrypoints
   Coming from Traefik, I miss the possibility to have multiple endpoints for separating public and private services.
   One Endpoint which is accessible from public (f.e. port 8080/4443, forwarded from public port 80/443), another Endpoint for local services (port 80/443) Right now I can only expose either all or no services to the public, risking a security breach when being sloppy and/or inexperienced.
2. Multiple Certs
   I think it makes sense to isolate certs where they don't belong together. F.e. when you're hosting a public website like a blog on cosmos while still using a separate Domain for private services, there is only one cert requested with all domains in there, exposing the domain-relations. This violates need to know principle, meaning this knowledge can be leveraged in case of an attack. Dupe: [Feat]: Per-domains certificates #336
3. Better Whitelist with groups/aliases
   Right now, Whitelists are on a per URL-basis in advanced settings. They are not shown on any overview and not handled centrally. Managing this is time consuming and prone to errors. We should have the possibility to setup named access-groups and show them on the URL-Overview as well as in the settings. Dupe: ([FEAT]: IP/Subnet aliases for whitelisting #214
4. default Whitelist / local only
   Right now, if not changed manually, Cosmos does not block public access. This means cosmos is compromised, as soon as someone does a port forwarding while having the wrong settings (or too early). IMHO in today's world, this is more than a minor security issue. Per Default, Cosmos should block access from public IP-Ranges. Arguably even any IP-Range except it's own. One should then have the possibility to change the default ranges either limiting them even more or opening access up to the public.

[azukaar]

1. For this point I would argue that creating a URL that filters to local only would do the job no? There's no additional benefit to the port being different IMO?
2. I'm a bit worried about implementing this in term of usability, it's already the hardest part about Cosmos to manage the HTTPS certificate for most people, and having an option to manage multiple would only complicate it further (without mentioning the difficulties code-wise of managing all those), But I agree that at the very least having 2 certificates (private vs public) would be useful, I was thinking about always having a private certs for .local domains even when public HTTPS is set for example, so that the operation would be odor-less to the user
3. yes 👍 I did have some early design about this actually at some point
4. Not possible as people use Cosmos on VPS / remote servers too, and since people dont read documentation, even if you have an option to disable it the number of tickets about this would be extremely annoying

[madejackson]

1. Maybe this can be omitted if Whitelists get better.
2. I don't think this needs to have any changes at all in terms of config / usability. Right now, cosmos updates the certificate on any domain change. I'm just suggesting to change the behavior from updating the existing cert to requesting a new cert, which would lead to one certificate per domain.
   • You even can improve the wildcard logic, further enhancing usability: If there is a wildcard DNS-entry for *.domain.tld (f.e. CNAME to domain.tld), request a cert for *.domain.tld, domain.tld else request a cert for domain.tld
     this means you can get rid of the wildcard-checkbox in the settings while now also supporting subdomains. I'm not even sure why subdomains aren't supported in the first place. It works perfectly fine when overwriting it manually.
3. perfect
4. I think I don't like the VPS-Setup from a security standpoint, neither.
   When you spin up cosmos on a publicly accessible VPS and set a password this way, you'll
   1. transmit this password unprotected via http and
   2. your instance is vulnerable/pawnable until a user is configured.
   3. Hence there should be another, more secure way of installing cosmos via the public internet
      1. like preconfigured keys via SSH.
      2. Another solution would be SSH tunneling for the first setup.
      3. Another would be constellation from the get go.
   4. All of those solutions would it make possible to limit access to local only per default. Anyways, if you won't enable local only per default, which I do understand, then very least should be a BIG FAT RED WARNING that your service is accessible from the Internet. Especially, when auth for said service is disabled.

[azukaar]

2. I need to think about this more, because it's not as easy:

• having one cert per domain means that users might expect to be setting multiple DNS challenges. Your approach would only work if DNS CHallenge = Wildcard. But it's not the case: one DNS challenge can resolve multiple subdomains and wildcard or none. Right now the shortcut I took alliviate this ambiguity by assuming everything matches the DNS challenge when it is setup
• right now the way certbot work it can do DNS challenge OR TLS challenge. Having multiple certs means implementing logic for multi-pass certificate generation (which is possible ofc)
• BUT that said I do agree that for sure more granularity is required here AT THE VERY LEAST to have local domains have their own certs when using a public cert for the rest
• We need to think about this more

4. Users are free to do that already if they want to, set the Cosmos hostname to localhost via hostname and open an SSH tunnel to do your install

5. in term of UI yes, more messaging can definitely be done, but Cosmos cannot tell wheteher something is accesible from the internet or not, because it cannnot tell if there is a NAT (with or without port forwarded) or a firewall (blocked or not) between itself and the internet