📦 Первые контейнеры.
• Первые контейнеры, официально называвшиеся именно этим термином, появились в феврале 2004 года в операционной системе Solaris 10 от Sun Microsystems, они использовались на серверах с архитектурой x86 и SPARC. Solaris Containers включали в себя изолированные «песочницы» для запуска ОС (в терминологии разработчика они назывались «зонами»), а также инструменты управления системными ресурсами, допускавшими создание «моментальных снимков» отдельных зон и их клонирование. То есть, механизмы оркестрации.
• Зоны представляли собой полностью изолированные виртуальные серверы внутри хостовой операционной системы. Каждый такой экземпляр ОС имел собственное сетевое имя, использовал выделенные сетевые интерфейсы, собственную файловую систему, набор пользователей (включая root) и конфигурацию. При этом для работы виртуального сервера не требовалось жестко выделять память или процессор — аппаратные ресурсы использовались общие, однако при необходимости администратор имел возможность зарезервировать определенные серверные мощности для какой-то конкретной зоны. Процессы внутри контейнеров выполнялись изолированно, не имели доступа друг к другу и потому не могли конфликтовать.
• Основным отличием Solaris Containers от предшественников (Process Containers, LXC и Warden, #Docker и #Kubernetes) можно назвать то обстоятельство, что, как и ранее, виртуальные ОС использовали ядро хостовой системы, но при желании администратор мог запускать копии системы в контейнерах с собственным ядром. Это стало следующим важным шагом в эволюции технологий контейнеризации.
#Разное
• Первые контейнеры, официально называвшиеся именно этим термином, появились в феврале 2004 года в операционной системе Solaris 10 от Sun Microsystems, они использовались на серверах с архитектурой x86 и SPARC. Solaris Containers включали в себя изолированные «песочницы» для запуска ОС (в терминологии разработчика они назывались «зонами»), а также инструменты управления системными ресурсами, допускавшими создание «моментальных снимков» отдельных зон и их клонирование. То есть, механизмы оркестрации.
• Зоны представляли собой полностью изолированные виртуальные серверы внутри хостовой операционной системы. Каждый такой экземпляр ОС имел собственное сетевое имя, использовал выделенные сетевые интерфейсы, собственную файловую систему, набор пользователей (включая root) и конфигурацию. При этом для работы виртуального сервера не требовалось жестко выделять память или процессор — аппаратные ресурсы использовались общие, однако при необходимости администратор имел возможность зарезервировать определенные серверные мощности для какой-то конкретной зоны. Процессы внутри контейнеров выполнялись изолированно, не имели доступа друг к другу и потому не могли конфликтовать.
• Основным отличием Solaris Containers от предшественников (Process Containers, LXC и Warden, #Docker и #Kubernetes) можно назвать то обстоятельство, что, как и ранее, виртуальные ОС использовали ядро хостовой системы, но при желании администратор мог запускать копии системы в контейнерах с собственным ядром. Это стало следующим важным шагом в эволюции технологий контейнеризации.
#Разное
• Awesome Cloud Security Labs - объемный набор бесплатных лаб для самостоятельного изучения безопасности облачных сред и технологий:
➡ AWS;
➡ Azure;
➡ GCP;
➡ Kubernetes;
➡ Container;
➡ Terraform;
➡ Research Labs;
➡ CI/CD.
➡ https://github.com/iknowjason/Awesome-CloudSec-Labs
#Cloud #ИБ
#Cloud #ИБ
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - iknowjason/Awesome-CloudSec-Labs: Awesome free cloud native security learning labs. Includes CTF, self-hosted workshops…
Awesome free cloud native security learning labs. Includes CTF, self-hosted workshops, guided vulnerability labs, and research labs. - GitHub - iknowjason/Awesome-CloudSec-Labs: Awesome free clou...
• Сетевые политики — основополагающий аспект защиты кластеров Kubernetes. Политики L4 обеспечивают базовый контроль над трафиком на основе IP-адресов и портов, в то время как политики L7 позволяют гранулярно контролировать трафик на уровне приложений с помощью надёжной криптографической идентификации. Комбинируя оба типа политик и используя service mesh, можно реализовать модель «нулевого доверия», отвечающую современным вызовам в области безопасности.
• Это руководство для тех, кто хочет узнать больше об управлении сетевым трафиком Kubernetes на основе политик. Вы узнаете о разных типах политик и о том, почему они важны, о плюсах и минусах каждой из них и о том, как их определять и когда следует комбинировать.
• Дополнительно:
#Kubernetes
Please open Telegram to view this post
VIEW IN TELEGRAM