amazon web services - nube - ¿Cuál es la mejor manera de pasar las credenciales de AWS al contenedor Docker?

instalar docker en aws

Question

Estoy ejecutando docker-container en Amazon EC2. Actualmente he agregado las credenciales de AWS a Dockerfile. ¿Podrías decirme la mejor manera de hacer esto?

Answer 1

La mejor manera es usar el rol de IAM y no tratar con credenciales en absoluto. (ver http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html )

Las credenciales se pueden recuperar de http://169.254.169.254..... Como se trata de una dirección IP privada, solo se puede acceder desde instancias de EC2.

Todas las bibliotecas de cliente de AWS modernas "saben" cómo obtener, actualizar y usar credenciales desde allí. Entonces, en la mayoría de los casos, ni siquiera necesita saberlo. Simplemente ejecute ec2 con el rol de IAM correcto y listo.

Como opción, puede pasarlos en tiempo de ejecución como variables de entorno (es decir, la docker run -e AWS_ACCESS_KEY_ID=xyz -e AWS_SECRET_ACCESS_KEY=aaa myimage )

Puede acceder a estas variables de entorno ejecutando printenv en la terminal.

Answer 2

Mucho ha cambiado en Docker desde que se hizo esta pregunta, así que aquí hay un intento de una respuesta actualizada.

Primero, específicamente con las credenciales de AWS en los contenedores que ya se están ejecutando dentro de la nube, usar las funciones de IAM como sugiere Vor es una muy buena opción. Si puede hacerlo, agregue uno más más uno a su respuesta y omita el resto de esto.

Una vez que comience a ejecutar cosas fuera de la nube, o tenga un tipo diferente de secreto, hay dos lugares clave que recomiendo contra el almacenamiento de secretos:

1. Variables de entorno: cuando se definen en un contenedor, todos los procesos dentro del contenedor tienen acceso a ellos, son visibles a través de / proc, las aplicaciones pueden volcar su entorno a stdout donde se almacena en los registros, y lo más importante, aparecen en texto claro cuando inspecciona el contenedor.

2. En la imagen en sí: las imágenes a menudo se envían a registros donde muchos usuarios tienen acceso de extracción, a veces sin ninguna credencial requerida para extraer la imagen. Incluso si elimina el secreto de una capa, la imagen se puede desmontar con utilidades comunes de Linux como tar y el secreto se puede encontrar en el paso donde se agregó por primera vez a la imagen.

Entonces, ¿qué otras opciones hay para los secretos en los contenedores Docker?

Opción A: si necesita este secreto solo durante la construcción de su imagen, no puede usar el secreto antes de que comience la construcción y todavía no tiene acceso a BuildKit, entonces una construcción de varias etapas es la mejor de las malas opciones. Agregaría el secreto a las etapas iniciales de la compilación, lo usaría allí y luego copiaría la salida de esa etapa sin el secreto a su etapa de lanzamiento, y solo empujaría esa etapa de lanzamiento a los servidores de registro. Este secreto todavía está en el caché de imágenes en el servidor de compilación, por lo que tiendo a usar esto solo como último recurso.

Opción B: también durante el tiempo de compilación, si puede usar BuildKit que se lanzó en 18.09, actualmente hay características experimentales para permitir la inyección de secretos como un montaje de volumen para una sola línea RUN. Ese montaje no se escribe en las capas de imagen, por lo que puede acceder al secreto durante la compilación sin preocuparse de que se envíe a un servidor de registro público. El Dockerfile resultante se ve así:

# syntax = docker/dockerfile:experimental
FROM python:3
RUN pip install awscli
RUN --mount=type=secret,id=aws,target=/root/.aws/credentials aws s3 cp s3://... ...

Y lo construyes con un comando en 18.09 o más reciente como:

DOCKER_BUILDKIT=1 docker build -t your_image --secret id=aws,src=$HOME/.aws/credentials .

Opción C: en tiempo de ejecución en un solo nodo, sin Modo enjambre u otra orquestación, puede montar las credenciales como un volumen de solo lectura. El acceso a esta credencial requiere el mismo acceso que tendría fuera de Docker al mismo archivo de credenciales, por lo que no es mejor ni peor que el escenario sin Docker. Lo más importante, el contenido de este archivo no debe ser visible cuando inspecciona el contenedor, ve los registros o empuja la imagen a un servidor de registro, ya que el volumen está fuera de eso en cada escenario. Esto requiere que copie sus credenciales en el host del acoplador, aparte de la implementación del contenedor. (Tenga en cuenta que cualquier persona con la capacidad de ejecutar contenedores en ese host puede ver su credencial ya que el acceso a la API de Docker es root en el host y root puede ver los archivos de cualquier usuario. Si no confía en los usuarios con root en el host , entonces no les dé acceso a la API de Docker).

