Contenerizar una aplicación que firma documentos parece un trámite hasta que se ejecuta el primer despliegue. Ahí aparecen, todas juntas, las contradicciones entre lo que un contenedor es —efímero, replicable, desechable— y lo que un certificado exige —custodia, unicidad y control. Un contenedor se destruye y se recrea decenas de veces al día; una clave privada, en cambio, es un activo que no debería multiplicarse.
Esta guía reúne los problemas que aparecen de verdad en producción, con la decisión que evita cada uno. Vale tanto para un despliegue con un solo servidor como para un orquestador con varias réplicas.
El certificado no va dentro de la imagen
Es la regla número uno y la que más se incumple por comodidad. Copiar el archivo .p12 durante la construcción de la imagen parece práctico y produce un daño duradero:
- La imagen queda almacenada en el registro, y cualquiera con acceso al registro tiene la clave privada.
- Las capas de la imagen conservan el archivo aunque una capa posterior lo borre.
- La imagen se replica en cada nodo del clúster y en cada respaldo del registro.
- Rotar el certificado obliga a reconstruir y redistribuir la imagen completa.
- El archivo suele terminar en el repositorio de código, junto al archivo de construcción.
Las alternativas correctas son inyectar el certificado en tiempo de ejecución mediante el mecanismo de secretos del orquestador, montarlo desde un volumen con permisos restringidos, o —lo más limpio— no tener certificado en el contenedor y usar firma en la nube, donde la aplicación solicita la operación al proveedor. El contraste entre formatos está en nube, .p12 y token.
Variables de entorno: mejor que la imagen, no perfecto
Pasar la contraseña del certificado por variable de entorno es un avance frente a incrustarla en el código, pero conviene conocer sus límites: las variables de un contenedor son visibles para quien pueda inspeccionarlo, pueden quedar registradas en los eventos del orquestador y a veces terminan volcadas en un registro de diagnóstico cuando alguien imprime el entorno para depurar.
Para material realmente sensible, los mecanismos de secretos del orquestador o un servicio dedicado de gestión de secretos ofrecen control de acceso, rotación y auditoría que una variable simple no tiene.
El token USB y el contenedor: conversación cerrada
Aparece en casi todos los proyectos y conviene zanjarlo temprano. Un token USB requiere que el dispositivo esté físicamente conectado al equipo que ejecuta el proceso. En un contenedor local sobre Linux se puede intentar exponer el dispositivo al contenedor, con controladores dentro de la imagen y resultados frágiles. En un contenedor que corre en la nube o en un clúster, es sencillamente imposible: no hay puerto USB al cual conectar nada.
Si la operación necesita ser desatendida y contenerizada, el formato es archivo bajo custodia o firma en la nube. No hay una tercera vía.
Certificados raíz dentro de la imagen
Las imágenes base minimalistas vienen sin el paquete de certificados de autoridades de confianza. Eso produce fallos que confunden porque el mensaje habla de conexión segura o de cadena y no de lo que realmente falta. Dos cuidados:
- Instalar el paquete de certificados raíz en la imagen, de forma explícita en el archivo de construcción.
- Si la aplicación corre sobre un entorno con almacén de confianza propio, como el de Java, incorporar ahí los certificados de la entidad de certificación durante la construcción. El detalle está en firmar desde Java Spring Boot.
Hacer estos cambios a mano dentro de un contenedor en ejecución no sirve: se pierden en el siguiente despliegue y dejan un sistema que funciona por razones que nadie recuerda.
Reloj y zona horaria
Un contenedor toma la hora del anfitrión y, por defecto, suele operar en horario universal coordinado. Eso tiene dos consecuencias directas para la firma. La primera, de trazabilidad: los registros y las marcas de tiempo aparecen con horas que no coinciden con la hora local de Ecuador, lo que complica cualquier conciliación con evidencia externa. La segunda, más seria: si el reloj del anfitrión está desviado, la validación de vigencias y la comprobación del momento de firma se comportan de forma errática.
Las medidas son simples: sincronización horaria garantizada en el anfitrión, zona horaria declarada de forma explícita en la aplicación y sello de tiempo emitido por una fuente confiable en lugar de confiar en el reloj local.
Almacenamiento efímero y documentos en tránsito
El sistema de archivos de un contenedor desaparece cuando el contenedor muere. Si el proceso escribe el documento firmado en una ruta local y el contenedor se reinicia, el resultado se pierde y el trabajo queda a medias.
| Práctica frágil | Práctica robusta |
|---|---|
| Guardar el firmado en el disco del contenedor | Escribirlo en almacenamiento de objetos o volumen persistente |
| Estado del lote en memoria del proceso | Estado por documento en base de datos |
| Temporales sin limpieza | Limpieza garantizada incluso ante error |
| Certificado copiado en la imagen | Secreto inyectado en ejecución o firma en la nube |
| Una réplica que asume ser única | Bloqueo por documento antes de procesar |
El último punto es el que produce incidentes más caros. En un despliegue con varias réplicas, dos contenedores pueden tomar el mismo documento pendiente y firmarlo por duplicado. Sin un mecanismo de exclusión, el problema aparece justo cuando el sistema empieza a tener volumen.
Escalar sin multiplicar el riesgo
La ventaja de los contenedores es agregar réplicas cuando sube la carga. Si cada réplica lleva su copia del archivo .p12, escalar significa multiplicar las copias de la clave privada por el factor de escala, y eso es exactamente lo contrario de custodiar un activo. La firma en la nube resuelve el conflicto de raíz: las réplicas son intercambiables porque ninguna guarda material criptográfico. El enfoque para volúmenes altos está en firma masiva en la nube, y la administración del ciclo de vida, en administración y control de certificados.
Registros, depuración y fugas involuntarias
En entornos contenerizados los registros se centralizan, se indexan y se conservan por meses. Todo lo que el proceso imprima queda ahí, accesible para más gente de la que uno imagina. Reglas mínimas: nunca imprimir el entorno completo, nunca registrar contraseñas ni contenido del certificado, nunca volcar el documento entero en los registros y revisar que las trazas de error no incluyan datos sensibles. Un registro de depuración que alguien dejó activo es una de las formas más comunes de filtrar información sin darse cuenta.
Conviene además reducir la superficie del contenedor: imagen base mínima, proceso que no corre como superusuario, sistema de archivos de solo lectura donde sea posible y sin herramientas de diagnóstico innecesarias dentro de la imagen de producción.
Lista de verificación antes de producción
- Ningún material criptográfico dentro de la imagen ni en el repositorio.
- Secretos gestionados por el orquestador, con rotación prevista.
- Certificados raíz y de la entidad emisora presentes en la imagen.
- Zona horaria explícita y sincronización horaria verificada.
- Resultados y estado en almacenamiento persistente, no en el contenedor.
- Bloqueo por documento en despliegues con varias réplicas.
- Validación del archivo firmado, siguiendo la guía de validación programática.
- Alerta ante crecimiento anómalo de la cola de pendientes.
El marco general de la integración está en la guía de la API de firma electrónica y en la guía técnica para desarrolladores. Sobre certificados: emisión 100% en línea, aproximadamente 30 minutos, en archivo .p12, token USB o firma en la nube. Los valores vigentes, en la página de precios.
Lo que no cabe en un contenedor
El grupo también desarrolla Omnifox, una plataforma omnicanal que reúne WhatsApp, correo, redes sociales y llamadas en una sola bandeja de equipo. Es la pieza que atiende lo que ninguna infraestructura resuelve: la persona del otro lado que pregunta por su documento, el aviso que hay que dar cuando un proceso termina, la conversación que hoy vive dispersa. Con historial y responsable asignado. Más información en omnifox.io.
Preguntas frecuentes
¿Puedo copiar el archivo .p12 dentro de la imagen del contenedor?
No es recomendable. La imagen se almacena en un registro, se replica en cada nodo y conserva el archivo en sus capas aunque después se borre. El certificado debe inyectarse en ejecución o no estar en el contenedor.
¿Se puede usar un token USB desde un contenedor?
Solo con esfuerzo y de forma frágil en un equipo local con el dispositivo conectado. En un contenedor que corre en la nube es imposible, porque no hay dispositivo físico al cual acceder.
¿Por qué falla la conexión segura en una imagen minimalista?
Porque suele faltar el paquete de certificados de autoridades de confianza. Hay que instalarlo de forma explícita durante la construcción de la imagen.
¿Cómo evito que dos réplicas firmen el mismo documento?
Con un bloqueo por documento antes de procesar, apoyado en la base de datos o en el sistema de colas. Sin ese control, el duplicado aparece apenas sube el volumen.
¿Qué formato conviene para una aplicación contenerizada?
La firma en la nube, porque permite que las réplicas sean intercambiables y que ninguna custodie material criptográfico. El archivo .p12 es viable con secretos bien gestionados, pero escala peor.
Si despliegas en contenedores y necesitas firma electrónica con validez legal en Ecuador sin multiplicar copias del certificado, habla con un asesor corporativo de Firmas.com.ec. Solicita tu cotización corporativa.