Parchado

La siguiente documentación es una solución temporal para el parchado Log4j2

Temporal
Se implementó de manera transversal añadir una variable de ambiente
LOG4J_FORMAT_MSG_NO_LOOKUPS=true a todos los deployment en los ambientes no
productivos.

Autogestión
A través del pipeline general Admin_eks_resources se habilita la opción de parchado a
demanda donde como parámetros debe elegir la cuenta, el namespace, el deployment al cual
desea habilitar la solución de parchado.

Solución definitiva
La solución temporal y de autogestión son variables añadidas de manera provisional, si se
lanza un nuevo despliegue de la aplicación estas variables se perderan por eso es de suma
importancia que cada equipo añada la variable dentro del manifest de sus respectivos
deployment.

Este es un ejemplo para añadir la variable desde el manifest de su deployment

apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: app-pruebas
 name: yonier-deployment
namespace: bco-dev
spec:
replicas: 2
selector:
matchLabels:
app: app-pruebas
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
labels:
app: app-pruebas
spec:
containers:
- env:
- name: LOG4J_FORMAT_MSG_NO_LOOKUPS
value: "true"

NOTA IMPORTANTE: Tener en cuenta que cada vez que aplique un nuevo
deployment los pods se reiniciaran, si desea utilizar la opción de autogestión
sucederá lo mismo.