Prisma Cloud Compute: Nodos OpenShift en transición al estado 'NotReady' con la regla de bloqueo en Policy

Prisma Cloud Compute: Nodos OpenShift en transición al estado 'NotReady' con la regla de bloqueo en Policy

10136
Created On 04/04/23 02:33 AM - Last Modified 04/07/23 07:38 AM


Symptom


  • Nodos OpenShift en transición al estado 'NotReady' con la regla de bloqueo en Policy

Image.png


Environment


  • Prisma Cloud Computación (autohospedada y SaaS)
  • OpenShift


Cause


Tiempo de ejecución del contenedor (CRIO)
 
  • Cuando se aplica o elimina el con una regla de bloqueo, puede producirse un reinicio del tiempo de ejecución del contenedor (CRIO) porque los defensores en el ámbito intercambian el Policy binario *runc* en los nodos donde se implementan para volver a cargar la configuración del tiempo de ejecución
  • Los servicios (y Kublet) pueden tardar unos minutos en CRIO reiniciarse después de volver a cargar la configuración.
  • Durante este tiempo, Node puede cambiar al estado 'NotReady' cuando CRIO o Kubelet no está disponible
  • Mientras tanto, el nodo de trabajo no puede ejecutar/programar cargas de trabajo hasta que vuelva al estado Listo
  • El estado NotReady se espera cuando Prisma Cloud se realiza el intercambio runc en los siguientes escenarios:
  1. Parada del defensor
  2. Inicio del defensor
  3. Se agrega la primera regla de bloqueo
  4. Se elimina la última regla de bloqueo
  5. Actualización de Defender (ya que provoca el reinicio del defensor)

Importante a tener en cuenta
 
  • Este estado NotReady se observa ONLY con el entorno de CRIO tiempo de ejecución debido a la restricción con OpenShift para interceptar las llamadas a runc
  • Este es el diseño actual con CRIO tiempo de ejecución


Resolution


  • A Es posible que sea necesario reiniciar el CRIO motor en tiempo de ejecución
  • Como la transición de estado 'NotReady' ocurre durante ciertos escenarios, este problema se puede evitar absteniéndose de realizar los siguientes cambios:
  1. Agregar la primera regla de bloqueo
  2. Eliminación de la última regla de bloqueo
  3. Reinicio / actualización de Defender
  4. Alternar la opción Inyección secreta

Solución
  • Cree una regla de bloque ficticia en el Policy y aplíquela al clúster para hacer la transición de los nodos al estado 'NotReady' una vez.
  • Publique esto, haga los cambios necesarios en las Policy Reglas cuando sea necesario
Referencia : Regla de bloqueo


Additional Information


Directivas de reglas de bloqueo

Esto incluye lo siguiente:
  • Defender => Cumplimiento => Imágenes de confianza: cualquier regla de bloqueo
  • Defender => Cumplimiento => Contenedores e imágenes => Implementado: cualquier regla de bloqueo
  • Defender => Cumplimiento => Hosts => Hosts - cualquier regla de bloqueo
  • Defender => Acceso => Secretos - cualquier regla que exista
  • Defender => Vulnerabilidades => Imágenes => Desplegado
  • Cualquier regla que tenga un efecto de bloqueo
  • Cualquier regla tiene un conjunto en excepciones con un CVE efecto de bloqueo
  • Cualquier regla tiene un conjunto en excepciones con un tag efecto de bloqueo
  • Cualquier regla tiene un umbral de bloqueo


Actions
  • Print
  • Copy Link

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

Choose Language