Authentification

Présentation

Un monitor qui reçoit un 401 signale une panne qui n’en est pas une. Chaque monitor HTTP et gRPC peut donc porter ses propres identifiants, choisis dans le bloc Authentification de la modale de création et du panneau d’édition.

Méthode	Ce qui est envoyé	Disponible sur
Basic auth	Authorization: Basic <utilisateur:mot de passe>	HTTP, gRPC
Jeton Bearer	Authorization: Bearer <jeton>	HTTP, gRPC
Clé d’API	Un en-tête nommé, ou un paramètre d’URL	HTTP, gRPC (en-tête uniquement)
Cookie de session	Un en-tête Cookie brut	HTTP, gRPC
OAuth2 client credentials	Un jeton obtenu auprès de votre IdP, puis Bearer	HTTP
Certificat client (mTLS)	Un certificat client pendant la poignée de main TLS	HTTP

Les monitors base de données, SMTP, IMAP et Redis s’authentifient avec leur propre couple utilisateur / mot de passe — voir Bases de données et Messagerie et cache.

Où vivent les secrets

Tous les secrets de cette page sont chiffrés au repos, dans une colonne distincte de l’URL du monitor. Relire un monitor — par le tableau de bord, l’API publique, le journal d’audit ou un export RGPD — renvoie la méthode et ses réglages non sensibles (le token endpoint, le nom de l’en-tête, l’identifiant client), le secret lui-même étant remplacé par ***.

Ce masque est aussi ce que reçoit le formulaire d’édition. Laissez un champ masqué tel quel et la valeur enregistrée est conservée ; saisissez-en une autre et elle la remplace. C’est pour cela que vous n’avez jamais à ressaisir un jeton pour modifier un réglage sans rapport.

Une clé d’API placée dans l’URL est masquée partout où l’URL est affichée ou journalisée, de la même façon que les identifiants https://utilisateur:motdepasse@hôte sont sortis de l’URL à l’enregistrement.

Jeton Bearer

Le cas le plus courant : un jeton statique émis par le service surveillé.

Authorization: Bearer eyJhbGciOiJIUzI1NiIs…

Collez le jeton seul — OKStatus ajoute le préfixe Bearer .

Clé d’API

Deux formes, parce que les services se partagent entre les deux :

• En-tête — X-API-Key: <clé>, ou le nom attendu par le service.
• Paramètre d’URL — ?api_key=<clé>, ajouté à l’URL du monitor à chaque check.

Préférez l’en-tête quand le service accepte les deux : une clé dans une URL finit dans les journaux d’accès de la cible, ce qui échappe à notre portée.

Cookie de session

Pour un point d’accès qui ne répond qu’à une session navigateur ouverte. Collez le contenu brut de l’en-tête Cookie :

session=abc123; csrf=def456

Un cookie de session expire — souvent en quelques heures ou quelques jours. Les checks se mettent alors à échouer avec le code de la page de connexion. À réserver à un diagnostic ponctuel : pour du durable, l’OAuth2 ou une clé d’API sont la bonne réponse.

OAuth2 client credentials

Pour une API derrière Entra ID, Keycloak, Auth0, Okta, ou tout serveur d’autorisation OAuth2 supportant le grant client_credentials (RFC 6749 §4.4).

Réglage	Description
Token endpoint	ex. https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token
Identifiant client	L’identifiant de l’application
Secret client	Stocké chiffré
Scope	Facultatif — api://monitoring/.default, read:status…
Audience	Facultatif — exigé par Auth0, ignoré par la plupart des autres
Identifiants transmis via	client_secret_basic (en-tête HTTP Basic, par défaut) ou client_secret_post (corps du formulaire)

Avant chaque check, l’agent de région demande un jeton et le garde jusqu’à son expiration (30 s de marge). Un monitor qui tourne toutes les 30 secondes depuis cinq régions demande donc quelques jetons par heure à votre IdP, et non quatorze mille par jour.

Si le token endpoint lui-même échoue, le check échoue avec un message explicite OAuth2 authentication failed: … qui désigne le token endpoint : une panne d’IdP n’est pas une panne du service surveillé, et les deux ne se déboguent pas au même endroit.

Certificat client (mTLS)

Pour un point d’accès qui exige un certificat client : API internes, banque, santé, IoT.

Réglage	Description
Certificat client	PEM. Public par nature, stocké chiffré malgré tout
Clé privée	PEM, PKCS#8 non chiffrée. Stockée chiffrée, jamais renvoyée par l’API
Autorité de certification	PEM, facultatif — pour une PKI interne dont l’autorité n’est pas publiquement reconnue

Une clé protégée par mot de passe est refusée à l’enregistrement plutôt qu’acceptée puis silencieusement inutilisable : les agents de région présentent le certificat via native-tls, qui ne sait pas la déchiffrer. Convertissez-la au préalable :

openssl pkcs8 -topk8 -nocrypt -in cle-chiffree.key -out monitoring.key

Le certificat du serveur reste vérifié contre les autorités publiques (ou l’autorité que vous fournissez). L’option Ignorer la validation TLS du monitor désactive cette vérification, y compris pour la connexion mTLS.

Monitors gRPC

Les checks gRPC envoient les mêmes identifiants en métadonnées : Basic, Bearer, clé d’API en en-tête, ou cookie. Deux formes n’ont pas d’équivalent et sont refusées explicitement plutôt qu’ignorées en silence :

• une clé d’API en paramètre d’URL — un appel gRPC n’a pas de query string ;
• OAuth2 et mTLS — pas encore branchés sur le canal gRPC.

Ce qui n’est pas couvert

AWS SigV4, les JWT auto-signés, les signatures HMAC de requête, NTLM et Kerberos ne sont pas encore disponibles. Les identifiants réutilisables partagés entre monitors (définis une fois, référencés partout) sont à la feuille de route ; aujourd’hui, chaque monitor porte les siens.