chen-keinan/mesh-kridikVérificateur de sécurité automatisé pour les clusters Kubernetes avec le maillage de services Istio, appliquant les bonnes pratiques via les politiques OPA et générant des rapports de correction pour les mauvaises configurations.
Améliorez la sécurité de votre maillage de services Kubernetes !!
mesh-kridik est un vérificateur de sécurité open-source qui effectue diverses vérifications de sécurité sur un cluster Kubernetes avec le maillage de services Istio et produit un rapport de sécurité.
Les tests de vérification de sécurité sont l'implémentation complète des bonnes pratiques de sécurité Istio
Les vérifications de sécurité effectuées sur un cluster Kubernetes avec le maillage de services Istio sont exploitées par OPA (Open Policy Agent) pour appliquer les règles de sécurité, et le rapport d'audit produit inclut : la cause racine du problème de sécurité et la remédiation proposée pour celui-ci.
git clone https://github.com/chen-keinan/mesh-kridik
cd mesh-kridik
make build
Exécutez Mesh-Kridik sans aucun indicateur pour exécuter tous les tests
./mesh-kridik
Exécutez mesh-kridik avec des indicateurs pour exécuter des tests à la demande
Usage : mesh-kridik [--version] [--help] <commande> [<args>]
Les commandes disponibles sont :
-r , --report : exécute les vérifications de sécurité et génère un rapport de remédiation
-i , --include : exécute uniquement une vérification de sécurité spécifique, exemple -i=1.1
-e , --exclude : ignore une vérification de sécurité spécifique, exemple -e=1.1,2.0
Exécutez les tests et générez un rapport de tests en échec et leurs remédiations
./mesh-kridik -r
| Nom | Description | Impact |
|---|---|---|
| TLS mutuel | Les proxys Istio en TLS mutuel sont configurés par défaut en mode permissif | Les proxys accepteront à la fois le TLS mutuel et le trafic en texte clair |
| Modèles de politique d'autorisation plus sûrs Istio | Utilisez des motifs ALLOW-with-positive-matching ou DENY-with-negative-match | Ces motifs de politique d'autorisation sont plus sûrs car le pire résultat en cas de non-concordance de politique est un rejet inattendu 403 au lieu d'un contournement de la politique d'autorisation. |
| Normalisation de chemin dans la politique d'autorisation | Le point d'application des politiques d'autorisation est le proxy Envoy au lieu du point d'accès habituel aux ressources dans l'application backend | Une non-concordance peut entraîner soit un rejet inattendu, soit un contournement de politique |
| Origine TLS pour le trafic sortant | Utilisation de DestinationRule sur le ServiceEntry pour le trafic sortant | Ne pas utiliser l'origine TLS pour le trafic sortant vers un service externe enverra les données en texte clair |
| Détection de protocole | Déclarez explicitement le protocole du service | Une détection manquée peut entraîner un comportement inattendu du trafic |
| Support CNI | Capture transparente du trafic Istio | Tout le trafic réseau ne sera pas capturé |
| Hôtes trop larges | Évitez les paramètres d'hôtes trop larges dans la passerelle | Peut entraîner une exposition potentielle de domaines inattendus |
| Restreindre les privilèges de création de passerelle | Restreignez la création de ressources de passerelle aux administrateurs de cluster de confiance | Peut entraîner la création de passerelle par des utilisateurs non fiables |
| Configurer une limite sur les connexions en aval | Mettez à jour global_downstream_max_connections dans la config map en fonction du nombre de connexions simultanées nécessaires pour chaque instance de passerelle dans votre déploiement. Une fois la limite atteinte, Envoy commencera à rejeter les connexions TCP | L'absence de limite sur le nombre de connexions en aval peut être exploitée par un acteur malveillant |
| Configurer les jetons de compte de service tiers | Il est recommandé de configurer des jetons tiers car les propriétés du jeton de première partie sont moins sécurisées | Les propriétés du jeton de première partie sont moins sécurisées et pourraient entraîner une violation d'authentification |
| Plan de contrôle | Istiod expose par défaut plusieurs ports en texte clair non authentifiés par commodité | Expose le port du service XDS 15010 et le port de débogage 8080 en texte clair non authentifié |
| Plan de données | Le proxy expose une variété de ports | Les applications exécutées dans le même pod que le proxy y ont accès ; il n'y a pas de frontière de confiance entre le sidecar et l'application |
| Comprendre les limitations de capture de trafic | Sécuriser le trafic sortant en définissant meshConfig.outboundTrafficPolicy.mode | L'accès aux services externes ne sera pas contrôlé |
mesh-kridik expose un hook pour les plugins utilisateur Exemple :
go build -buildmode=plugin -o=~/<dossier plugin>/<plugin>.so ~/<dossier plugin>/<plugin>.go
cp ~/<dossier plugin>/<plugin>.so ~/.kube-kridik/plugins/compile/<plugin>.so
mesh-kridik supporte ces spécifications et peut être facilement étendu :
ces spécifications peuvent être facilement étendues en modifiant les fichiers de spécification sous le dossier ~/.mesh-kridik/security/mesh/istio