Portal Checker : un dashboard pour monitorer tous vos endpoints Kubernetes | DC Tech

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 (30 secondes par défaut, 5 minutes dans le déploiement Helm via CHECK_INTERVAL). Les caches (URLs, résultats de test, infos SSL) évitent de surcharger les endpoints et l’API Kubernetes.

Comment ça marche

┌─────────────────────────────────────────────────────────────────┐
│                    Kubernetes API                               │
│                                                                 │
│  - Liste tous les Ingress (networking.k8s.io/v1)               │
│  - Liste tous les HTTPRoutes (gateway.networking.k8s.io/v1beta1)│
└───────────────────────────┬─────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│               Portal Checker (Flask + Hypercorn)                │
│                                                                 │
│  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                                   │
└─────────────────────────────────────────────────────────────────┘

Portal Checker Dashboard

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

Détail Swagger

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 (src/autoswagger_integration.py) :

/openapi.json, /openapi.yaml, /openapi.yml
/swagger.json, /swagger.yaml, /swagger.yml
/api/swagger.json, /api/openapi.json, /docs/swagger.json
/api-docs, /api-docs.json
/docs, /redoc, /swagger-ui.html
/v1/swagger.json, /v2/swagger.json, /v3/swagger.json

Si un de ces paths répond avec une spec OpenAPI/Swagger valide (JSON, YAML, ou embarquée dans un HTML Swagger UI), 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 (valeurs par défaut dans src/config.py) :

REQUEST_TIMEOUT : timeout HTTP en secondes (défaut 5)
MAX_CONCURRENT_REQUESTS : nombre de checks en parallèle (défaut 20)
CHECK_INTERVAL : fréquence des tests en secondes (défaut 30 ; 300 dans le chart Helm)
KUBERNETES_POLL_INTERVAL : TTL du cache de découverte K8s (défaut 600)
CACHE_TTL_SECONDS : TTL du cache des résultats de test (défaut 300)
SSL_CACHE_TTL_SECONDS : TTL du cache des infos certificats (défaut 3600)
ENABLE_AUTOSWAGGER : activer la détection des APIs (activé par défaut dans l’image, désactivé dans le chart Helm via autoswagger.enabled)
CUSTOM_CERT : certificat CA personnalisé (optionnel)

L’expiration des certificats est affichée telle quelle (jours restants + date) ; Portal Checker ne bloque pas sur un seuil.

Pour exclure certaines URLs du monitoring, le fichier config/excluded-urls.yaml est une simple liste de patterns :

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

Les patterns supportent les wildcards * (fnmatch) pour matcher plusieurs segments. Par ailleurs, une ressource peut être exclue avec l’annotation Kubernetes portal-checker.io/exclude: "true", et le dashboard expose un bouton « Exclure » qui alimente /api/exclude.

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 :

Endpoint	Description
`GET /api/urls`	Liste complète des URLs avec status et temps de réponse
`GET /api/swagger`	Résultats de la détection Swagger (cache)
`POST /api/swagger/scan/<url>`	Scan Swagger ponctuel d’une URL précise
`POST /api/refresh-async`	Redécouverte K8s + tests en arrière-plan (réponse 202)
`GET /api/refresh-status`	État du refresh asynchrone (running/erreur)
`GET/POST /api/auto-refresh`	Lire/activer le toggle auto-refresh
`POST /api/exclude`	Ajouter une URL aux exclusions
`GET /api/excluded-urls`	Lister les URLs exclues
`GET /health`	Healthcheck (utilisé par les probes Kubernetes)
`GET /memory`	Usage mémoire RSS/VMS du processus

Code source

Le projet est open source sur GitHub.

Ce que vous devez retenir

Sur un cluster, inventorier automatiquement les endpoints évite de maintenir à la main une liste de services à suivre.
Tester le statut HTTP ne suffit pas : certificats, temps de réponse et documentation OpenAPI exposée apportent des informations complémentaires.
Les exclusions doivent rester explicites et versionnées pour que le comportement du monitoring reste compréhensible.
Le bon compromis est un outil léger de contrôle des endpoints, pas une seconde plateforme de supervision généraliste.