Які найкращі та всебічні практики слід враховувати під час роботи докера у виробництві?

Нарешті, ви настільки закохані в Docker, що хочете перенести свої критичні для бізнесу бізнес-системи з чутливими даними клієнтів у Docker Swarm. Деякі, можливо, навіть уже зробили це. Інша організація не може собі цього дозволити, застосовуючи політику, яка забороняє виробничі процеси, що працюють в кореневому режимі.

Що може бути контрольним списком будівельних блоків для продуктивного середовища Docker? Один не потребує всіх, але всі вони повинні мати важливе значення для оцінки.

Відмова: Я знаю, що існує політика SE для уникнення "великих нескінченних списків", але я думаю, що цей контрольний список не може бути дуже великим ... і нескінченним.

Отже - що це за будівельні блоки?

1. Якщо це ще не розгорнуто, розгляньте запуск хост-системи Linux із розширеними налаштуваннями безпеки - загартованим ядром, SELinux тощо.
2. Подумайте про використання крихітного базового зображення Docker, такого як альпійський, зайнятий або навіть подряпин, наприклад, почніть з порожнього базового зображення
3. Використовуйте налаштування USER, крім root
4. Ретельно оцініть, щоб додатково зменшити вже зменшений набір можливостей ядра, наданих контейнеру
5. Подумайте, що для запуску вашого процесу є лише один виконуваний двійковий код на контейнер, ідеально пов'язаний статично
6. Тим, хто хоче зламати вашу систему, щоб отримати доступ до оболонки, може задатися питанням, чи з’ясували, що у вашому контейнері вимкнено всі мушлі
7. Монтуйте томи лише для читання, коли це можливо

Питання: що ще?

Хост, на якому працюють контейнери

Запустіть стенд безпеки докер на кожному вузлі, на якому запущені контейнери докера https://github.com/docker/docker-bench-security

Запуск наступної команди на вузлі, який запускає контейнери докера:

docker run -it --net host --pid host --cap-add audit_control \
    -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
    -v /var/lib:/var/lib \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /usr/lib/systemd:/usr/lib/systemd \
    -v /etc:/etc --label docker_bench_security \
    docker/docker-bench-security

повертає список чеків:

[INFO] 1 - Host Configuration

[WARN] 1.1  - Ensure a separate partition for containers has been created

[NOTE] 4.2  - Ensure that containers use trusted base images

[PASS] 4.6  - Ensure HEALTHCHECK instructions have been added to the container image

Цитата із сховища README:

Док-лав для безпеки - це сценарій, який перевіряє десятки поширених найкращих практик щодо розгортання контейнерів Docker у виробництві. Всі тести автоматизовані та натхненні Benchmark v1.1.0 CIS Community Docker Community Edition .

Деякі проблеми, про які повідомляє служба безпеки, можна було б вирішити, прочитавши офіційну статтю про захист докера та порівнявши її з куль, визначеними в питанні, важливі також такі речі:

• захистити гніздо демона docker, реалізуючи ssl
• вміст довіри з використанням нотаріату та DOCKER_CONTENT_TRUSTзмінної

Докер ще в розробці.

Як і у випадку з будь-яким іншим програмним забезпеченням в розробці, можуть бути додані незахищені функції, можуть виникнути недоліки архітектури, що призводять до порушень безпеки. Не варто цього недооцінювати! Ваша система може бути цілком безпечною сьогодні, але з виправленням наступного тижня хтось виявить помилку, пише подвиг, і раптом ваша система широко відкрита.

Якщо не потрібно, не оновлюйте до останньої версії. Використовуйте натомість останню добре перевірену версію.

Докер - це не віртуалізація

Якщо хтось втече з контейнера Docker, той зловмисник негайно потрапляє на реальну машину. Не існує жодної другої ворота, як віртуалізація, яка б запобігла порушенням.

Ставтесь до контейнера Docker як до будь-якої іншої програми. Запускайте з найменшими можливими правами користувачів, блокуйте весь мережевий трафік, який не потрібен, віртуалізуйте весь хокер Docker, якщо продуктивність дозволяє.

Докер - це не захист

Який би код не запускався всередині контейнерів Docker, запускається без запитання від Docker. Будь-який зловмисник може просто встановити своє програмне забезпечення всередині контейнера, і Docker запустить це, як і будь-який інший код.