Para una docker run , esto se ve así:

docker run -v $HOME/.aws/credentials:/home/app/.aws/credentials:ro your_image

O para un archivo de composición, tendría:

version: ''3''
services:
  app:
    image: your_image
    volumes:
    - $HOME/.aws/credentials:/home/app/.aws/credentials:ro

Opción D: con herramientas de orquestación como Swarm Mode y Kubernetes, ahora tenemos soporte de secretos que es mejor que un volumen. Con el modo Enjambre, el archivo se cifra en el sistema de archivos del administrador (aunque la clave de descifrado a menudo también está allí, lo que permite que el administrador se reinicie sin que un administrador ingrese una clave de descifrado). Más importante aún, el secreto solo se envía a los trabajadores que lo necesitan (ejecutar un contenedor con ese secreto), solo se almacena en la memoria del trabajador, nunca en el disco, y se inyecta como un archivo en el contenedor con un tmpfs montar. Los usuarios en el host fuera del enjambre no pueden montar ese secreto directamente en su propio contenedor, sin embargo, con acceso abierto a la API de Docker, pueden extraer el secreto de un contenedor en ejecución en el nodo, así que nuevamente, limite quién tiene este acceso al API De componer, esta inyección secreta se ve así:

version: ''3.7''

secrets:
  aws_creds:
    external: true

services:
  app:
    image: your_image
    secrets:
    - source: aws_creds
      target: /home/user/.aws/credentials
      uid: ''1000''
      gid: ''1000''
      mode: 0700

Activa el modo enjambre con docker swarm init para un solo nodo, luego sigue las instrucciones para agregar nodos adicionales. Puede crear el secreto externamente con docker secret create aws_creds $HOME/.aws/credentials . Y despliega el archivo docker stack deploy -c docker-compose.yml stack_name con docker stack deploy -c docker-compose.yml stack_name .

A menudo versiono mis secretos usando un script de: https://github.com/sudo-bmitch/docker-config-update

Opción E: existen otras herramientas para administrar secretos, y mi favorito es Vault porque brinda la capacidad de crear secretos de tiempo limitado que caducan automáticamente. Cada aplicación obtiene su propio conjunto de tokens para solicitar secretos, y esos tokens les dan la posibilidad de solicitar esos secretos de tiempo limitado mientras puedan llegar al servidor de la bóveda. Eso reduce el riesgo si alguna vez se saca un secreto de su red, ya que no funcionará o caducará rápidamente. La funcionalidad específica de AWS for Vault se documenta en https://www.vaultproject.io/docs/secrets/aws/index.html

Answer 3

Otro enfoque es crear un volumen temporal de solo lectura en docker-compose.yaml. AWS CLI y SDK (como boto3 o AWS SDK para Java, etc.) están buscando default perfil default en el archivo ~/.aws/credentials .

Si desea utilizar otros perfiles, solo necesita exportar la variable AWS_PROFILE antes de ejecutar el comando docker-compose

export AWS_PROFILE=some_other_profile_name

version: ''3''

services:
  service-name:
    image: docker-image-name:latest
    environment:
      - AWS_PROFILE=${AWS_PROFILE}
    volumes:
      - ~/.aws/:/root/.aws:ro

En este ejemplo utilicé usuario root en docker. Si está utilizando otro usuario, simplemente cambie /root/.aws al directorio de inicio del usuario

:ro - significa volumen de acoplador de solo lectura

Es muy útil cuando tiene varios perfiles en el archivo ~/.aws/credentials y también está utilizando MFA. También es útil cuando desea probar localmente el docker-container antes de implementarlo en ECS en el que tiene roles de IAM, pero localmente no.

Answer 4

Otro enfoque es pasar las claves de la máquina host al contenedor acoplable. Puede agregar las siguientes líneas al archivo docker-compose .

services:
  web:
    build: .
    environment:
      - AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
      - AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
      - AWS_DEFAULT_REGION=${AWS_DEFAULT_REGION}