Uso de claves SSH dentro del contenedor docker

Nota : solo use este enfoque para imágenes que son privadas y siempre serán !

La clave ssh permanece almacenada dentro de la imagen, incluso si elimina la clave en un comando de capa después de agregarla (consulte los comentarios en este post).

En mi caso esto está bien, así que esto es lo que estoy usando:

# Setup for ssh onto github
RUN mkdir -p /root/.ssh
ADD id_rsa /root/.ssh/id_rsa
RUN chmod 700 /root/.ssh/id_rsa
RUN echo "Host github.com\n\tStrictHostKeyChecking no\n" >> /root/.ssh/config

Es un problema más difícil si necesita usar SSH en tiempo de compilación. Por ejemplo, si estás usando git clone, o en mi caso pip y npm para descargar desde un repositorio privado.

La solución que encontré es agregar tus claves usando la bandera --build-arg. Luego puede usar el nuevo comando experimental --squash (agregado 1.13) para fusionar las capas de modo que las claves ya no estén disponibles después de la eliminación. Aquí está mi solución:

Construir command

$ docker build -t example --build-arg ssh_prv_key="$(cat ~/.ssh/id_rsa)" --build-arg ssh_pub_key="$(cat ~/.ssh/id_rsa.pub)" --squash .

Dockerfile

FROM python:3.6-slim

ARG ssh_prv_key
ARG ssh_pub_key

RUN apt-get update && \
    apt-get install -y \
        git \
        openssh-server \
        libmysqlclient-dev

# Authorize SSH Host
RUN mkdir -p /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan github.com > /root/.ssh/known_hosts

# Add the keys and set permissions
RUN echo "$ssh_prv_key" > /root/.ssh/id_rsa && \
    echo "$ssh_pub_key" > /root/.ssh/id_rsa.pub && \
    chmod 600 /root/.ssh/id_rsa && \
    chmod 600 /root/.ssh/id_rsa.pub

# Avoid cache purge by adding requirements first
ADD ./requirements.txt /app/requirements.txt

WORKDIR /app/

RUN pip install -r requirements.txt

# Remove SSH keys
RUN rm -rf /root/.ssh/

# Add the rest of the files
ADD . .

CMD python manage.py runserver

Actualización: Si está utilizando Docker 1.13 y tiene características experimentales, puede agregar --squash al comando build que fusionará las capas, eliminando las claves SSH y ocultándolas de docker history.

Si está utilizando docker compose una opción fácil es reenviar el agente SSH de esta manera:

something:
    container_name: something
    volumes:
        - $SSH_AUTH_SOCK:/ssh-agent # Forward local machine SSH key to docker
    environment:
        SSH_AUTH_SOCK: /ssh-agent

Para inyectarle la clave ssh, dentro de un contenedor, tiene múltiples soluciones:

1. Usando un Dockerfile con la instrucción ADD, puede inyectarlo durante su proceso de compilación

2. Simplemente haciendo algo como cat id_rsa | docker run -i <image> sh -c 'cat > /root/.ssh/id_rsa'

3. Usando el comando docker cp que le permite inyectar archivos mientras se está ejecutando un contenedor.

Expandiendo La respuesta de Peter GraingerPude usar compilación de varias etapas disponible desde Docker 17.05. Los estados de la página oficial:

Con compilaciones de varias etapas, se utilizan varias instrucciones FROM en el archivo Dockerfile. Cada instrucción FROM puede usar una base diferente, y cada una de ellas comienza una nueva etapa de la construcción. Puede copiar artefactos de forma selectiva de una etapa a otra, dejando atrás todo lo que no desea en la final imagen.

Teniendo esto en cuenta aquí está mi ejemplo de Dockerfile incluyendo tres etapas de construcción. Está destinado a crear una imagen de producción de la aplicación web del cliente.

# Stage 1: get sources from npm and git over ssh
FROM node:carbon AS sources
ARG SSH_KEY
ARG SSH_KEY_PASSPHRASE
RUN mkdir -p /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan bitbucket.org > /root/.ssh/known_hosts && \
    echo "${SSH_KEY}" > /root/.ssh/id_rsa && \
    chmod 600 /root/.ssh/id_rsa
WORKDIR /app/
COPY package*.json yarn.lock /app/
RUN eval `ssh-agent -s` && \
    printf "${SSH_KEY_PASSPHRASE}\n" | ssh-add $HOME/.ssh/id_rsa && \
    yarn --pure-lockfile --mutex file --network-concurrency 1 && \
    rm -rf /root/.ssh/

# Stage 2: build minified production code
FROM node:carbon AS production
WORKDIR /app/
COPY --from=sources /app/ /app/
COPY . /app/
RUN yarn build:prod

