Règles de périphérie

Chaque serveur exécute un proxy Web devant ses applications. Les règles ci-dessous s’exécutent là, avant qu’une requête atteigne votre application. La plupart vivent dans l’onglet Settings → Networking de l’application et s’appliquent au prochain déploiement.

Vous pouvez aussi les définir par l’API (GET / PATCH /api/applications/:id/edge, qui fusionne les clés que vous envoyez) ou dans la section edge: de railyard.yml.

Accès : mot de passe et règles IP

La carte Access fait trois choses :

• Password. Met un mot de passe sur l’application, ce qui convient aux stagings, aux aperçus et aux outils d’administration.
• IP rules. Autorisez ou refusez une adresse ou une plage CIDR par ligne. Tous les autres reçoivent 403.
• No indexing. Les adresses par défaut et d’aperçu indiquent déjà aux moteurs de recherche de ne pas les indexer.

HTTPS

Chaque adresse reçoit un certificat, et une visite en HTTP simple est redirigée vers HTTPS par défaut. Désactivez HTTP redirects to HTTPS seulement pour les clients qui ne peuvent pas suivre une redirection, comme de vieux appareils ou des vérificateurs de santé — l’application répond alors aussi en HTTP simple. S’applique au prochain déploiement.

Redirections et réécritures

Redirects and rewrites accepte une règle par ligne. Les règles sont vérifiées dans l’ordre, et la première correspondance gagne :

/blog/* https://blog.example.com/*{?query} 301
www.shop.example.com/promo /sale 302
/old-api/* /api rewrite
/legacy /new

• Type : 301, 302, 307, 308 ou rewrite. La valeur par défaut est 301.
• Hôte : un hôte placé devant le chemin limite la règle à cette adresse.
• * final : reporte le reste du chemin.
• Les réécritures servent un autre chemin de la même application et conservent la chaîne de requête.

Vous pouvez avoir jusqu’à 100 règles. Elles sont désactivées pendant le mode maintenance.

En-têtes de réponse et CORS

Response headers and CORS accepte une règle d’en-tête par ligne :

* X-Frame-Options: DENY
/api/* Cache-Control: no-store
* -X-Powered-By

Un en-tête que vous définissez remplace la valeur envoyée par votre application, et -Name supprime l’en-tête. Vous pouvez avoir jusqu’à 50 règles.

Pour CORS, listez les origines autorisées, puis les méthodes, les en-têtes, si les identifiants sont autorisés et une durée maximale. Le proxy répond lui-même aux requêtes preflight, donc elles n’atteignent jamais l’application, et les autres origines ne reçoivent aucun en-tête CORS. Si l’application a un mot de passe, les preflights reçoivent 401.

Pages d’erreur et de maintenance

• Error page : affichée avec le vrai statut (502, 503 ou 504) quand l’application ne répond pas parce qu’elle a planté, redémarre ou est trop lente.
• Maintenance page : remplace la page intégrée de Railyard pendant que le mode maintenance est actif. Elle est quand même envoyée avec un 503.

Collez le HTML, ou donnez une adresse et Railyard copie la page chaque fois que vous enregistrez. Une page copiée peut faire jusqu’à 64 Ko et doit être sur une adresse publique. Les pages sont servies telles qu’elles sont, donc utilisez des URL complètes pour les images et les styles. La carte a un lien d’aperçu.

Routage par chemin

Path routing sert cette application sous un chemin de l’adresse d’une autre application, comme shop.example.com/api pour votre API, sur un seul certificat. Vous pouvez garder le préfixe ou le retirer.

Les deux applications doivent être sur le même serveur. Le routage entre serveurs n’est pas encore pris en charge.

Votre propre certificat SSL

Settings → Domains → Your own certificates. Collez un certificat PEM, avec sa chaîne, et une clé PEM non chiffrée. Avant d’enregistrer, Railyard vérifie que :

• la clé correspond au certificat;
• le certificat est valide actuellement;
• il couvre au moins une des adresses de l’application.

Le certificat et la clé sont stockés chiffrés, et l’API ne retourne jamais la clé. La carte affiche la date d’expiration, et Railyard envoie un avertissement par les règles app down de l’application 14 jours avant l’expiration. Une fois expiré, le prochain déploiement revient aux certificats Let’s Encrypt automatiques. Les certificats ne peuvent pas aller dans railyard.yml, parce que cela mettrait une clé privée dans git.

API : GET / POST /api/applications/:id/certificates, DELETE …/certificates/:cert_id.

Limitation de débit (bêta)

Rate limiting définit les requêtes par minute par IP cliente. Vous pouvez définir une limite pour toute l’application et ajouter des limites par chemin :

Whole app: 600
/login 10
/api/* 120

Une requête au-delà de la limite reçoit 429 avec Retry-After.

Bêta : les limites de débit ont besoin de l’image de proxy de périphérie propre à Railyard sur le serveur, et cette image est encore en déploiement progressif. Jusqu’à ce que votre serveur l’ait, les règles sont enregistrées mais non appliquées, et la carte comme le journal de déploiement le disent.

Autres limites :

• Les compteurs vivent dans la mémoire de chaque serveur, donc une application sur plusieurs serveurs obtient la limite par serveur.
• Derrière Cloudflare ou un autre proxy, chaque visiteur ressemble à l’IP de ce proxy, et les proxys de confiance ne peuvent pas encore être configurés.

Blocage par pays (bêta)

Countries accepte des codes de pays à deux lettres dans deux listes, allow only et block. UNK couvre les adresses sans pays connu.

• Les visiteurs bloqués reçoivent 403, avant les limites de débit, les redirections ou votre application.
• Les adresses privées et internes passent toujours.
• Les données de pays viennent de DB-IP Lite.

Il a besoin de la même image de proxy de périphérie que la limitation de débit, donc aujourd’hui les règles sont enregistrées mais pas appliquées. La même limitation Cloudflare s’applique.

Pare-feu d’application Web (bêta)

Web application firewall fait passer chaque requête par le OWASP Core Rule Set (injection SQL, XSS et les autres catégories du CRS) avant qu’elle atteigne l’application. Définissez le mode : Off (aucune vérification), Detect (journalisé, sans jamais bloquer, à utiliser d’abord pour voir ce qui aurait été stoppé) ou Block (appliqué, retourne 403). S’applique au prochain déploiement; une requête bloquée apparaît dans les logs de l’application comme tout autre blocage de périphérie.

Il a besoin de la même image de proxy de périphérie que la limitation de débit et le blocage par pays, donc jusqu’à ce que votre serveur l’ait, le réglage est enregistré mais non appliqué, et la carte le précise.

Cloudflare et réseau privé

Mettre le CDN et le WAF de Cloudflare devant l’adresse propre d’une application, le réseau privé entre applications, et un seul certificat pour tout un domaine générique sont couverts dans Réseau.

Domaines personnalisés

L’ajout de domaines, les paires www et domaine nu, les sous-domaines génériques et la vérification de propriété sont couverts dans Domaines.