По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Много раз в день вы посещаете веб-сайты, на которых вас просят войти под своим именем пользователя, адресом электронной почты и паролем. Банковские сайты, сайты социальных сетей, почтовые службы, сайты электронной коммерции и новостные сайты - это всего лишь несколько типов сайтов, использующих этот механизм.
Каждый раз, когда вы входите на один из этих сайтов, вы, по сути, говорите: «Да, я доверяю этому сайту, поэтому я хочу поделиться с ним своей личной информацией». Эти данные могут включать ваше имя, пол, физический адрес, адрес электронной почты, а иногда даже информацию о кредитной карте.
Но откуда вы знаете, что можете доверять определенному веб-сайту? Иными словами, что делает веб-сайт для защиты вашей транзакции, чтобы вы могли доверять ей?
Эта статья направлена на демистификацию механизмов, которые делают сайт безопасным. Мы начнем с обсуждения веб-протоколов HTTP и HTTPS и концепции безопасности транспортного уровня (TLS - Transport Layer Security), которая является одним из криптографических протоколов. Затем мы объясним центры сертификации (CA - Certificate Authorities) и самозаверяющие сертификаты и как они могут помочь защитить веб-сайт. Наконец, я представлю некоторые инструменты с открытым исходным кодом, которые вы можете использовать для создания и управления сертификатами.
Защита маршрутов через HTTPS
Самый простой способ понять защищенный веб-сайт - это увидеть его в действии. К счастью, сегодня найти защищенный веб-сайт гораздо проще, чем незащищенный веб-сайт в Интернете. Но, поскольку вы уже находитесь на сайте wiki.merionet.ru, будем использовать его в качестве примера. Независимо от того, какой браузер вы используете, вы должны увидеть значок, который выглядит как замок рядом с адресной строкой. Нажмите на значок замка, и вы должны увидеть что-то похожее на это.
По умолчанию веб-сайт не является безопасным, если он использует протокол HTTP. Добавление сертификата, настроенного через хост сайта, может преобразовать сайт из незащищенного сайта HTTP в защищенный сайт HTTPS. Значок замка обычно указывает, что сайт защищен через HTTPS.
Нажмите на сертификат, чтобы увидеть CA сайта. В зависимости от вашего браузера вам может понадобиться скачать сертификат, чтобы увидеть его.
Здесь вы можете узнать кое-что о сертификате, кем, кому и когда был выдан. Эта информация о сертификате позволяет конечному пользователю проверить, что сайт безопасен для посещения.
ВНИМАНИЕ: Если вы не видите знак сертификата на веб-сайте или если вы видите знак, указывающий на то, что веб-сайт не защищен, пожалуйста, не входите в систему и не выполняйте действия, требующие ваших личных данных. Это довольно опасно!
Если вы видите предупреждающий знак, который редко встречается на большинстве общедоступных веб-сайтов, это обычно означает, что срок действия сертификата истек или используется самозаверяющий сертификат вместо сертификата, выпущенного через доверенный CA.
Интернет-протоколы с TLS и SSL
TLS - это текущее поколение старого протокола Secure Socket Layer (SSL). Лучший способ понять его место - посмотреть на модель OSI.
Есть шесть уровней, которые составляют Интернет, каким мы его знаем сегодня: физический, данные, сеть, транспорт, безопасность и приложения. Физический уровень является базовой основой, и он наиболее близок к реальному оборудованию. Прикладной уровень является наиболее абстрактным и ближайшим к конечному пользователю. Уровень безопасности можно рассматривать как часть уровня приложений, а TLS и SSL, которые являются криптографическими протоколами, разработанными для обеспечения безопасности связи по компьютерной сети, находятся на уровне безопасности.
Основным вариантом использования TLS является шифрование связи между веб-приложениями и серверами, такими как веб-браузеры, загружающие веб-сайт. Протокол TLS также можно использовать для шифрования других сообщений, таких как электронная почта, обмен сообщениями и передача голоса по IP (VOIP).
Центры сертификации и самозаверяющие сертификаты
Центр Сертификации (CA) - это доверенная организация, которая может выдавать цифровой сертификат.
TLS и SSL могут сделать соединение безопасным, но для механизма шифрования необходим способ его проверки - это сертификат SSL/TLS. TLS использует механизм, называемый асимметричным шифрованием, который представляет собой пару ключей безопасности, называемых закрытым ключом (private key) и открытым ключом (public key). Важно знать, что центры сертификации, такие как GlobalSign, DigiCert и GoDaddy являются внешними доверенными поставщиками, которые выпускают сертификаты, которые используются для проверки сертификата TLS/SSL, используемого веб-сайтом. Этот сертификат импортируется на хост-сервер для защиты сайта.
Прежде чем какой-либо крупный веб-браузер, такой как Chrome, Firefox, Safari или Internet Explorer, подключится к вашему серверу по протоколу HTTPS, он уже имеет в своем распоряжении набор сертификатов, которые можно использовать для проверки цифровой подписи, найденной в сертификате вашего сервера. Эти цифровые сертификаты веб-браузера называются сертификатами CA. Если с сертификатом на сервере все ок, то мы попадаем на сайт, а если нет, то браузер покажет нам предупреждение. Закрытые ключи, используемые для подписи сертификатов сервера, уже имеют соответствующие пары открытых ключей в веб-браузерах пользователей.
Однако CA может быть слишком дорогим или сложным, когда вы просто пытаетесь протестировать веб-сайт или услугу в разработке. У вас должен быть доверенный ЦС для производственных целей, но разработчикам и администраторам веб-сайтов необходим более простой способ тестирования веб-сайтов, прежде чем они будут развернуты в рабочей среде - именно здесь приходят самозаверяющие сертификаты.
Самозаверяющий сертификат - это сертификат TLS/SSL, подписанный лицом, которое его создает, а не доверенным центром сертификации. Создать самозаверяющий сертификат на компьютере очень просто, и он может позволить вам протестировать защищенный веб-сайт, не покупая дорогой сертификат, подписанный СА, сразу. Хотя самозаверяющий сертификат определенно рискованно использовать в производственной среде, он является простым и гибким вариантом для разработки и тестирования на подготовительных этапах.
Инструменты с открытым исходным кодом для генерации сертификатов
Для управления сертификатами TLS/SSL доступно несколько инструментов с открытым исходным кодом. Наиболее известным из них является OpenSSL, который включен во многие дистрибутивы Linux и в macOS. Тем не менее, другие инструменты с открытым исходным кодом также доступны.
OpenSSL - Самый известный инструмент с открытым исходным кодом для реализации библиотек TLS и шифрования Apache
EasyRSA - Утилита командной строки для создания и управления PKI CA
CFSSL - PKI/TLS "Швейцарский нож" от Cloudflare
Lemur - Инструмент создания TLS от Netflix
Подаренный компанией Google сообществу Opensource, Kubernetes теперь стал инструментом контейнерного хранения по выбору. Он может управлять и координировать не только среду выполнения докеров, но и среду контейнерного хранения объектов и Rkt.
Типичный кластер Kubernetes обычно имеет главный узел и несколько рабочих узлов или Minions. Управление рабочими узлами осуществляется из главного узла, что обеспечивает управление кластером из центральной точки.
Важно также отметить, что можно развернуть кластер с одним узлом Kubernetes, который обычно рекомендуется использовать для легких непроизводственных рабочих нагрузок. Для этого можно взять Minikube - инструмент, который управляет кластером K ubernetes с одним узлом в виртуальной машине.
В этом руководстве мы рассмотрим многоузловую установку кластера Kubernetes в системе Linux CentOS 7. Это учебное пособие основано на командной строке и требует доступа к окну терминала.
Требования
Иметь несколько серверов под управлением Centos 7 (1 главный узел, 2 рабочих узла). Рекомендуется, чтобы главный узел содержал по крайней мере 2 ЦП, хотя это не является строгим требованием.
Подключение к Интернету на всех узлах. Мы будем извлекать пакеты Kubernetes и докеров из хранилища. Кроме того, необходимо убедиться, что диспетчер пакетов yum установлен по умолчанию и может получать пакеты удаленно.
Вам также потребуется доступ к учетной записи с правами sudo или root. В этом учебном пособии я буду использовать свою учетную запись root.
Наш 3-узловой кластер будет выглядеть примерно так:
Установка кластера Kubernetes на главном узле
Для работы Kubernetes потребуется механизм контейнеризации. Для этой установки мы будем использовать docker, так как он самый популярный.
На главном узле выполняются следующие шаги.
Шаг 1: Подготовить имя узла, брандмауэр и SELinux
На главном узле задайте имя хоста и, если у вас нет DNS-сервера, обновите файл /etc/hosts.
# hostnamectl set-hostname master-node
# cat <<EOF>> /etc/hosts
10.128.0.27 master-node
10.128.0.29 node-1 worker-node-1
10.128.0.30 node-2 worker-node-2
EOF
Можно выполнить проверку связи с рабочим узлом 1 и рабочим узлом 2, чтобы убедиться в правильности работы обновленного файла хоста с помощью команды ping.
# ping 10.128.0.29
# ping 10.128.0.30
Затем отключите SElinux и обновите правила брандмауэра.
# setenforce 0
# sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux
# reboot
Установите следующие правила брандмауэра для портов. Убедитесь, что каждая команда firewall-cmd возвращает результат.
# firewall-cmd --permanent --add-port=6443/tcp
# firewall-cmd --permanent --add-port=2379-2380/tcp
# firewall-cmd --permanent --add-port=10250/tcp
# firewall-cmd --permanent --add-port=10251/tcp
# firewall-cmd --permanent --add-port=10252/tcp
# firewall-cmd --permanent --add-port=10255/tcp
# firewall-cmd –reload
# modprobe br_netfilter
# echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables
Шаг 2: Настройка Kubernetes Repo
Нужно будет вручную добавить хранилище Kubernetes, так как оно не установлено по умолчанию в CentOS 7.
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
Шаг 3: Установить Kubeadm и Docker
После того, как пакет repo уже готов, вы можете продолжить и установить kubeadm и docker пакеты.
# yum install kubeadm docker -y
После успешного завершения установки включите и запустите обе службы.
# systemctl enable kubelet
# systemctl start kubelet
# systemctl enable docker
# systemctl start docker
Шаг 4: Установка Kubernetes Master и настройка пользователя по умолчанию
Теперь мы готовы инициализировать Kubernetes Master, но до этого нужно отключить swap, чтобы запустить команду kubeadm init.
# swapoff –a
Инициализация Kubernetes master - это полностью автоматизированный процесс, управляемый командой kubeadm init, которую необходимо выполнить.
# kubeadm init
Инициализация Kubernetes master
Возможно, потребуется скопировать последнюю строку и сохранить ее в другом месте, поскольку нужно будет запустить ее на рабочих узлах.
kubeadm join 10.128.0.27:6443 --token nu06lu.xrsux0ss0ixtnms5 --discovery-token-ca-cert-hash sha256:f996ea3564e6a07fdea2997a1cf8caeddafd6d4360d606dbc82314688425cd41
Совет: Иногда эта команда может жаловаться на переданные аргументы (args), поэтому отредактируйте ее, чтобы избежать ошибок. Таким образом, вы удалите символ , сопровождающий --token, и ваша последняя команда будет выглядеть следующим образом.
kubeadm join 10.128.0.27:6443 --token nu06lu.xrsux0ss0ixtnms5 --discovery-token-ca-cert-hash sha256:f996ea3564e6a07fdea2997a1cf8caeddafd6d4360d606dbc82314688425cd41
После успешной инициализации Kubernetes необходимо разрешить пользователю начать использование кластера. В нашем случае мы хотим запустить эту установку от имени пользователя root, поэтому мы продолжим выполнение этих команд с этого же имени. Вы можете перейти на пользователя с поддержкой sudo, который вы предпочитаете, и запустить ниже с помощью sudo.
Чтобы использовать root, выполните следующие действия:
# mkdir -p $HOME/.kube
# cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# chown $(id -u):$(id -g) $HOME/.kube/config
Чтобы быть пользователем с поддержкой sudo, выполните следующие действия:
$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
Теперь проверьте, активирована ли команда kubectl.
# kubectl get nodes
На этом этапе также можно заметить, что главный узел имеет статус NotReady. Это связано с тем, что сеть модулей еще не развернута в кластере.
Pod Network - это сеть наложения для кластера, которая развернута поверх текущей сети узла. Она предназначена для обеспечения возможности подключения через модуль.
Шаг 5: Настройка сети модуля
Применение сетевого кластера является очень гибким процессом в зависимости от потребностей пользователя и наличия множества доступных вариантов. Так как мы хотим сохранить нашу установку как можно проще, мы будем использовать плагин Weavenet, который не требует никакой конфигурации или дополнительного кода, и он предоставляет один IP-адрес на модуль, что отлично для нас. Для просмотра дополнительных параметров проверьте здесь.
Эти команды будут важны для настройки сети модуля.
# export kubever=$(kubectl version | base64 | tr -d '
')
# kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever"
Теперь, если вы проверите статус главного узла, он должен показать "Ready"
# kubectl get nodes
Далее мы добавим рабочие узлы в кластер.
Настройка рабочих узлов для присоединения к кластеру Kubernetes
Следующие шаги будут выполнены на рабочих узлах. Эти шаги должны выполняться на каждом рабочем узле при присоединении к кластеру Kubernetes.
Шаг 1: Подготовить имя узла, брандмауэр и SELinux
На рабочем узле-1 и рабочем узле-2 задайте имя, а если у вас нет DNS-сервера, то обновите основные и рабочие узлы в файле /etc/hosts.
# hostnamectl set-hostname 'node-1'
# cat <<EOF>> /etc/hosts
10.128.0.27 master-node
10.128.0.29 node-1 worker-node-1
10.128.0.30 node-2 worker-node-2
EOF
Можно выполнить ping master-node для проверки правильности обновленного файла хоста.
Затем отключите SElinux и обновите правила брандмауэра.
# setenforce 0
# sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux
Установите следующие правила брандмауэра для портов. Убедитесь, что все команды firewall-cmd возвращаются успешно.
# firewall-cmd --permanent --add-port=6783/tcp
# firewall-cmd --permanent --add-port=10250/tcp
# firewall-cmd --permanent --add-port=10255/tcp
# firewall-cmd --permanent --add-port=30000-32767/tcp
# firewall-cmd --reload
# echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables
Шаг 2: Настройка Kubernetes Repo
Вам потребуется добавить хранилище Kubernetes вручную, так как оно не будет предварительно установлено на CentOS 7.
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
Шаг 3: Установить Kubeadm и Docker
После того, как пакет repo уже готов, вы можете продолжить и установить kubeadm и docker пакеты.
# yum install kubeadm docker -y
Запустите и включите обе службы.
# systemctl enable docker
# systemctl start docker
# systemctl enable kubelet
# systemctl start kubelet
Шаг 4: Присоединение рабочего узла к кластеру Кубернетов
Теперь для присоединения к кластеру требуется маркер, созданный kubeadm init. Его можно скопировать и вставить в узлы 1 и 2, если он был скопирован в другом месте.
# kubeadm join 10.128.0.27:6443 --token nu06lu.xrsux0ss0ixtnms5 --discovery-token-ca-cert-hash sha256:f996ea3564e6a07fdea2997a1cf8caeddafd6d4360d606dbc82314688425cd41
Как показано в последней строке, вернитесь к главному узлу и проверьте, присоединились ли рабочие узлы 1 и 2 к кластеру с помощью следующей команды.
# kubectl get nodes
Если все шаги выполнены успешно, на главном узле должны быть показаны узлы 1 и 2 в состоянии готовности.
На этом этапе мы успешно завершили установку кластера Kubernetes на Centos 7 и успешно взяли два рабочих узла. Теперь можно начинать создавать модули и разворачивать службы.
Привет, бро! В статье расскажем в чем разница между RIPv1 (Routing Information Protocol Version 1) и его продолжение RIPv2. Погнали?
Про Routing Information Protocol Version 1 (RIPv1)
Прямо и по пунктам:
RIPv1 это Distance-Vector протокол. Если переводить на русский - дистанционно-векторный. ;
Distance vector routing - так называемая дистанционно-векторная маршрутизация, главный принцип которой основан на вычислении специальных метрик, которые определяют расстояние (количество узлов) до сети назначения
RIPv1 это classfull протокол. Это означает, что он не отправляет маску подсети в апдейтах маршрутизации;
RIPv1 не поддерживает VLSM (Variable Length Subnet Masking);
VLSM (Variable Length Subnet Masking) - метод эффективного использования IP – адресации, который избавляет от привязки к классу сети (класс A, класс B, класс C). VLSM позволяет дробить подсеть на подсеть и так далее. Тем самым, мы можем эффективно использовать адресное пространство согласно реальных потребностей, а не класса сети;
RIPv1 поддерживает максимум 15 хопов! Это означает, что любой маршрутизатор, который расположен от вас в больше, чем 15 узлов (маршрутизаторов) будет отмечен как недоступный;
Раз в 30 секунд RIPv1 отправляет широковещательные апдейты маршрутизации – каждый узел должен принять и обработать этот апдейт;
Первая версия RIP не поддерживает авторизация апдейтов маршрутизации – это означает, что потенциально, роутер может обновить таблицу маршрутизации от любого источника;
Вот такой он, RIP первой версии. Двигаем дальше и посмотрим, а на что способен его брат – RIP второй версии?
Про Routing Information Protocol Version 2 (RIPv2)
RIPv2 это гибридный протокол. Он реализован на базе Distance-Vector, но так же поддерживает часть алгоритмов Link State маршрутизации, то есть, может отслеживать состояние каналов;
Link State routing - отслеживает состояние каналов и отправляет LSA (Link-state advertisement) пакеты, в которых рассказывает о состоянии своих каналов. Примером link state протокола маршрутизации является OSPF
RIPv2 - classless протокол. В отличие от своего старшего брата первой версии, второая версия умеет отправлять маску подсети в апдейтах маршрутизации;
RIPv2 поддерживает VLSM!;
RIPv2, как и RIPv1 поддерживает максимум 15 хопов;
RIPv2 отправляет мультикаст сообщения об апдейтах на адрес 224.0.0.9. Это уменьшает нагрузку на сеть и в первую очередь на узлы, на которых не запущен RIP;
Вторая версия RIP поддерживает аутентификацию апдейтов маршрутизации. Это значит, что теперь нельзя будет подсунуть ложный апдейт роутеру (в целом, этим могли пользоваться злоумышленники) – только авторизированные источники;