# Stage 3: include only built production files and host them with Node Express server
FROM node:carbon
WORKDIR /app/
RUN yarn add express
COPY --from=production /app/dist/ /app/dist/
COPY server.js /app/
EXPOSE 33330
CMD ["node", "server.js"]

.dockerignore repite el contenido del archivo .gitignore (evita que se copien los directorios node_modules y dist resultantes del proyecto):

.idea
dist
node_modules
*.log

Ejemplo de comando para construir una imagen:

$ docker build -t ezze/geoport:0.6.0 \
  --build-arg SSH_KEY=$(cat ~/.ssh/id_rsa) \
  --build-arg SSH_KEY_PASSPHRASE=my_super_secret \
  ./

Si su clave SSH privada no tiene una frase de contraseña, simplemente especifique un argumento SSH_KEY_PASSPHRASE vacío.

Esto es cómo funciona:

1). Solo en la primera etapa package.json, yarn.lock los archivos y la clave SSH privada se copian en la primera imagen intermedia llamada sources. Para evitar más mensajes de contraseña de clave SSH, se agrega automáticamente a ssh-agent. Finalmente yarn el comando instala todas las dependencias necesarias de NPM y clona repositorios git privados de Bitbucket sobre SSH.

2). La segunda etapa construye y minifica el código fuente de la aplicación web y lo coloca en el directorio dist de la siguiente imagen intermedia llamada production. Tenga en cuenta que el código fuente de installed node_modules se copia de la imagen llamada sources producida en la primera etapa por esta línea:

COPY --from=sources /app/ /app/

Probablemente también podría ser la siguiente línea:

COPY --from=sources /app/node_modules/ /app/node_modules/

Solo tenemos el directorio node_modules de la primera imagen intermedia aquí, ya no hay argumentos SSH_KEY y SSH_KEY_PASSPHRASE. Todo el resto necesario para la compilación se copia de nuestro directorio de proyectos.

3). En la tercera etapa reducimos un tamaño de la final imagen que será etiquetada como ezze/geoport:0.6.0 incluyendo solo el directorio dist de la segunda imagen intermedia llamada production e instalando Node Express para iniciar un servidor web.

Listing images da una salida como esta:

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ezze/geoport        0.6.0               8e8809c4e996        3 hours ago         717MB
<none>              <none>              1f6518644324        3 hours ago         1.1GB
<none>              <none>              fa00f1182917        4 hours ago         1.63GB
node                carbon              b87c2ad8344d        4 weeks ago         676MB

Donde las imágenes no etiquetadas corresponden a la primera y segunda etapa intermedia de construcción.

Si ejecuta

$ docker history ezze/geoport:0.6.0 --no-trunc

No verás ninguna mención de SSH_KEY y SSH_KEY_PASSPHRASE en la imagen final.

Esta línea es un problema:

ADD ../../home/ubuntu/.ssh/id_rsa /root/.ssh/id_rsa

Al especificar los archivos que desea copiar en la imagen, solo puede usar rutas relativas - relativas al directorio donde se encuentra su Dockerfile. Así que deberías usar:

ADD id_rsa /root/.ssh/id_rsa

Y ponga el archivo id_rsa en el mismo directorio donde está su Dockerfile.

Mira esto para más detalles: http://docs.docker.io/reference/builder/#add

Los contenedores Docker deben ser vistos como 'servicios' propios. Para separar las preocupaciones, debe separar las funcionalidades:

1) Los datos deben estar en un contenedor de datos: use un volumen vinculado para clonar el repositorio. Ese contenedor de datos se puede vincular al servicio que lo necesita.

2) Use un contenedor para ejecutar la tarea de clonación de git, (es decir, su único trabajo es clonar) vinculando el contenedor de datos a él cuando lo ejecute.

3) Lo mismo para la clave ssh: put es un volumen (como se sugiere arriba) y enlázalo al servicio git clone cuando lo necesites

De esta manera, tanto la tarea de clonación como la clave son efímeras y solo están activas cuando es necesario.

Ahora bien, si tu aplicación en sí es una interfaz git, es posible que quieras considerar las API REST de github o bitbucket directamente para hacer tu trabajo: para eso fueron diseñadas.

Este problema es realmente molesto. Dado que no puede agregar/copiar ningún archivo fuera del contexto dockerfile, lo que significa que es imposible simplemente vincular ~/.ssh / id_rsa en /root/de la imagen.ssh / id_rsa, y cuando definitivamente necesitas una clave para hacer algo de sshed como clonar git desde un enlace de repositorio privado..., durante la construcción de su imagen docker.

De todos modos, encontré una solución alternativa, no tan persuasiva, pero funcionó para mí.

