Portal Checker : un dashboard pour monitorer tous vos endpoints Kubernetes

J’ai 40 Ingress et HTTPRoutes répartis sur plusieurs namespaces. Lequel est cassé ? Quel certificat expire dans 3 jours ? Est-ce qu’il y a une API Swagger exposée sans auth quelque part ?

Impossible de répondre sans ouvrir chaque ressource une par une. kubectl get ingress donne les URLs, pas leur état de santé. Et pour les certificats SSL, il faut curl chaque endpoint et parser le résultat. Pas viable quand on gère des dizaines d’applications.

J’ai donc créé Portal Checker. Il découvre automatiquement tous les Ingress et HTTPRoutes du cluster, teste leur disponibilité en parallèle, et affiche un dashboard avec l’essentiel : status HTTP, latence, expiration SSL, et APIs exposées.

Ce que Portal Checker apporte

Le dashboard centralise toutes les infos qu’il faut habituellement aller chercher manuellement :

• Status HTTP en temps réel avec temps de réponse
• Expiration des certificats SSL avec code couleur selon l’urgence
• Détection automatique des endpoints Swagger et OpenAPI
• Analyse de sécurité : PII exposés, tokens visibles dans les schémas
• Filtrage par namespace, status, ou texte libre

Les checks tournent en background toutes les 30 secondes. Le cache évite de surcharger les endpoints.

Comment ça marche

┌─────────────────────────────────────────────────────────────────┐
│                    Kubernetes API                               │
│                                                                 │
│  - Liste tous les Ingress (networking.k8s.io/v1)               │
│  - Liste tous les HTTPRoutes (gateway.networking.k8s.io/v1)    │
└───────────────────────────┬─────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│                   Portal Checker (FastAPI)                      │
│                                                                 │
│  1. Découverte des ressources via kubernetes-client             │
│  2. Extraction des URLs depuis les specs Ingress/HTTPRoute      │
│  3. Health check HTTP en parallèle (aiohttp)                    │
│  4. Vérification SSL et date d'expiration                       │
│  5. Scan des paths Swagger connus (/swagger, /api-docs, etc.)  │
└───────────────────────────┬─────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│                      Dashboard Web                              │
│                                                                 │
│  - Vue tabulaire de tous les endpoints                         │
│  - Tri par status, latence, expiration SSL                     │
│  - Modal de détail pour chaque endpoint                        │
│  - Export JSON des résultats                                   │
└─────────────────────────────────────────────────────────────────┘

Le service tourne dans le cluster avec un ServiceAccount qui a les droits de lecture sur les Ingress et HTTPRoutes. Il n’a pas besoin d’accès aux Secrets ou aux Pods.

Un exemple concret : détecter une API Swagger exposée

Je viens de déployer une nouvelle application. En ouvrant Portal Checker, je vois qu’elle est marquée avec un badge “Swagger”. En cliquant sur le détail, je découvre que /api-docs est accessible publiquement.

Le scanner teste automatiquement les paths classiques :

• /swagger
• /swagger-ui
• /api-docs
• /openapi.json
• /v3/api-docs

Si un de ces paths répond avec du JSON OpenAPI valide, il est flaggé. L’analyse va plus loin : elle parse le schéma pour détecter des champs sensibles comme password, token, ssn, ou credit_card dans les modèles exposés.

Configuration

Variables d’environnement principales :

• REQUEST_TIMEOUT : timeout HTTP en secondes (défaut 10)
• MAX_CONCURRENT_REQUESTS : nombre de checks en parallèle (défaut 10)
• CHECK_INTERVAL : fréquence des tests en secondes (défaut 30)
• ENABLE_AUTOSWAGGER : activer la détection des APIs (défaut true)
• SSL_WARNING_DAYS : seuil d’alerte pour les certificats (défaut 30)

Pour exclure certaines URLs du monitoring :

excludedUrls:
  - "monitoring.*"
  - "*.internal/*"
  - "health.*/.*"

Les patterns supportent les wildcards * pour matcher plusieurs segments.

Déploiement

Le chart Helm inclut tout ce qu’il faut :

helm install portal-checker helm/ \
  --namespace monitoring \
  --create-namespace

kubectl port-forward svc/portal-checker 8080:80 -n monitoring

Le dashboard est accessible sur http://localhost:8080.

Pour une installation permanente, configurez un Ingress ou un HTTPRoute pointant vers le service.

API

Le backend expose quelques endpoints utiles pour l’intégration :

Code source

Le projet est open source sur GitHub.