Изучение новой функции доверия Docker

Современное развитие все чаще включает использование третьих сторон. Будь то программирование библиотек из репозиториев, таких как npm или GitHub , использование платформ, таких как Azure и AWS , или просто копирование примера кода из переполнения стека , справедливо сказать, что большая часть кода, используемого в приложении, будет написана кем-то, кроме основного разработчика.

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

Доверять

С использованием третьих сторон возникает неизбежный вопрос: «Доверяю ли я этому источнику?»

То, что звучит как довольно простой вопрос, на самом деле довольно сложно ответить. Что мы подразумеваем под «доверием» для начинающих? В таких репозиториях, как Docker Hub, мы хотим быть уверены, что программное обеспечение, предоставленное автором, совпадает с тем, что мы получаем из репозитория, поэтому мы можем верить, что оно не было случайно или злонамеренно изменено во время его хранения на сервере. Сделки рЕПО.

Для репозиториев приложений основным способом решения проблемы доверия является предоставление возможности разработчикам подписывать контент, который они размещают в системе. Правильно реализованные цифровые подписи могут помочь пользователям убедиться в том, что они используют тот же контент, который создал первоначальный разработчик, и по существу удаляют репозиторий из доверенной картинки.

Доверие к контенту

Итак, давайте поговорим о реализации этого принципа в Docker с помощью функции, вышедшей в 1.8, Docker Content Trust . Благодаря этому в Docker реализован ряд мер безопасности, которые позволяют разработчикам подтвердить, что используемые ими изображения не были изменены Docker, а также что они получают последнюю доступную версию.

При реализации доверия к контенту Docker взял идеи из The Update Framework , которая является открытой спецификацией, направленной на устранение рисков компрометации репозитория кода. Была проделана работа по ряду реализаций для таких вещей, как упаковка библиотек Python, но с Content Trust, Docker, возможно, является наиболее распространенной на сегодняшний день реализацией.

Реализация Доверия Доверия

Так что это все замечательные вещи в теории, но что это означает на самом деле? Как это реализовано, и что это делает для жизненных циклов управления образами пользователей Docker?

Первое, что нужно отметить, это то, что реализация Content Trust ограничивает возможности развертывания образов в Docker Hub. Обычно используемый подход автоматической сборки не будет работать с Content Trust, потому что с помощью этого метода не владелец репозитория создает изображения, а сам Docker Hub. Очевидно, что если Hub выполняет сборку, будет трудно предотвратить его модификацию!

Поэтому, если вы планируете внедрить Доверие к контенту, вам нужно будет применить подход к созданию образа, а затем перенести его из вашей системы в Docker Hub.

Возможно, лучший способ объяснить Доверие к контенту, как и в случае с большинством новых концепций, — это проработать пример. Если вы хотите попробовать это, вам потребуется учетная запись в Docker Hub и современная (1.8+) установка Docker, настроенная для входа в нее.

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

Во-первых, давайте включим Доверие к контенту, так как оно не включено по умолчанию. Для этого запустите:

Это будет установлено только для текущей сессии bash. Если вы хотите, чтобы он был установлен постоянно, убедитесь, что переменная окружения установлена ​​для пользователя, отправляющего в хранилище при входе в систему.

Далее мы хотим создать изображение и добавить к нему тег, чтобы мы могли отправить его в концентратор. Здесь мы указываем имя пользователя, хранилище и тег, который мы хотим установить. Затем мы будем строить на основе по умолчанию с именем Dockerfile.

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

Теперь мы помещаем образ в Docker Hub, используя следующую стандартную команду:

Это будет выглядеть как любой другой толчок, но затем вы получите текст, аналогичный тому, что я покажу вам дальше. Вам будет предложено создать ключевые фразы для «автономного» ключа и «тегового» ключа.

Очевидно, что создание сильной уникальной парольной фразы — хорошая идея; доступ к ключам позволит злоумышленникам подписывать изображения как вы сами, что в значительной степени противоречит цели Content Trust. Это немного усложняет некоторые процессы развертывания. Например, если вы автоматически создаете новые сборки, вам необходимо предоставить парольную фразу для ключа для подписи изображения. Docker предоставляет механизм для этого, используя переменные окружения , но вы должны быть очень уверены в безопасности своего хоста сборки при этом. Очевидно, что любой, кто сможет прочитать переменные окружения, которые используются для этого, получит ваши парольные фразы!

Ключевой менеджмент

Используемые здесь ключи являются очень важной частью процесса Доверия Доверия, поэтому на данном этапе стоит обсудить управление ключами.

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

Для системы Docker Content Trust два сгенерированных ключа должны обрабатываться несколько по-разному.

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

Ключ можно найти в ~ / .docker / trust / private / root_keys. Чтобы защитить его, хорошей идеей может быть что-то вроде зашифрованного USB-ключа (или двух, в зависимости от его важности).

Другой ключ, который был создан, является ключом тегирования. Он хранится в:

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

Итак, теперь, когда у нас есть подписанное изображение, что это на самом деле означает? Что ж, для пользователей образа они могут включить Docker Content Trust. Они будут уверены, что когда они загрузят изображение, оно не было изменено с тех пор, как разработчик его подтолкнул, и что это новое изображение для этого тега.

Использование Доверия Доверия

Однако на данный момент включение Доверия к контенту может показаться немного разочаровывающим для пользователей, так как оно усложняет блокировку извлечения любого тега, который не подписан. Если вы включили Доверие к контенту и пытаетесь извлечь хранилище без подписи, вы получите следующее сообщение и не получите свое изображение:

Надеемся, что это станет меньшей проблемой, так как больше репозиториев обеспечивают Доверие к контенту. Однако, если вы хотите запустить его с включенным и по-прежнему использовать неподписанные теги, вы можете передать ключ -disable-content-trust команде Docker для выполнения отдельных операций без включенного Доверия.

Вывод

В целом, Docker Content Trust — действительно полезная функция, если вы хотите создавать надежные образы на основе Docker. В нем рассматривается ключевой вопрос безопасности, который может затмить открытые программные репозитории. Надеюсь, он будет хорошо воспринят пользователями Docker Hub.