Материал подготовлен командой Simple-Server для администраторов VPS и выделенных серверов. Команды и пути проверяйте на тестовой машине перед production.
Преимущества использования сетевых политик
В данном разделе мы расскажем об основных преимуществах использования сетевых политик в Kubernetes:
Сетевые политики позволяют пользователями определить строгие правила доступа к сетевому трафику между подами. Это позволит предотвратить попытки несанкционированного доступа и минимизирует поверхность атак.
- Изоляция и мультитенантность
Сетевые политики используются при создании изолированных сетевых зон внутри кластера. Пользователь может определить различные правила доступа для разных неймспейсов, подавляя возможность пересечения сетевого трафика между приложениями разных групп. Это будет особенно полезно в мультитенантных средах, где несколько клиентов или команд могут использовать один кластер Kubernetes.
Сетевые политики также упрощают процесс управления сетевыми соединениями в кластере. Пользователи могут выполнить настройку как общих правил, так и индивидуальных для конкретных компонентов.
- Повышенная отказоустойчивость
Правила самоисключения или self-healing повышают отказоустойчивость приложений. Например, если один из подов выйдет из строя, весь трафик будет автоматически перенаправлен на работающие экземпляры, обеспечивая тем самым непрерывность работы.
NetworkPolicy в Kubernetes — это механизм управления сетевыми политиками. Он предназначен для определения правил доступа для сетевого трафика между подами в кластере. С помощью NetworkPolicy пользовать может ограничить входящий и исходящий сетевой трафик на основе различных атрибутов: IP-адресов, портов и меток.
Чтобы реализовать сетевые политики, понадобится сетевой плагин, поддерживающий NetworkPolicy.
Ниже перечислим основные поля, которые включает в себя NetworkPolicy:
apiVersion— данное поле отвечает за версию API, которая используется для определения NetworkPolicy. Например, для Kubernetes версии 1.22 значение рассматриваемого поля может бытьnetworking.k8s.io/v1.kind— указывает на тип объекта NetworkPolicy. В случае с сетевыми политиками, значениеkindбудетNetworkPolicy.metadata— поле, содержащее метаданные объекта NetworkPolicy (имя, неймспейс, аннотации и метки).spec— данное поле определяет основные параметры и правила сетевой политики. Внутри поля могут быть расположены следующие подполя:
* `podSelector` — указывает на поды, к которым будет применяться сетевая политика.
* `policyTypes` — определяет типы политик, применяемых к выбранным подам. Существует два типа политик для подов — это `ingress` и `egress`. Пользователь может указать либо один из типов, либо сразу оба.
* `ingress` — содержит список правил доступа для входящего сетевого трафика.
* `egress` — содержит список правил доступа для исходящего сетевого трафика.-
status— содержит информацию о состоянии сетевой политики. В нем могут содержаться условия (conditions), которые отражают текущее состояние политики. -
podSelector— указывает на поды, к которым будет применяться сетевая политика. -
policyTypes— определяет типы политик, применяемых к выбранным подам. Существует два типа политик для подов — этоingressиegress. Пользователь может указать либо один из типов, либо сразу оба. -
ingress— содержит список правил доступа для входящего сетевого трафика. -
egress— содержит список правил доступа для исходящего сетевого трафика.
Ниже приведем простой пример сетевой политики, содержащей все вышеописанные поля:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: example-network-policy
namespace: example-namespace
labels:
app: example-app
spec:
podSelector:
matchLabels:
app: example-app
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
app: allowed-app
ports:
- protocol: TCP
port: 80
egress:
- to:
- podSelector:
matchLabels:
app: allowed-app
ports:
- protocol: TCP
port: 443
status:
conditions:
- type: NetworkPolicyReady
status: "True"
lastTransitionTime: "2023-06-27T12:00:00Z"Здесь создается сетевая политика с именем example-network-policy в неймспейсе example-namespace. Политика применяется к подам с меткой app: example-app и содержит оба типа политик. Правило ingress разрешает входящий TCP-трафик на порту 80 из подов с меткой app: allowed-app. Правило egress разрешает исходящий TCP-трафик на порту 443 к подам с меткой app: allowed-app. Поле status указывает на то, что политика готова к использованию.
Примеры использования сетевых политик
В данной главе мы приведем некоторые распространенные среди пользователей сетевые политики. Другие примеры вы можете изучить в специальном репозитории GitHub.
Запрет всего трафика для приложений
Рассматриваемая в данной подглаве политика подразумевает блокировку всего трафика для подов приложения. Подобная политика может пригодиться пользователю в следующих случаях:
- Блокировка всего трафика перед созданием белого списка с разрешенными ресурсами;
- Запрет взаимодействия других подов с указанным;
- Временная изоляция сервиса от других подов.
В первую очередь, необходимо запустить под nginx с специальными метками, также указав порт:
kubectl run web --image=nginx --labels app=web,env=prod --expose --port 80Теперь включим временный под и отправим запрос к службе:
$ kubectl run --rm -i -t --image=alpine test-$RANDOM -- sh
/ # wget -qO- http://webПосле успешного запуска и отправки запроса, составим NetworkPolicy и сохраним ее в файл banning-all-traffic.yaml:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: banning-all-traffic
spec:
podSelector:
matchLabels:
app: web
ingress: []Осталось применить ее к кластеру:
$ kubectl apply -f banning-all-traffic.yamlТеперь протестируем работу сетевой политики и повторим запуск пода и отправку запроса:
$ kubectl run --rm -i -t --image=alpine test-$RANDOM -- sh
/ # wget -qO- --timeout=2 http://webЕсли вы получили сообщение о том, что время загрузки истекло — значит, все выполнено успешно!
Ограничение трафика для приложений
Пользователь может ограничить трафик для приложения, разрешив его от определенных подов и запретив от других. Подобная политика может пригодиться пользователю в следующих случаях:
- Разрешение трафика для тех приложений, которым это нужно.
- Разрешение трафика к БД требуемым приложениям.
Допустим, приложение представляет собой сервер REST API, помеченный метками app=example2 и role=api:
kubectl run apiserver --image=nginx --labels="app=example2,role=api" --expose --port=80Тогда сетевая политика для ограничения трафика будет выглядеть следующим образом:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: traffic-restriction
spec:
podSelector:
matchLabels:
app: example2
role: api
ingress:
- from:
- podSelector:
matchLabels:
app: example2Сохраним ее в файл traffic-restriction.yaml и применим к кластеру:
kubectl apply -f traffic-restriction.yamlЧтобы проверить работу сетевой политики, запустим под с меткой app=example2 и без нее.
Под с меткой app=example2:
$ kubectl run test-$RANDOM --rm -i -t --image=alpine --labels="app=example2,role=frontend" -- sh
/ # wget -qO- --timeout=2 http://apiserver
$ kubectl run test-$RANDOM --rm -i -t --image=alpine -- sh
/ # wget -qO- --timeout=2 http://apiserverВ первом случае трафик должен быть разрешен, а во втором ограничен.
Разрешение всего трафика для приложений
Разрешение всего трафика для приложений может понадобиться после применения политики запрета всего трафика, чтобы разрешить доступ к приложению из всех подов в указанном пространстве имен.
kubectl run web --image=nginx --labels="app=web" --expose --port=80Напишем соответствующую сетевую политику:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: resolution-all-traffic
namespace: default
spec:
podSelector:
matchLabels:
app: web
ingress:
- {}Здесь используется правило пустого входа — {}. Оно разрешает входящий трафик как в текущем пространстве имен, так и в любых иных. Правило пустого входа равносильно следующему фрагменту:
- from:
- podSelector: {}
namespaceSelector: {}Сохраним политику в файле resolution-all-traffic.yaml и применим ее к кластеру:
$ kubectl apply -f resolution-all-traffic.yamlВы также можете применить политику запрета трафика, чтобы проверить, что применение resolution-all-traffic.yaml приведет к ее аннулированию.
Наконец, проверим работу написанной политики:
$ kubectl run test-$RANDOM --rm -i -t --image=alpine -- sh
/ # wget -qO- --timeout=2 http://webВ результате вы должны увидеть, что трафик успешно разрешен.
Нужен сервер для практики? Арендуйте VPS/VDS в России — root-доступ, NVMe, DDoS-защита и поддержка 24/7.