BookinglyTech News
Infraestructura

EXPOSE no publica nada y la clave KMS no se llama como crees

Tres comportamientos de Docker y AWS KMS donde la lectura evidente es la incorrecta y el fallo no deja rastro: ni error, ni aviso, ni puerto abierto.

3 min de lecturaDev.to0 vistas

Tres detalles de Docker y AWS KMS que se leen mal y fallan en silencio. Una almohadilla al final de una línea de Dockerfile no comenta nada, EXPOSE no publica ningún puerto y el nombre que le das a una clave KMS no vive en la clave. Ninguno de los tres es un bug: son esquinas donde la lectura obvia no es la que aplica y el resultado no da error.

El comentario que es un argumento

En un Dockerfile, la almohadilla solo comenta si abre la línea. En cualquier otra posición, Docker la trata como un argumento más. ENV DEBIAN_FRONTEND=noninteractive # comenta esto no es un ENV con una nota al margen: el # y lo que sigue se pasan como argumentos adicionales y el build revienta. Cuesta poco creer que es un comentario, porque en casi cualquier lenguaje lo es.

Hay tres decisiones más en ese Dockerfile que no son de estilo. apt-get update e install van en el mismo RUN porque cada instrucción es una capa cacheada: si los separas, un build posterior puede reutilizar un índice desactualizado y fallar con un 404 en un paquete que existe. apt-get clean y el borrado de listas van también ahí por lo mismo, ya que eliminar archivos en una capa posterior no encoge la imagen, porque las capas solo suman. Y apachectl -D FOREGROUND es lo único que mantiene el contenedor en pie: un contenedor vive lo que vive PID 1, y el arranque normal de Apache se demoniza, el padre sale con código 0 y Docker lo interpreta como fin de la ejecución.

EXPOSE 5004 no abre nada. Solo documenta qué puertos escucha la aplicación. El puerto se publica con -p 5004:5004 en el docker run. Sin ese flag tienes un contenedor correcto, funcionando e inalcanzable.

El alias no es la clave

aws kms create-key no acepta ningún --name. Devuelve un UUID, y la clave solo tiene descripción y etiquetas. Lo que todo el mundo llama el nombre de la clave es un alias, un recurso aparte que apunta a ella, así que hacerlo son siempre dos llamadas. El prefijo alias/ es obligatorio y forma parte del nombre.

La indirección sirve para lo que sirve: un alias vale para cifrar, descifrar, DescribeKey y GetPublicKey, pero no para programar el borrado, que sigue pidiendo el ID. Dentro de ese margen puedes reapuntar el alias a otra clave sin tocar nada de lo que cifra a través de él.

En el manejo de ficheros hay más trampas. fileb:// lee bytes crudos; file:// trata el contenido como texto y en la CLI v2 espera que ya venga en base64. Con un fichero de texto plano, lo segundo cifra los bytes equivocados sin decir nada. La salida hay que decodificarla porque la API devuelve el criptograma en base64, que es el apaño de JSON para transportar binario: se quita al salir de la API y se vuelve a poner al entrar. Al descifrar no hace falta --key-id, porque el blob ya lleva dentro el ARN de la clave. Los tamaños lo delatan: 25 bytes de texto plano se convierten en 177 de criptograma, y ese sobrecargo no es relleno, lleva la clave, el algoritmo y la clave de datos envueltos.

Lo incómodo de los tres casos no es la sintaxis, es que ninguno falla con ruido. El Dockerfile construye, el contenedor arranca, el comando termina con éxito y el resultado está mal. Para quien despliega, la lección práctica es revisar estos puntos antes de que los descubra un incidente en producción.