Équipes, SSO et accès

Tout dans Railyard appartient à une équipe : ses serveurs, ses applications, ses clés cloud et son historique. Les réglages d’équipe sont sous Settings → Team. Les admins voient tous les onglets; les autres rôles en voient moins.

Rôles

Rôle	Peut
viewer	Voir les applications, les serveurs, les logs et les déploiements
deployer	Aussi déployer, redémarrer, changer les variables et exécuter des commandes
admin	Aussi gérer les membres, les identifiants cloud, les notifications, les jetons, les clés SSH et les réglages d’équipe
owner	Tout. Seuls les owners peuvent accorder, changer ou retirer le rôle owner

Une application peut aussi exiger une deploy approval. Ses déploiements attendent alors qu’une personne les approuve.

Membres et invitations

Team → Members → Invite a member. L’invitation est envoyée par courriel. Vous pouvez la renvoyer, et la liste montre quand elle expire.

Jetons d’API

Team → API tokens. Un jeton est read ou write et peut avoir une date d’expiration. Il n’est affiché qu’une fois, alors copiez-le à ce moment. Les jetons sont ce que la CLI, l’API REST et MCP utilisent. Un jeton fonctionne aussi comme compte de service pour la CI.

Authentification unique (OpenID Connect)

Settings → Single sign-on (admins). Vous pouvez utiliser Google Workspace, Okta, Microsoft Entra, Authentik, Keycloak ou tout autre fournisseur OpenID Connect :

1. Dans votre fournisseur d’identité, créez une application Web OpenID Connect avec l’URI de redirection affichée sur la page.
2. Remplissez Issuer URL, Client ID, Client secret et votre Email domain.
3. Choisissez le rôle avec lequel les nouvelles personnes se joignent : viewer, deployer ou admin.
4. Cochez optionnellement Require SSO for @domain emails, ce qui désactive les mots de passe pour ce domaine.

Les personnes avec ce domaine de courriel utilisent Sign in with SSO sur la page de connexion et se joignent à l’équipe à la première connexion.

SAML 2.0 est pris en charge en plus d’OpenID Connect : choisissez SAML sur la page Single sign-on, collez l’URL de connexion et le certificat du fournisseur d’identité, et Railyard affiche l’URL ACS (de réponse), l’identifiant d’entité et les métadonnées SP à coller dans Okta, Entra, OneLogin, JumpCloud ou ADFS. Les réponses sont vérifiées pour la signature, l’audience, l’heure et l’identifiant de requête.

Domain verification : avant que quiconque puisse se connecter par SSO pour @yourdomain, ajoutez l’enregistrement TXT affiché sur la page (_railyard-sso.<domain>) chez votre fournisseur DNS et vérifiez-le. Le SSO ne connecte jamais un opérateur du site ni un compte existant hors de l’équipe, et les utilisateurs avec la double authentification activée doivent quand même fournir leur code. Changer de domaine signifie vérifier à nouveau.

Provisionnement SCIM

Une fois le SSO enregistré, Create SCIM token et pointez l’application SCIM 2.0 de votre fournisseur d’identité vers https://app.railyard.run/scim/v2 avec ce jeton porteur :

• Assigner quelqu’un dans votre fournisseur d’identité l’ajoute à l’équipe.
• Le désactiver le retire.
• Les owners ne sont jamais retirés.

Un mauvais jeton reçoit 401.

Clés SSH d’équipe

Team → SSH keys. Ajoutez une clé publique (la ligne unique dans ~/.ssh/id_ed25519.pub, jamais une clé privée). Railyard l’installe sur chaque serveur de l’équipe, pour l’utilisateur avec lequel il a configuré le serveur. Elle se place dans son propre bloc de authorized_keys, donc les clés que vous avez ajoutées vous-même ne sont jamais touchées. Retirer une clé, ou retirer un membre, enlève ses clés de chaque serveur en environ une minute. L’onglet Security de chaque serveur montre qui peut se connecter en SSH.

Connexion à deux facteurs

Les membres peuvent activer l’authentification à deux facteurs depuis Settings → Security. Le score de sécurité compte quiconque ne l’a pas.

Journal d’audit

Activity (barre latérale → Operate) enregistre les déploiements, les changements de variables, les changements de membres, les approbations et les jobs de données. Vous pouvez le filtrer par membre, application, type et dates, le parcourir page par page, et export the filtered view as CSV. Les changements de variables apparaissent aussi sur l’onglet Variables de l’application : qui a changé quel nom et quand, mais jamais la valeur.

Les actions qu’un opérateur Railyard effectue sur votre équipe (changer ses limites de serveurs ou d’applications, la suspendre ou la rétablir) atterrissent dans ce même journal, pas dans un journal caché, pour que vous puissiez voir ce qui a été fait et quand.

Score de sécurité

Settings → Security note l’équipe de 0 à 100 à partir de dix vérifications :

• l’authentification à deux facteurs sur chaque membre;
• les admins qui ne se sont pas connectés depuis 90 jours;
• les serveurs avec des mises à jour de sécurité en attente;
• les systèmes d’exploitation en fin de vie;
• ActiveProtect désactivé;
• des ports ouverts supplémentaires;
• des certificats proches de l’expiration;
• aucune sauvegarde vérifiée depuis 30 jours;
• des stagings publics sans mot de passe ni règles IP;
• de vieux jetons d’API qui n’expirent jamais.

Chaque vérification est liée à sa correction. Le score s’affiche aussi sur le tableau de bord.

Déplacer une application vers une autre équipe

Depuis Settings → General de l’application, une application peut se déplacer vers une autre équipe. Ses bases de données, ses volumes, ses domaines et son historique l’accompagnent, et les données d’une application déployée se déplacent vers un serveur de la nouvelle équipe.