Prisma Cloud Calcul : Nœuds OpenShift en transition vers l'état 'NotReady' avec la règle de blocage dans Policy

Prisma Cloud Calcul : Nœuds OpenShift en transition vers l'état 'NotReady' avec la règle de blocage dans Policy

11347
Created On 04/04/23 02:33 AM - Last Modified 02/18/26 03:38 AM


Symptom


  • Nœuds OpenShift en transition vers l'état « Pas prêt » avec la règle de blocage dans Policy

image.png


Environment


  • Prisma Cloud Calcul (auto-hébergé et SaaS)
  • OpenShift


Cause


Runtime du conteneur (CRIO)
 
  • Lorsque la avec une règle de blocage est appliquée ou supprimée, un redémarrage du runtime de conteneur (CRIO) peut se produire car les défenseurs dans l’étendue permutent le binaire *runc* sur les nœuds où ils sont déployés pour recharger la Policy configuration d’exécution
  • Le redémarrage des services (et Kublet) peut prendre quelques minutes après CRIO le rechargement de la configuration
  • Pendant ce temps, Node peut passer à l'état 'NotReady' lorsque CRIO ou Kubelet n'est pas disponible
  • Pendant ce temps, le nœud de travail ne peut pas exécuter/planifier des charges de travail tant qu’il n’est pas revenu à l’état Prêt
  • L’état NotReady est attendu lors Prisma Cloud de l’exécution de l’échange dans les scénarios suivants :
  1. Arrêt du défenseur
  2. Début du défenseur
  3. La première règle de blocage est ajoutée
  4. La dernière règle de blocage est supprimée
  5. Mise à niveau du défenseur (car elle provoque le redémarrage du défenseur)

Important à noter
 
  • Cet état NotReady est remarqué ONLY avec CRIO l’environnement d’exécution en raison de la restriction avec OpenShift dans l’interception des appels à runc
  • Il s’agit de la conception actuelle avec CRIO le runtime


Resolution


  • A Le redémarrage du CRIO runtime peut être nécessaire
  • Comme la transition d'état « NotReady » se produit dans certains scénarios, ce problème peut être évité en s'abstenant d'apporter les modifications suivantes :
  1. Ajout de la première règle de blocage
  2. Suppression de la dernière règle de blocage
  3. Redémarrage / Mise à niveau de Defender
  4. Basculer l’option Injection secrète

Contournement
  • Créez une règle de bloc factice dans le Policy et appliquez-la au cluster pour faire passer les nœuds à l'état « Pas prêt » une fois.
  • Affichez ceci, apportez les modifications nécessaires aux Policy règles au besoin
Référence : Règle de blocage


Additional Information


Stratégies de blocage des règles

Il s’agit notamment des éléments suivants :
  • Défendre = > Conformité => Images de confiance - toute règle de blocage
  • Défendre = > Conformité = > Conteneurs et images = > Déployé - toute règle de blocage
  • Défendre = > Conformité = > Hôtes => Hôtes - toute règle de blocage
  • Défendre => Accès => Secrets - toute règle qui existe
  • Défendre = > Vulnérabilités = > Images = > déployé
  • Toute règle ayant un effet bloquant
  • Toute règle a un ensemble d’exceptions avec un CVE effet de blocage
  • Toute règle a un ensemble d’exceptions avec un tag effet de blocage
  • Toute règle a un seuil de bloc


Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000g1DdCAI&lang=fr&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language