1. В данном случае мы использовали cloudflare как dns для нашей зоны. И включили проксирование чтобы SSL автоматически подрубился. У MCS есть свой CDN — mcs.mail.ru/cdn и его как раз можно будет использовать с s3 для отдачи статического контента.
2. Для верификации нужно подтвердить почту, телефон и привязать карту. Такие требования вроде у всех облачных провайдеров (не помню, регистрировался везде сто лет назад).
Спасибо за позитивный фидбек! По поводу начальных вещей с удовольствием прикрутим — в конце апреля будем делать Kubernetes с установкой и базовой настройкой. Следите за анонсами и подключайтесь :)
Да, 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. Честно скажу сам не тестировал, но судя по описанию и логике это именно то что требуется.
Да, то есть мы решаем задачу безопасного хранения образа контейнера. Когда он запускается образ расшифровывается и, естественно, можно зайти внутрь и выполнять в нем команды, в том числе посмотреть что там находится.
Данная история скорее нужна для того чтобы никто не смог прочитать базовый образ, размещенный на машине, когда он остановлен. И, соответственно, запустить его мог только тот у кого есть ключ для расшифровки.
2. Для верификации нужно подтвердить почту, телефон и привязать карту. Такие требования вроде у всех облачных провайдеров (не помню, регистрировался везде сто лет назад).
Спасибо за позитивный фидбек! По поводу начальных вещей с удовольствием прикрутим — в конце апреля будем делать Kubernetes с установкой и базовой настройкой. Следите за анонсами и подключайтесь :)
Всегда за :)
Хотя в интернете везде указывают на проблемы с производительностью (как и везде где дело касается zfs на linux) — надо этот момент будет проверить.
А вообще судя по всему есть смысл использовать подключаемые volumes с шифрованием — и там хранить данные приложений. Судя по документации, несколько плагинов поддерживают шифрование — BlockBridge plugin и OpenStorage Plugin (https://docs.docker.com/engine/extend/legacy_plugins/). И вот здесь есть примеры шифрования разными инструментами — github.com/e-mission/e-mission-docs/issues/384. Честно скажу сам не тестировал, но судя по описанию и логике это именно то что требуется.
Данная история скорее нужна для того чтобы никто не смог прочитать базовый образ, размещенный на машине, когда он остановлен. И, соответственно, запустить его мог только тот у кого есть ключ для расшифровки.