Окрім речей, про які ви згадували у запитанні, подумайте про використання показників та сповіщень, щоб отримувати сповіщення, якщо якесь зображення Docker робить дивні речі. Чи є раптовий, постійний сплеск процесора? Чи програма раптово сканує мережеві порти? Чи є підозрілий доступ до диска? Вам слід отримати повідомлення, якщо щось із цього трапиться. Існує багато інструментів для вимірювання цих речей, ви повинні їх використовувати.

Самі зображення Docker

Додатковим варіантом є використання Clair .

Clair - це проект з відкритим кодом для статичного аналізу вразливих місць у контейнерах додатків (включаючи додаток та докер).

Через регулярні інтервали Clair приймає метадані вразливості з налаштованого набору джерел і зберігає їх у базі даних.

Клієнти використовують API Clair для індексації зображень контейнерів; це створює перелік функцій, наявних у зображенні, і зберігає їх у базі даних.

Клієнти використовують API Clair для запиту в базу даних про вразливості певного зображення; співвідношення вразливих місць та особливостей виконується для кожного запиту, уникаючи необхідності переглядати зображення.

Коли відбуваються оновлення метаданих уразливості, системам може бути надіслано сповіщення системам попередження про те, що зміни відбулися.

Наша мета - забезпечити більш прозорий погляд на безпеку інфраструктури на основі контейнерів. Таким чином, проект був названий Клер за французьким терміном, що перекладається на чітке, яскраве, прозоре.

Крім точок у цій нитці; наступна моя рекомендація:

• Отримайте контроль над Docker PID1 за допомогою dumb-init
  • ref: PID1 та проблема пожинання зомбі
• Не запускайте докер у виробництві без контейнерної системи оркестрації
  • Оберіть свій вибір із Kubernetes, Mesos, Swarm тощо.
• Використовуйте gosu для управління користувачем усередині зображення докера
• Дотримуйтесь 12-факторної парадигми додатків, якщо у вас запущені додаткові програми в контейнерах, змініть її.
  • Якщо вам справді потрібно запустити програми, які користуються великим вмістом (mysql, zookeeper, elastsesearch) у контейнерах, використовуйте парадигми оркестратора, як Kubernetes Statefulsets
• Робіть надійне управління секретами / конфігураціями за допомогою таких інструментів, як hashicorp treult / console
• Відправляйте той самий контейнер, який побудували розробники, щоб пропускати через трубопровід CI, який здійснює його шляхом поетапної, інтеграційної тестування.
• Створюйте сповіщення навколо CVE та патчів, запускайте нарощування на патчі-сповіщення
• Проводячи широкий журнал, щоб отримати уявлення про працюючий контейнер, ви не хочете надавати SSH-дискам доступу ні до хоста, ні до контейнерів
  • рекомендація: вільно
• Майте як контейнери, так і показники хоста
  • рекомендація: прометеус + вузол-експортер

Якщо ви заповнюєте свою вхідну точку докера sedкомандами, врахуйте цю практику:

• Використовуйте такий інструмент, як confd, щоб керувати файлами конфігурації зображень докер і постійно оновлювати їх

Confd буде читати дані з багатьох підтримуваних сховищ ключових значень та відображати шаблони конфігурації динамічно.

Можна використовувати A2D, щоб вкласти додаток у зображення докера, беручи до уваги певні речі, наприклад, не-root, дозволи, місцезнаходження програми:

docker run -v $PWD:/projectName utrecht/a2d:1.0.0 \
       -projectName someProjectName -dockerfile /projectName/Dockerfile

повертає:

FROM golang:1.12.4-alpine as builder
COPY . ./someProjectName/
WORKDIR someProjectName
RUN adduser -D -g '' someProjectName && \
    apk add git && \
    CGO_ENABLED=0 go build && \
    cp someProjectName /someProjectName && \
    chmod 100 /someProjectName

FROM scratch
COPY --from=builder /etc/group /etc/group
COPY --from=builder /etc/passwd /etc/passwd
COPY --from=builder --chown=someProjectName:someProjectName /someProjectName /usr/local/someProjectName
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
USER someProjectName
ENTRYPOINT ["/usr/local/someProjectName"]