Planteamiento y alcance
Un equipo planea actualizar de PostgreSQL 18 a PostgreSQL 19. Los clústeres actuales utilizan RADIUS y algo de autenticación por contraseña MD5; los clientes incluyen aplicaciones, scripts de operaciones y herramientas de BI. Explica cómo realizarías el inventario de dependencias, elegirías los reemplazos, validarías los clientes y definirías las condiciones de parada.
El aviso oficial de la versión Beta de PostgreSQL describe una vista previa de características preliminares y desaconseja el uso directo en producción. Las notas de migración de la versión 19 eliminan el soporte para RADIUS y emiten una advertencia tras una autenticación MD5 exitosa; RADIUS solo era compatible a través de UDP, lo cual el proyecto describe como irremediablemente inseguro. La pregunta evalúa una migración de autenticación basada en evidencias, sin asumir que todos los entornos se ven afectados.
Qué evalúa el entrevistador
El entrevistador espera que separes la eliminación de protocolos, los formatos de contraseñas y la capacidad de los clientes; que construyas un inventario completo de dependencias; y que definas reemplazos con privilegios mínimos, un despliegue observable y la reversión (rollback). Una respuesta sólida también señala que los resultados en versiones Beta no representan compromisos para la versión final y no tergiversa una advertencia de MD5 como un bloqueo inmediato de la conexión.
Preguntas de clarificación antes de responder
- ¿Cuáles son las versiones de PostgreSQL actual y de destino, y cuándo se espera la versión final?
- ¿Qué puntos de entrada utilizan RADIUS y qué usuarios o conexiones siguen utilizando MD5?
- ¿Los controladores (drivers), pools y herramientas de operaciones admiten SCRAM, certificados o un proxy de identidad?
- ¿Cómo se gestionan el servidor de autenticación, la ruta de red, los requisitos de auditoría, la conmutación por error (failover) y las cuentas de emergencia?
- ¿De qué tiempo de inactividad, ventana de reversión y responsable de seguridad se dispone?
Estructura de respuesta en 30 segundos
“Trataría la versión Beta como un objetivo de validación aislado. Primero inventariaría cada regla de pg_hba.conf, formato de contraseña, cliente y dependencia de RADIUS; luego validaría SCRAM, certificados o un proxy de identidad controlado en un clúster de prueba de PostgreSQL 19. Mantendría disponibles las rutas antiguas y nuevas para la misma identidad durante la reproducción de conexiones, conmutaciones por error y escenarios de auditoría; luego migraría primero a los inquilinos de bajo riesgo mientras observo los fallos de autenticación, la latencia y las brechas de auditoría. Cualquier fallo de inicio de sesión, ampliación de privilegios, pérdida de auditoría o fallo en la reversión detiene el despliegue, preservando el clúster antiguo y la ruta de autenticación.”
Respuesta detallada paso a paso
1. Construir el inventario de dependencias
Exporta y revisa pg_hba.conf, los atributos de roles, el almacenamiento de contraseñas, los orígenes de conexión, las versiones de clientes, los pools y los scripts de automatización. Marca por separado RADIUS, MD5, SCRAM, certificados y proxies externos; registra el usuario, la red, la base de datos, la prioridad de la regla y el propietario de cada una. No busques únicamente en el repositorio de la aplicación: los scripts temporales y las herramientas de BI también pueden contener credenciales de conexión.
2. Separar la eliminación de la advertencia
Las notas de migración de PostgreSQL 19 eliminan RADIUS; una autenticación MD5 exitosa produce una advertencia en el cliente controlable mediante md5_password_warnings. Una advertencia señala trabajo de migración; no significa que las conexiones actuales ya sean rechazadas. Reemplaza las dependencias de RADIUS antes de la actualización y programa la migración de contraseñas y reglas para las dependencias de MD5 en lugar de tratar los riesgos como idénticos.
3. Elegir un reemplazo y restringir privilegios
Evalúa SCRAM-SHA-256, certificados de cliente o un proxy de identidad empresarial existente, en función del soporte del cliente, el ciclo de vida de las claves, los límites de red y los requisitos de auditoría. Crea cuentas de migración temporales con privilegios mínimos, nunca superusuarios compartidos; separa las cuentas antiguas de las nuevas y define expiración y propiedad. El diseño debe contemplar la conmutación por error, las réplicas de solo lectura, las cuentas de emergencia para operaciones (break-glass) y la recuperación fuera de línea.
4. Validar la matriz de conexiones de forma aislada
Recrea la topología de producción con datos anonimizados y credenciales separadas. Prueba la aplicación, el pool, las herramientas de migración, la restauración de copias de seguridad, la monitorización y la conmutación por error uno por uno. Fija una versión de driver para cada cliente y registra el método de autenticación, TLS, tiempo de conexión, motivo del fallo y evento de auditoría. Es razonable mantener las rutas de acceso antiguas y nuevas para un mismo rol durante las pruebas, pero las credenciales de prueba nunca deben llegar a producción.
psql "host=pg19-test dbname=app user=app_scram sslmode=verify-full" -c 'select 1'
psql "host=pg19-test dbname=app user=app_cert sslmode=verify-full" -c 'select 1'5. Diseñar el canary, los puntos de control (gates) y la reversión
Mueve primero a los inquilinos de bajo riesgo o los trabajos no críticos. Establece umbrales para fallos de autenticación, latencia de conexión, éxito en el restablecimiento de contraseñas, completitud de auditoría y éxito de conmutación por error; detén el proceso ante ampliaciones de privilegios, fallos de inicio de sesión, brechas de auditoría o fallos de recuperación. Mantén una copia ejecutable de PostgreSQL 18, versiones anteriores de las reglas, registros de rotación de contraseñas y scripts de reversión, y verifica que los clientes antiguos puedan recuperarse dentro de la ventana de reversión.
6. Registrar la incertidumbre de la versión Beta
El comportamiento y las interfaces de la versión Beta aún pueden cambiar. Redacta las conclusiones como resultados para un cliente, configuración de autenticación y conjunto de datos de prueba determinados; registra versiones, hashes de configuración y problemas conocidos, y luego solicita la aprobación final tras el lanzamiento de la versión definitiva. Un clúster de prueba exitoso no demuestra la compatibilidad para todos los clientes.
Ejemplo de respuesta de alta calidad
Congelaría la línea base de autenticación de PostgreSQL 18 y construiría una matriz de pg_hba.conf, roles, clientes y dependencias de RADIUS por punto de entrada y propietario. Dado que PostgreSQL 19 elimina RADIUS, validaría SCRAM, certificados o un proxy de identidad empresarial para las identidades afectadas en un clúster aislado, mientras gestiono a los usuarios de MD5 restantes por separado; la advertencia por MD5 exitoso señala tareas de migración, pero no es un rechazo generalizado. Reproduciría aplicaciones, pools, scripts, restauración de copias de seguridad y conmutación por error mientras observo fallos, latencia, auditoría y límites de privilegios. Solo después de que un canary de bajo riesgo supere cada punto de control lo expandiría; una ampliación de privilegios, pérdida de auditoría, fallo de inicio de sesión o fallo de reversión detiene el despliegue. La evidencia de la versión Beta sigue siendo un insumo para la aprobación de la versión final.
Errores comunes
- Tratar la eliminación de RADIUS y la advertencia de MD5 como el mismo evento → uno elimina el soporte, el otro señala migración → inventaríalos y planifícalos por separado.
- Modificar únicamente
pg_hba.confsin probar los clientes → los drivers y pools pueden carecer de soporte → reproduce una matriz completa de clientes. - Rotar todas las contraseñas de producción al mismo tiempo → la superficie de fallos y de reversión se vuelve demasiado grande → aísla, utiliza cuentas temporales con privilegios mínimos y migra por lotes.
- Ignorar las cuentas de emergencia (break-glass) → una interrupción del servicio puede eliminar el acceso de recuperación → prepara accesos de emergencia controlados y auditados.
- Presentar el éxito en Beta como una garantía de compatibilidad definitiva → el comportamiento preliminar puede cambiar → registra los límites y vuelve a aprobar en la versión final.
Preguntas de seguimiento y respuestas
¿Cuándo debe detenerse la actualización?
Detén el proceso ante fallos de inicio de sesión, ampliación de privilegios, brechas de auditoría, incompatibilidad crítica de clientes, fallo en la conmutación por error o una reversión que no pueda completarse dentro de la ventana prevista.
¿Por qué no reemplazar RADIUS por cualquier método de contraseña?
La robustez de la autenticación, el ciclo de vida de las claves, los límites de la red y los requisitos de auditoría difieren. El reemplazo debe satisfacer la política de seguridad y cubrir a los clientes y los escenarios de fallo.
¿Una advertencia de MD5 implica desconectar a todos los usuarios de MD5 de inmediato?
No. La advertencia expone una ruta que aún necesita migración. Identifica a los clientes, rota las credenciales, valida SCRAM, certificados o un proxy, y realiza el cambio por lotes.
¿Cómo demuestras que no se omitieron clientes ocultos?
Correlaciona registros de conexión, registros de auditoría, uso de roles, orígenes de red, búsquedas en repositorios y entrevistas de operaciones a lo largo de una ventana de tiempo fija; monitoriza orígenes desconocidos y fallos de autenticación antes y después de la migración.
¿Cuándo puede entrar a producción un cambio probado en Beta?
Tras la publicación de la versión final, una nueva validación de la versión y de la matriz de clientes, simulacros exitosos de reversión y auditoría, y la aprobación conjunta de los responsables de seguridad, base de datos y negocio, seguido de un despliegue canary observable.