безопасное использование удаленного API докера - PullRequest
0 голосов
/ 13 ноября 2018

Я пытаюсь найти эффективный способ безопасного использования удаленного API докера. У меня есть демон Docker, работающий на удаленном хосте, и клиент Docker на другом компьютере. Мне нужно, чтобы мое решение не зависело от операционной системы клиент / сервер, чтобы оно подходило для любой машины с клиентом / демоном Docker и т. Д.

Пока что единственный способ сделать это - создать сертификаты на машине Linux с openssl и вручную скопировать сертификаты на клиент / сервер, как в этом примере:

https://docs.docker.com/engine/security/https/

, а затем настройте докер с обеих сторон для использования сертификатов для шифрования и аутентификации.

На мой взгляд, этот метод довольно неуклюжий, потому что иногда возникает проблема скопировать файлы и поместить их на каждую машину, с которой я хочу использовать удаленный API.

Я ищу что-то более элегантное.

Другое решение, которое я нашел, - это использование прокси-сервера для базовой HTTP-аутентификации, но в этом методе трафик не зашифрован, и он не является таким безопасным.

У кого-нибудь есть предложение по другому решению или по способу улучшения одного из вышеперечисленных?

Ответы [ 2 ]

0 голосов
/ 13 ноября 2018

Исходя из ваших комментариев, я бы посоветовал вам использовать Ansible, если вам не нужна функциональность роя и требуется поддержка только одного хоста.Для Ansible требуется только доступ по SSH, который у вас, вероятно, уже имеется.

Очень легко использовать существующий сервис, определенный в Docker Compose, или вы можете просто вызывать свои сценарии оболочки в Ansible.Нет необходимости открывать демон Docker для внешнего мира.

Очень простой файл примера (playbook.yml)

- hosts: all
  tasks:
  - name: setup container
    docker_container:
      name: helloworld
      image: hello-world

Запуск playbook ansible-playbook -i username@mysshhost.com, playbook.yml

Ansibleпредоставляет практически все функции, необходимые для взаимодействия с Docker через его модульную систему:

docker_service
    Use your existing Docker compose files to orchestrate containers on a single Docker daemon or on Swarm. Supports compose versions 1 and 2.
docker_container
    Manages the container lifecycle by providing the ability to create, update, stop, start and destroy a container.
docker_image
    Provides full control over images, including: build, pull, push, tag and remove.
docker_image_facts
    Inspects one or more images in the Docker host’s image cache, providing the information as facts for making decision or assertions in a playbook.
docker_login
    Authenticates with Docker Hub or any Docker registry and updates the Docker Engine config file, which in turn provides password-free pushing and pulling of images to and from the registry.
docker (dynamic inventory)
    Dynamically builds an inventory of all the available containers from a set of one or more Docker hosts.
0 голосов
/ 13 ноября 2018

Ваш любимый инструмент системной автоматизации ( Chef , SaltStack , Ansible ), вероятно, может напрямую управлять запущенными контейнерами Docker на удаленном хосте, не открывая другой корень-эквивалентный сетевой путь.Существуют Docker-ориентированные инструменты кластеризации ( Docker Swarm , Nomad , Kubernetes , AWS ECS ), которые могут запускать контейнер локально или удаленно, но у вас меньше контроля над тем, где именно (вас часто это не волнует), и они, как правило, захватывают машины, на которых они работают.

Если бы мне действительно пришлось управлять системами таким образом, я бывероятно, используйте какое-то централизованное хранилище для хранения клиентских ключей TLS, скорее всего, Vault , обладающее свойством хранения зашифрованных ключей, требующим некоторого уровня аутентификации для их получения и возможностью контроля доступаих.Вы могли бы написать такую ​​функцию оболочки, как это (не проверено):

dockerHost() {
  mkdir -p "$HOME/.docker/$1"
  JSON=$(vault kv get -format=json "secret/docker/$1")
  for f in ca.pem cert.pem key.pem; do
    echo "$JSON" | jq ".data.data.[\"$f\"]" > "$HOME/.docker/$1/$f"
  done
  export DOCKER_HOST="https://$1:2376"
  export DOCKER_CERT_PATH="$HOME/.docker/$1"
}

Хотя ваш вопрос проясняет, что вы понимаете это, стоит повторить: не разрешать удаленный доступ без проверки подлинности к демону Docker поскольку захватить хост с неограниченным корневым доступом тривиально, если вы вообще можете получить доступ к сокету.

...