Как стать автором
Обновить

Комментарии 11

О интересное чтиво, заценим чуть позже. В закладки!
Правильно ли я понимаю, что это только «передача контейнера по http», т.е. когда можно передать его через не безопасную среду, где его не смогут прочитать и получить содержимое, но при его запуске, мы получаем стандартные возможности попасть в него и делать в нем, что угодно?
docker exec id -it -u root bash
Да, то есть мы решаем задачу безопасного хранения образа контейнера. Когда он запускается образ расшифровывается и, естественно, можно зайти внутрь и выполнять в нем команды, в том числе посмотреть что там находится.

Данная история скорее нужна для того чтобы никто не смог прочитать базовый образ, размещенный на машине, когда он остановлен. И, соответственно, запустить его мог только тот у кого есть ключ для расшифровки.
Но после остановки докер образа, файлы все равное какие-то будут в overlayfs, например те, которые уже создались после запуска докера и во время его работы, и они будут явно не зашифрованные?
Да, Read-Write Layer не шифруется, хотя теоретически это возможно реализовать. Если у докера будет публичный ключ, тогда при остановке контейнера он сможет зашифровать все содержимое RW слоя и синкнуть его на диск. А для старта потребуется администратор, который владеет приватным ключом для расшифровки (как базового образа, так и RW слоя).

А вообще судя по всему есть смысл использовать подключаемые volumes с шифрованием — и там хранить данные приложений. Судя по документации, несколько плагинов поддерживают шифрование — BlockBridge plugin и OpenStorage Plugin (https://docs.docker.com/engine/extend/legacy_plugins/). И вот здесь есть примеры шифрования разными инструментами — github.com/e-mission/e-mission-docs/issues/384. Честно скажу сам не тестировал, но судя по описанию и логике это именно то что требуется.

Как альтернатива BlockBridge plugin и OpenStorage Plugin можно использовать zfs encrypted pool. В этом случае весь контейнер хранится на шифрованном volumes, в том числе RW layer. Вы не рассматриваете такую реализацию?

Нет, к сожалению не рассматривали. Сейчас почитал описание storage driver'а zfs — мне понравилось — надо будет протестировать.

Хотя в интернете везде указывают на проблемы с производительностью (как и везде где дело касается zfs на linux) — надо этот момент будет проверить.
я сейчас собираю, что-то подобное, черным критиком выступите? ;)

Всегда за :)

Фразы про эллиптические кривые некорректно сформулированы. Эллиптическая кривая — это математическая абстракция, на которой могут быть основаны асимметричные шифры. Тот же RSA может на них работать, так что лучше уточнить что имеется ввиду, какой именно шифр на эллиптических кривых используется. Для AES хорошо бы казать режим шифрования который был использован, от него зависит периодичность смены ключа.

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

что-то не выглядит убедительно. Целостность обеспечивается через Notary и контроли доступа к хранилищу образов. Деплой — не по тегам, а по digest. А шифрование образа — как мертвому припарки, тогда уж лучше шифровать операционную систему целиком. Как там? RHEL + clevis

Зарегистрируйтесь на Хабре, чтобы оставить комментарий