1. En su dockerfile:

   • añadir este archivo es / root/.ssh / id_rsa
   • haz lo que quieras, como git clone, composer...
   • rm /root/.ssh / id_rsa al final

2. Un script para hacer en una sesión:

   • cp la clave de la carpeta que contiene dockerfile
   • compilación de docker
   • rm la clave copiada

3. Cada vez que tenga que ejecutar un contenedor desde esta imagen con algunos requisitos ssh, simplemente agregue-v para el comando run, como:

   Docker run-v ~/.ssh / id_rsa: / root/.ssh / id_rsa command nombre de imagen del contenedor comando

Esta solución no da como resultado ninguna clave privada tanto en el origen del proyecto como en la imagen acoplable construida, por lo que ya no hay problemas de seguridad de los que preocuparse.

Tuvimos un problema similar al hacer la instalación de npm en el tiempo de compilación de docker.

Inspirado en la solución de Daniel van Flymen y combinándolo con git url rewrite, encontramos un método un poco más simple para autenticar la instalación de npm desde repositorios de github privados: usamos tokens oauth2 en lugar de las claves.

En nuestro caso, las dependencias npm fueron especificadas como " git + https://github.com/..."

Para la autenticación en contenedor, las url deben ser reescrito para ser adecuado para la autenticación ssh (ssh://[email protected]/) o autenticación de token (https: / / {{GITHUB_TOKEN}@github.com/)

Comando de compilación:

docker build -t sometag --build-arg GITHUB_TOKEN=$GITHUB_TOKEN . 

Desafortunadamente, estoy en docker 1.9, por lo que la opción squash squash aún no está allí, eventualmente debe agregarse

Dockerfile:

FROM node:5.10.0

ARG GITHUB_TOKEN

#Install dependencies
COPY package.json ./

# add rewrite rule to authenticate github user
RUN git config --global url."https://${GITHUB_TOKEN}@github.com/".insteadOf "https://github.com/"

RUN npm install

# remove the secret token from the git config file, remember to use --squash option for docker build, when it becomes available in docker 1.13
RUN git config --global --unset url."https://${GITHUB_TOKEN}@github.com/".insteadOf

# Expose the ports that the app uses
EXPOSE 8000

#Copy server and client code
COPY server /server 
COPY clients /clients

Reenvíe el socket de autenticación ssh al contenedor:

docker run --rm -ti \
        -v $SSH_AUTH_SOCK:/tmp/ssh_auth.sock \
        -e SSH_AUTH_SOCK=/tmp/ssh_auth.sock \
        -w /src \
        my_image

Su script será capaz de realizar un git clone.

Extra: Si desea que los archivos clonados pertenezcan a un usuario específico, debe usar chown ya que usar otro usuario que no sea root dentro del contenedor hará que git falle.

Puede hacer esto publicando en el entorno del contenedor algunas variables adicionales:

docker run ...
        -e OWNER_USER=$(id -u) \
        -e OWNER_GROUP=$(id -g) \
        ...

Después de clonar debe ejecutar chown $OWNER_USER:$OWNER_GROUP -R <source_folder> para establecer la propiedad adecuada antes de salir de la contenedor por lo que los archivos son accesibles por un usuario no root fuera del contenedor.

'puede permitir selectivamente que los servidores remotos accedan a su agente ssh local como si se estuviera ejecutando en el servidor'

Https://developer.github.com/guides/using-ssh-agent-forwarding /

También puede vincular su.directorio ssh entre el host y el contenedor, no se si este método tiene implicaciones de seguridad pero puede ser el método más fácil. Algo como esto debería funcionar:

$ sudo docker run -it -v /root/.ssh:/root/.ssh someimage bash

Recuerde que docker se ejecuta con sudo (a menos que no lo haga), si este es el caso, usará las claves ssh raíz.

Una solución es montar las claves ssh del host en docker con las siguientes opciones:

docker run -v /home/<host user>/.ssh:/home/<docker user>/.ssh <image>

Similar a la solución anterior. Pero funciona con un usuario no root. Funciona perfectamente con github.

Me encontré con el mismo problema hoy y la versión un poco modificada con publicaciones anteriores Encontré este enfoque más útil para mí

docker run -it -v ~/.ssh/id_rsa:/root/.my-key:ro image /bin/bash

(Tenga en cuenta que readonly flag so container no ensuciará mi clave ssh en ningún caso.)

Dentro del contenedor ahora puedo ejecutar:

ssh-agent bash -c "ssh-add ~/.my-key; git clone <gitrepourl> <target>"

Así que no entiendo ese error Bad owner or permissions on /root/.ssh/.. que fue observado por @kross

Estoy tratando de trabajar el problema de la otra manera: agregar clave ssh pública a una imagen. Pero en mis pruebas, descubrí que "docker cp" es para copiar DE un contenedor a un host. El elemento 3 de la respuesta de creak parece estar diciendo que puede usar docker cp para inyectar archivos en un contenedor. Véase https://docs.docker.com/engine/reference/commandline/cp /

Extracto

Copie archivos/carpetas del sistema de archivos de un contenedor a la ruta del host. Las rutas son relativas a la raíz del sistema de archivos.

  Usage: docker cp CONTAINER:PATH HOSTPATH

  Copy files/folders from the PATH to the HOSTPATH

Puede pasar las claves autorizadas a su contenedor usando una carpeta compartida y establecer permisos usando un archivo docker como este:

FROM ubuntu:16.04
RUN apt-get install -y openssh-server
RUN mkdir /var/run/sshd
EXPOSE 22
RUN cp /root/auth/id_rsa.pub /root/.ssh/authorized_keys
RUN rm -f /root/auth
RUN chmod 700 /root/.ssh
RUN chmod 400 /root/.ssh/authorized_keys
RUN chown root. /root/.ssh/authorized_keys
CMD /usr/sbin/sshd -D

Y su docker run contiene algo como lo siguiente para compartir un directorio auth en el host (conteniendo las authorised_keys) con el contenedor y luego abrir el puerto ssh que será accesible a través del puerto 7001 en el host.

-d -v /home/thatsme/dockerfiles/auth:/root/auth -–publish=127.0.0.1:7001:22

Es posible que desee mirar https://github.com/jpetazzo/nsenter que parece ser otro forma de abrir un shell en un contenedor y ejecutar comandos dentro de un contenedor.

Si no le importa la seguridad de sus claves SSH, hay muchas buenas respuestas aquí. Si lo haces, la mejor respuesta que encontré fue de un enlace en un comentario anterior a este comentario de GitHub por diegocsandrim. Para que otros sean más propensos a verlo, y en caso de que el repo desaparezca, aquí hay una versión editada de esa respuesta:

La mayoría de las soluciones aquí terminan dejando la clave privada en la imagen. Esto es malo, ya que cualquier persona con acceso a la imagen tiene acceso a su clave privada. Dado que no sabemos lo suficiente sobre el comportamiento de squash, este puede seguir siendo el caso incluso si elimina la clave y aplasta esa capa.

Generamos una URL de pre-firma para acceder a la clave con aws s3 cli, y limitamos el acceso durante unos 5 minutos, guardamos esta URL de pre-firma en un archivo en el directorio repo, luego en dockerfile la agregamos a la imagen.

En dockerfile tenemos un comando RUN que realiza todos estos pasos: use la URL pre-sing para obtener la clave ssh, ejecute npm install y retire la tecla ssh.

Al hacer esto en un solo comando, la clave ssh no se almacenará en ninguna capa, pero la URL de pre-firma se almacenará, y esto no es un problema porque la URL no será válida después de 5 minutos.

El script de compilación se ve así:

# build.sh
aws s3 presign s3://my_bucket/my_key --expires-in 300 > ./pre_sign_url
docker build -t my-service .

El archivo Dockerfile se ve así:

FROM node

COPY . .

RUN eval "$(ssh-agent -s)" && \
    wget -i ./pre_sign_url -q -O - > ./my_key && \
    chmod 700 ./my_key && \
    ssh-add ./my_key && \
    ssh -o StrictHostKeyChecking=no [email protected] || true && \
    npm install --production && \
    rm ./my_key && \
    rm -rf ~/.ssh/*

ENTRYPOINT ["npm", "run"]

CMD ["start"]

En versiones posteriores de docker (17.05) puede usar compilaciones de varias etapas. Que es la opción más segura ya que las compilaciones anteriores solo pueden ser utilizadas por la compilación posterior y luego se destruyen

Ver la respuesta a mi pregunta de stackoverflow para más información

La forma más sencilla es obtener una cuenta de launchpad y usar: ssh-import-id

Tarde para la parte es cierto, ¿qué tal esto que hará que las claves del sistema operativo del host estén disponibles para rootear dentro del contenedor, sobre la marcha:

docker run -v ~/.ssh:/mnt -it my_image /bin/bash -c "ln -s /mnt /root/.ssh; ssh [email protected]"

No estoy a favor de usar Dockerfile para instalar claves ya que las iteraciones de su contenedor pueden dejar claves privadas atrás.

En un contenedor docker en ejecución, puede emitir ssh-keygen con la opción docker-i (interactiva). Esto reenviará las indicaciones del contenedor para crear la clave dentro del contenedor de docker.