Zum Hauptinhalt springen

Proposal: Service IP Ranges Endpoint

🤖 Generated with Claude Code

Co-Authored-By: Claude (noreply@anthropic.com)

Status: Draft Date: 2025-01

Problem​

Kunden müssen IP-Adressen von Together-Services für Firewall-Regeln kennen. Aktuell sind diese in Dokumentation (HOSTING.md) statisch gelistet. Bei IP-Änderungen müssen alle Kunden manuell informiert werden.

Proposal​

Maschinenlesbare Endpoints für Service-IPs bereitstellen.

Namespace-Optionen​

OptionURLScope
Ahttps://api.cca.online/ip-ranges.jsonCCA-spezifisch
Bhttps://www.servicebytogether.at/ip-ranges.jsonPlattform-weit
CBeideRedundant, aber flexibel

Empfehlung: Option B (servicebytogether.at) - zentral für alle Together-Produkte.

Response Format​

{
  "syncToken": "1705312800",
  "createDate": "2025-01-15",
  "services": [
    {
      "service": "together-cloud",
      "description": "Management Server, Health Checks",
      "ipv4Prefixes": ["40.91.210.71/32"],
      "products": ["kundenportal", "notification-api"]
    },
    {
      "service": "together-plattform",
      "description": "Integration Callbacks (TogetherSign, etc.)",
      "ipv4Prefixes": ["193.80.22.145/32"],
      "products": ["togethersign", "kundenportal"]
    }
  ]
}

Format angelehnt an AWS ip-ranges.json.

Warum nicht .well-known?​

RFC 8615 definiert .well-known für standardisierte URIs (ACME, OpenID, security.txt). IP-Ranges sind kein IANA-registrierter Well-Known URI. Große Cloud-Anbieter (AWS, Azure, GCP) verwenden eigene Pfade.

Implementation​

  • Static JSON file (kein dynamischer Service nötig)
  • Hosted auf CDN oder statischem Storage
  • Update-Prozess bei IP-Änderungen definieren
  • Optional: Webhook/Notification bei Änderungen

Documentation Update​

HOSTING.md würde dann referenzieren:

For current IP ranges, see: https://www.servicebytogether.at/ip-ranges.json

Open Questions​

  1. Soll servicebytogether.at oder ein anderer Domain verwendet werden?
  2. Notification-Mechanismus bei IP-Änderungen?
  3. IPv6 Support planen?

References​