По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
На данный момент Kubernetes является одной из самых интересных технологий в мире DevOps. В последнее время вокруг него образовалось очень много хайпа, по одной простой причине, и причина эта – всемогущие контейнеры.
Компания Docker Inc. привлекла народное внимание к контейнерам с помощью маркетинговых компаний о своем прекрасном продукте (у нас есть статья о первоначальной настройке Docker). Но что интересно, Docker – не первопроходец в мире контейнеров, но они положили начало их победоносному походу по миру. Что же было в начале? А в начале были Linux контейнеры, внимание к которым также возросло после такого ажиотажа вокруг Docker контейнеров, при этом и повысив потребность к контейнерным оркестраторам.
Давайте поближе познакомимся с Кормчим – он же Kubernetes. Первоначально это являлось разработкой Google, для управления их гигантской инфраструктурой, состоящей из миллионов контейнеров. В какой-то момент Google отдал Кормчего в люди, а именно - Cloud Native Computing Foundation. На данный момент, Docker добавил Kubernetes в свои сборки как один из вариантов оркестраторов наравне с Docker Swarm.
Теперь Kubernetes также будет частью сборок Docker Community и Docker Enterprise Edition.
Общий обзор Кормчего
Пожалуй, тут нужно разъяснить: Kubernetes является греческим именем кормчего или управляющего кораблём
В зарубежных коммьюнити Кормчий носит несколько названий – Kubernetes, k8s или kube и является платформой с открытым кодом. Данная платформа позволяет автоматизировать операции с контейнерами – запуск, масштабирование, управление контейнизированными приложениями и так далее. Kubernetes может помочь вам сохранить десятки часов жизни и бесценного времени.
Kubernetes позволяет вам помещать в кластер группы хостов с контейнерами и управлять этими кластерами. Эти кластеры могут работать в публичных, частных и гибридных облаках – может, однажды, даже в Хогвартсе откажутся от сложных заклинаний в пользу Kubernetesа.
Как я уже упомянул, Kubernetes изначально является разработкой Google, но будет также нелишним знать, что Kubernetes включен во многие облачные коммерческие предложения Корпорации Добра.
Сам Google запускает более чем 2 миллиарда контейнеров в неделю. Это почти 300 миллионов контейнеров в день с помощью своей внутренней платформы Borg. Эта платформа – предшественник Kubernetes. Все ошибки Borg были учтены и исправлены в Кормчем./
Использование Kubernetes позволяет получать радость от управления и запуска контейнизированных приложений – он автоматизирует запуск и откаты сборок, мониторит запущенные сервисы – т.е вы можете узнать о том, что что-то пойдет не так еще до непосредственной инициации процесса.
Кроме того, Kubernetes управляет ресурсами и может масштабировать необходимые ресурсы для приложений в зависимости от того, сколько им требуется, для того, чтобы избежать лишней траты ресурсов.
Как работает Kubernetes?
Посмотрите на схему с официального сайта (ссылка ниже):
Как вы видите, Kubernetes это очень сложная система (особенно если сравнивать с нативным оркестратором Docker Swarm). Чтобы понять, как он работает, необходимо сначала понять его базовые принципы.
Желаемое состояние
Желаемое состоятие (Desired state) – это один из базовых концептов Kubernetes. Вы можете указать необходимое состояние для запуска контейнеров в т.н Подах. То есть, к примеру, если контейнер почему-то перестал работать, Kubernetes заново создаст Под основываясь на указанном желаемом состоянии.
Kubernetes всегда проверяет состояние контейнеров в кластере, и этим занимается т.н Kubernetes Мастер, который является частью плоскости управления. Можно использовать объект kubectl – он напрямую взаимодействует с кластером для установки или изменения Desired State через Kubernetes API.
Объекты Kubernetes
Обратимся к официальной документации Kubernetes: объект в Kubernetes это «запись о намерениях» (record of intent) – после создания объекта, Kubernetes будет постоянно проверять наличие этого объекта. При создании объекта, вы сообщаете Кормчему как должна выглядеть загрузка вашего кластера, иначе говоря – каково его желаемое состояние.
Состояние сущностей в системе в любой взятый момент времени представлено Kubernetes объектами. Кроме того, объекты также служат как дополнительный уровень абстракции над интерфейсом контейнеров. Вы можете напрямую взаимодействовать с сущностями объектов вместо взаимодействия с контейнерами. Ниже приведем список базовых объектов в Kubernetes.
Под (Pod) – наименьшая запускаемая единица в ноде. Это группа контейнеров, которые должны работать вместе. Довольно часто (но не всегда) в поде находится только один контейнер;
Сервис(Service) – данный объект используется для обозначения логической суммы подов и политик, используемых для доступа к подам;
Раздел (Volume) – директория, которая доступна всем контейнерам внутри пода;
Именные пространства (Namespaces) – виртуальные кластеры, поддерживаемые физическим кластером;
Также в Kubernetes есть несколько контроллеров, которые построены на базовых объектах и они предоставляют дополнительные фичи. Ниже список данных контроллеров:
ReplicaSet - проверяет что какое-то количество копий подов также все время запущено;
Deployment - используется для смены текущего состояния на желаемое состояние;
StatefulSet - используется для контроля над развертыванием и доступов к разделам;
DaemonSet - используется для копирования пода на все ноды кластера или только на указанные ноды;
Job - используется для реализации какой-то задачи и прекращения существования после завершения задачи или после указанного времени
Плоскость управления в Kubernetes
Плоскость управления в Kubernetes используется для установки кластера в желаемое состояние, и для этого Kubernetes выполняет множество задач автоматически – старт и перезагрузка контейнеров, изменение количества реплик приложения и так далее.
Различные части плоскости управления, такие как Kubernetes Мастер и процесс kubelet задают тон тому, как Kubernetes взаимодействует с вашим кластером. Плоскость управления содержит записи о всех объектах Kubernetes в системе и запускает бесконечные петли управления для контроля состояния объектов. В каждый момент времени эти петли будут реагировать на изменения в кластере и будет приводить состояние всех объектов в системе из текущего состояния в желаемое. Представьте себе правительство страны, которое проверяет все ли работают и существуют в соответствии с законом.
Kubernetes Мастер являются частью плоскости управления, и выполняет такую же задачу по сохранению желаемого состояния во всем вашем кластере. Команда kubectl является интерфейсом для взаимодействия с мастером в кластере через API.
В документации написано: «мастер» - это группа процессов, управляющих состоянием кластера. Как правило, все эти процессы запущены одной ноде в кластере и эта нода также называется мастер-нодой. Мастер-нода также может быть реплицирована для избыточности и отказоустойчивости.
Каждый мастер в кластере являет собой совокупность следующих процессов:
kube-apiserver - единственная точка управления для целого кластера. Команда cubectl взаимодействует напрямую через API;
kube-controller-manager - управляет состоянием кластера, управляя различными контроллерами;
kube-scheduler - планирует задачи на всех доступных нодах в кластере;
Ноды в Kubernetes
Ноды в Kubernetes – это ваши «сервера» - виртуалки, физические и так далее, которые находятся в кластере и на которых запущены ваши приложения. Ноды также контролируются мастером и постоянно мониторятся для того, чтобы устанавливать желаемое состояние для приложений. Раньше они назывались «миньонами» - но не теми желтыми милахами из мультика. Каждая нода в кластере держит два процесса:
kubelet– интерфейс между нодой и мастером;
kube-proxy – сетевая прокси, через которую проходят сервисы, указанные в API на каждой ноде. Также эта прокси может совершать простой TCP и UDP проброс портов;
Установка Kubernetes
Теперь давайте посмотрим как это работает. Для этого необходимо установить Kubernetes у вас на сервере. Нужно скачать и установить Docker Community Edition версий 17.12.+ и затем для локального запуска нужно установить Minikube.
Ссылка для скачивания Docker Community Edition - здесь;
Ссылка для скачивания Minikube - тут (MiniKube)
При использовании Minikube надо помнить, что создается локальная виртуальная машина и запускает кластер, состоящий из одной ноды. Но ни в коем случае не используйте его для продакшена – Minikube служит исключительно для тестирования и разработки.
Для запуска однонодного кластера достаточно лишь выполнить команду minikube start. Бадумс, вы одновременно запустили виртуальную машину, кластер и сам Kubernetes.
$minikube start
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...
Kubectl is now configured to use the cluster.
Loading cached images from config file.
Для проверки установки надо ввести команду kubectl version
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"3a1c9449a956b6026f075fa3134ff92f7d55f812", GitTreeState:"clean", BuildDate:"2018-01-04T20:00:41Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:44:10Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
В сегодняшней статье поговорим о том, как защитить IP-АТС от несанкционированного доступа и дадим несколько простых советов, следуя которым, можно существенно повысить безопасность вашей телефонной станции. Примеры, которые будут приведены в данной статье, относятся к IP-АТС на базе Asterisk, однако многие из них распространяются на все без исключения VoIP-АТС.
Для начала, давайте разберёмся, чем же грозят “дыры” в безопасности и какие последствия грозят бизнесу, если злоумышленник получит доступ к IP-АТС.
Угроза взлома
В отличие от взлома персонального компьютера или почты, взлом АТС – это бесплатные для взломщика звонки, за которые придется заплатить владельцу АТС. Известно немало случаев, когда хакеры тратили колоссальные суммы, проведя на взломанной АТС всего несколько часов.
Как правило, целями злоумышленников становятся IP-АТС, которые доступны из публичной сети. Используя различные SIP-сканнеры и исследуя системные уязвимости, они выбирают места для атаки. Дефолтные (default) пароли, открытые SIP-порты, неправильно управляемый firewall или его отсутствие - всё это может стать причиной несанкционированного доступа.
К счастью, все эти уязвимости можно устранить и причём совершенно бесплатно.
Простые шаги к повышению безопасности
Первое правило, которое необходимо соблюдать – это не афишировать адрес своей IP-АТС и следить за тем, чтобы доступ к сети имели только авторизованные пользователи. Разумеется, это правило распространяется и на физический доступ к серверу, на котором установлена IP-АТС.
Второе и самое очевидное – не использовать дефолтные (default) пароли, которые будет легко подобрать или угадать – “1234”, “admin”, “password”, название компании и так далее.
Одной из самых распространённых ошибок, является создание внутренних номеров (Extension), у которых и номер и пароль совпадают. В sip.conf это выглядит примерно так:
sip.conf
[101]
username=101
secret=101
host=dynamic
Допускать такого, категорически нельзя. Тем более что при создании внутреннего номера через интерфейс FreePBX 13, автоматически генерируется 32-значный надёжный пароль.
При настройке внутренних номеров также следует ограничивать IP-адреса, которые могут быть на них зарегистрированы вплоть до пула адресов локальной подсети. IP-АТС Asterisk имеет встроенные ACL (Access Control List), в настройке sip.conf. При помощи команд permit/deny можно разрешить лишь опредёленное количество IP-адресов для регистрации.
Другой важной мерой по усилению безопасности, является ограничение удалённого доступа к IP-АТС при помощи firewall. Будьте внимательны, так как в данном случае, главное грамотно настроить правила, по которым будет отрабатывать firewall. Убедитесь, что настройка не блокирует порты, которые использует ваша IP-АТС и не позволяет анонимно посылать ICMP запросы из публичной сети. Если вы планируете предоставлять удалённый доступ для авторизованных сотрудников, лучше всего организовать его при помощи VPN сервера (например, Open VPN).
Если это возможно, то желательно использовать NAT (Network Address Translation). При помощи NAT’а, можно присвоить IP-АТС приватный IP-адрес и существенно усложнить доступ к ней из Интернета.
Ещё одним очень важным фактором, является разделение входящих и исходящих маршрутов (Inbound Routes и Outbound Routes). Необходимо, чтобы каждый маршрут принадлежал собственному контексту обработки вызова.
Отключите каналы и сервисы, которые не используются. Например, если вы не используете протокол MGCP или skinny. Отключить эти модули можно в /etc/modules.conf как показано ниже:
noload => chan_mgcp.so
noload => chan_skinny.so
noload => chan_oss.so
Чтобы усложнить работу всевозможным SIP-сканнерам, необходимо в настройках sip.conf выставить следующее условие - alwaysauthreject=yes. Это будет препятствовать получению информации об использующихся внутренних номерах на вашей IP-АТС.
Рекомендуем создавать отдельные маршруты на звонки за рубеж (по сути, международное направление 810). Ставьте ограничения на звонки в таких маршрутах или закрывайте их PIN – кодом, который могут знать только сотрудники вашей организации.
Как видите, защитить IP-АТС от внешних вторжений не так уж трудно, следуя предложенным советам, можно достаточно серьёзно повысить безопасность и надёжность системы.
Беспроводные точки доступа могут быть настроены для работы в не инфраструктурных режимах, когда обычный BSS не может обеспечить необходимую функциональность. Далее рассмотрим наиболее распространенные топологии.
Кстати, почитайте статью где мы сравниваем проводные и беспроводные сети
Ретранслятор (repeater)
Обычно каждая точка доступа в беспроводной сети имеет проводное соединение с DS (системой распределения) или коммутируемой инфраструктурой. Чтобы расширить зону покрытия беспроводной сети за пределы области действия обычной точки доступа (AP), можно добавить дополнительные точки доступа. Иногда бывают ситуации, когда невозможно выполнить проводное подключение к новой точке доступа, поскольку расстояние слишком велико для поддержки Ethernet-связи.
В этом случае можно добавить дополнительную точку доступа, настроенную в режиме ретранслятора. Беспроводной ретранслятор принимает сигнал, ретранслирует его в новой области ячейки, окружающей ретранслятор. Размещается ретранслятор на таком расстоянии от точки доступа, чтобы он все еще находился в пределах досягаемости как точки доступа, так и удаленного клиента, как показано на рисунке 1.
На рисунке показано увеличение диапазона точки доступа. Точка доступа соединена с коммутатором третьего уровня посредством кабеля. Диапазон точки доступа формирует базовый набор услуг (BSS). Клиент А подключен к точке доступа по беспроводной сети и находится в BSS. Ретранслятор помещается на удалении от точки доступа, но в пределах ее видимости так, чтобы он мог соединиться с удаленным клиентом B. Ретранслятор соединен с точкой доступа и клиентом B по беспроводной сети.
Если ретранслятор имеет один передатчик и приемник, он должен работать на том же канале, что и точка доступа. Это связано с тем, что сигнал точки доступа будет принят и ретранслирован повторителем для того, чтобы быть снова принятым точкой доступа. Ретранслятор в двое уменьшает эффективную пропускную способность, потому что канал будет занят в два раза дольше, чем раньше. В качестве средства защиты некоторые ретрансляторы могут использовать два передатчика и приемника, чтобы изолировать исходные и повторные сигналы на разных каналах. Одна пара передатчика и приемника предназначена для сигналов в ячейке точки доступа, в то время как другая пара предназначена для сигналов в собственной ячейке ретранслятора.
Мост рабочей группы (Workgroup)
Предположим, есть устройство, которое поддерживает проводную связь Ethernet, но не может работать в беспроводной сети. Например, некоторые мобильные медицинские устройства могут быть сконструированы только с проводным подключением. Хоть при наличии проводного подключения устройства к сети Ethernet, беспроводное соединение было бы гораздо более практичным. Для подключения проводного сетевого адаптера устройства к беспроводной сети используется мост рабочей группы (WGB).
Вместо того, чтобы обеспечить BSS для беспроводного обслуживания, WGB становится беспроводным клиентом BSS. Фактически WGB выступает в качестве внешнего адаптера беспроводной сети для устройства, которое не имеет такового. На рисунке 2, точка доступа обеспечивает BSS, где клиент А - это обычный беспроводной клиент, а клиент Б связан с точкой доступа через WGB.
На рисунке показано подключение проводного устройства через мост рабочей группы (WGB). Точка доступа соединена с коммутатором третьего уровня через кабель. Диапазон точки доступа формирует базовый набор услуг (BSS). Клиент А подключен к точке доступа по беспроводной связи. Клиент B в пределах BSS соединен с мостом рабочей группы, через кабель. Мост рабочей группы подключен к точке доступа по "воздуху".
WGB бывают двух типов:
Универсальный мост рабочей группы (uWGB-Universal WORKGROUP BRIDGE): только одно проводное устройство может быть соединено с беспроводной сетью;
Мост рабочей группы (WGB): проприетарный режим Cisco, который позволяет соединять несколько проводных устройств в беспроводную сеть
Открытый мост
Точка доступа может быть настроена в качестве моста для формирования единой беспроводной линии связи от одной локальной сети к другой на большом расстоянии. Данный тип подключения используется для связи между зданиями или между городами.
Если необходимо соединить две локальные сети, то можно использовать мостовую связь "точка-точка". На каждом конце беспроводной линии связи должна одна точка доступа, настроенная в режиме моста. Специальные антенны обычно используются с мостами для фокусировки их сигналов в одном направлении к антенне точки доступа. Это позволяет максимально увеличить расстояние между звеньями, как показано на рисунке 3.
На рисунке показан открытый мост "точка-точка". Два здания расположены на значительном расстоянии друг от друга. Сеть A соединена с мостом, который в свою очередь соединен с антенной на здании, через кабель. Сеть B соединена с другим мостом, который в свою очередь соединен с другой антенной в другом здании, так же через кабель. Между этими двумя зданиями настроена беспроводная связь, и сигналы фокусируются с помощью антенн.
Иногда сети нескольких подразделений компании должны быть объединены. Мостовая связь "точка-множественное подключение" (point-to-multipoint) позволяет соединять головной (центральный) офис с удаленными офисами. Мост головного офиса соединен с всенаправленной антенной, так что его сигнал передается одинаково во всех направлениях. Это позволяет передавать данные в удаленные офисы одновременно. Мосты на каждом из других участков могут быть соединены с направленной антенной, смотрящей на головной офис. На рисунке показано подключение point-to-multipoint.
На рисунке показан открытый мост (outdoor bridge) типа "point-to-multipoint". Показанная сеть состоит из трех зданий, расположенных линейным образом на равном расстоянии. Первый и третий корпуса содержат специальные антенны, которые фокусируют сигнал друг на друга. Второе здание в центре содержит всенаправленную антенну. Сеть А, Сеть B, Головной офис все эти сети соединены через мосты, каждая в своем здании.
Ячеистая сеть
Чтобы обеспечить беспроводное покрытие на очень большой площади, не всегда практично использовать провода Ethernet к каждой точке доступа, которая будет необходима. Вместо этого можно использовать несколько точек доступа, настроенных в режиме ячейки. В ячеистой топологии беспроводной трафик передается от точки доступа к точке доступа с помощью другого беспроводного канала.
Точки доступа ячеистой топологии используют два радиоканала-один канал используется в одном диапазоне частот, а другой -в другом диапазоне. Каждая точка доступа ячеистой топологии обычно поддерживает BSS на одном канале, с которым могут связываться беспроводные клиенты. Затем клиентский трафик обычно соединяется через мост от точки доступа к точке доступа по другим каналам. На границе ячеистой сети обратный трафик соединяется с инфраструктурой проводной локальной сетью. На рисунке 5 показана типичная ячеистая сеть. С Cisco APs можно построить ячеистую сеть в помещении или на улице. Ячеистая сеть использует свой собственный протокол динамической маршрутизации, чтобы определить наилучший путь для обратного трафика, который будет проходить через сеть AP.