Listas de acceso y modo de mantenimiento

Las Access Lists y el modo de mantenimiento responden a dos preguntas de gestión: quién puede llegar al servicio y si el servicio debe aceptar tráfico de clientes durante un trabajo planificado. Úsalos como controles explícitos y auditables en lugar de cambios temporales de DNS, Routes eliminadas o excepciones de cortafuegos sin documentar.

Si se hace bien, los clientes permitidos mantienen el acceso, los clientes denegados quedan bloqueados siempre, y el mantenimiento devuelve un 503 deliberado mientras el nombre de host, TLS y la configuración de la Route se mantienen en su sitio.

Las listas de acceso combinan reglas de IP y autenticación HTTP básica opcional. Aplica la lista más restrictiva que cumpla el requisito y prueba tanto un cliente permitido como uno denegado. Trata los secretos de autenticación básica guardados como credenciales y rótalos cuando cambien los miembros. Eliminar una lista, o desactivar su autenticación básica, elimina su archivo de contraseñas de todos los nodos Ingress conectados, y la sincronización completa de un nodo tras reconectarse elimina los archivos de contraseñas que ya no usa ninguna configuración.

Las Access Lists están en la página Routes, en la pestaña Access Lists.

El modo de mantenimiento está disponible para las Routes gestionadas activadas que no usan configuración en bruto. Conserva el host virtual HTTP/HTTPS, devuelve HTTP 503, pausa las comprobaciones de estado gestionadas y expone el estado de mantenimiento a las alertas y las páginas de estado.

Usa el modo de mantenimiento para trabajos deliberados visibles para los clientes. No simules un mantenimiento eliminando una Route, desactivando TLS o apuntando a un upstream ficticio; esas acciones destruyen estado útil y dificultan la recuperación.

Antes de salir del modo de mantenimiento, confirma que el upstream está en buen estado, que las migraciones han terminado y que las bases de datos o los Secure Links dependientes están listos.

Flujo de trabajo de las listas de acceso

1. Define el conjunto más pequeño de reglas de permitir o denegar que represente al público previsto.
2. Añade autenticación HTTP básica solo cuando el cliente pueda proteger y rotar la credencial.
3. Asocia primero la lista a una Route de prueba o a un nombre de host de bajo riesgo.
4. Verifica una dirección permitida y otra denegada desde fuera del host de nginx.
5. Revisa los logs de acceso de nginx para confirmar que la decisión vino de la política prevista.
6. Asocia la política a otras Routes solo cuando la prueba sea concluyente.

Cambiar una Access List reutilizable afecta a todas las Routes asociadas. Antes de editar una política compartida, inspecciona sus relaciones y crea una lista separada cuando una aplicación necesite un límite distinto.

Entra en mantenimiento de forma segura

Antes de activar el modo de mantenimiento:

• confirma que la Route está gestionada y activada;
• registra el estado actual y el despliegue activo;
• publica un incidente en la página de estado cuando se espere que los clientes lo noten;
• asegúrate de que los operadores conservan una vía administrativa que no quede bloqueada por la Route de la aplicación;
• decide qué verificación demuestra que el trabajo de mantenimiento ha terminado.

Una Route que pertenece a una app también se puede poner en mantenimiento desde su entorno o desde la app completa. Ese mantenimiento se suma al interruptor propio de la Route, que conserva su valor y vuelve a aplicarse cuando termina el mantenimiento del entorno o de la app; la página de la Route muestra de dónde viene su mantenimiento. Un código de acceso de mantenimiento emitido para un entorno o para la app abre una vez cada una de sus Routes en mantenimiento.

Opfield mantiene el host virtual y el comportamiento de TLS mientras devuelve 503. Así, la monitorización y la comunicación con los clientes son explícitas y se evitan cambios innecesarios de DNS o de certificados.

Sal y verifica

1. Verifica el upstream directamente o a través de su comprobación de estado gestionada.
2. Confirma que las vinculaciones de bases de datos, las migraciones y los servicios dependientes están listos.
3. Desactiva el modo de mantenimiento.
4. Haz una petición externa al nombre de host canónico.
5. Verifica el código de estado, el cuerpo esperado, TLS, las redirecciones y el comportamiento de WebSocket cuando corresponda.
6. Resuelve el incidente de la página de estado solo cuando la comprobación externa sea correcta.

Si la Route sigue sin estar disponible, vuelve a activar el mantenimiento en lugar de cambiar repetidamente ajustes no relacionados. Usa Solución de problemas del tráfico entrante para identificar la capa que ha fallado.

Evaluación de políticas y seguridad de los cambios

Documenta si la lista está pensada para restringir una superficie administrativa, un endpoint privado de clientes o una aplicación pública completa. Las reglas mezcladas de permitir y denegar son fáciles de malinterpretar durante un incidente, así que mantén la política pequeña y ponle el nombre del público al que protege. Prueba la dirección de cliente efectiva que ve nginx, sobre todo cuando las peticiones llegan a través de una CDN u otro proxy de confianza; probar solo la dirección aparente del navegador puede validar la regla equivocada.

La autenticación básica complementa la política de red, pero no sustituye a TLS. Úsala solo en Routes HTTPS, guarda la credencial generada a través de la vía de secretos compatible y entrégala fuera de los logs de la aplicación o de los tickets. Quitar a un usuario de una credencial compartida exige rotar esa credencial para todos los usuarios restantes; usa listas separadas cuando sea importante revocar de forma independiente.

Antes de editar una Access List compartida, registra todas las Routes asociadas y el comportamiento actual para una petición permitida y otra denegada. Haz el cambio una sola vez, espera la confirmación de nginx y repite ambas pruebas. Si la validación o la aplicación fallan, conserva la última política confirmada y corrige la nueva revisión en lugar de desvincular el control de acceso de las Routes de producción.

Recuperación de emergencia

Una Access List puede dejar a los operadores fuera de una aplicación, pero no debería bloquear la vía de administración de Opfield salvo que esa vía se haya colocado deliberadamente detrás de la misma política. Si se deniega a todos los clientes esperados, verifica la dirección de origen que aparece en los logs de acceso y la configuración de proxies de confianza antes de ampliar el rango permitido.

Cuando sea necesario restablecer el servicio de inmediato, restaura la lista anterior que se sabe que funcionaba o asocia una lista de emergencia de alcance limitado con una vida operativa corta. No la sustituyas por un acceso público sin restricciones salvo que el responsable del incidente acepte explícitamente esa exposición. Tras la recuperación, elimina las reglas temporales, rota las credenciales de emergencia y verifica todas las Routes que compartían la lista original.