Сетевые политики на защите рабочих нагрузок в кластере Kubernetes

В кластере Kubernetes нам доступен любой сервис в любом пространстве имён, то есть по умолчанию pod открыт для любого трафика.

Мы можем определить сетевую политику для пространства имён или pod’а, чтобы защитить рабочие нагрузки в кластере. Например, разделить рабочие нагрузки в мультитенантном кластере по проектам, командам или организациям.

Сценарий

Представьте, что в пространствах имён Kubernetes мы развёртываем приложение на трёх уровнях: фронтенд, бэкенд и база данных.

Фронтенд будет общедоступным. Приложения будут предоставляться через балансировщик нагрузки, поэтому обращаться к фронтенду мы будем по DNS-имени или IP-адресу этого балансировщика.

Бэкенд будет содержать всю логику приложения.

База данных будет базой данных.

Мы знаем, что по умолчанию любое пространство имён может отправлять трафик любому пространству имён и принимать любой трафик. Без сетевых политик наша трёхуровневая архитектура будет выглядеть так:

Давайте настроим архитектуру, создав три новых пространства имён, в которых мы будем развёртывать сервисы и развёртывания.

Для простоты мы будем использовать образ nginx для развёртывания pod’ов в развёртываниях.

1. Настраиваем новые пространства имён

Создаём пространства имён и добавляем метки к каждому, чтобы потом можно было применять сетевые политики по этим меткам.

# Create "frontend" namespace and add a label 
> kubectl create ns frontend 
> kubectl label ns frontend tier=frontend

# Create "backend" namespace and add a label 
> kubectl create ns backend 
> kubectl label ns backend tier=backend
 
# Create "database" namespace and add a label 
> kubectl create ns database 
> kubectl label ns database tier=database

2. Развёртываем сервисы и развёртывания

2.1 Уровень базы данных

# Deploy a deployment named "database" with 2 replicas
> kubectl create deploy database -n database  --image=nginx --replicas=2
# List the pods of "database" deployments
> kubectl get pods -n database
----------------------------------------------------------------------------------------------------
NAME                        READY   STATUS    RESTARTS   AGE
database-7d94797799-b9sdw   1/1     Running   0          23h
database-7d94797799-jc4xt   1/1     Running   0          23h
----------------------------------------------------------------------------------------------------

# Create a service (cluster ip) named "database" for accessing the pods of the "database" deployment
> kubectl create service clusterip database --tcp=80 -n database
# List the service  
> kubectl get svc -n database
----------------------------------------------------------------------------------------------------
NAME       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
database   ClusterIP   10.106.137.165   <none>        80/TCP    23h
----------------------------------------------------------------------------------------------------

2.2 Уровень бэкенда

# Deploy a deployment named "backend" with 2 replicas
> kubectl create deploy backend -n backend  --image=nginx --replicas=2
# List the pods of "backend" deployments
> kubectl get pods -n backend
----------------------------------------------------------------------------------------------------
NAME                       READY   STATUS    RESTARTS   AGE
backend-5c5c74cbf6-h4d9p   1/1     Running   0          23h
backend-5c5c74cbf6-jf6fj   1/1     Running   0          23h
----------------------------------------------------------------------------------------------------

# Create a service (cluster ip) named "backend" for accessing the pods of the "backend" deployment
> kubectl create service clusterip backend --tcp=80 -n backend
# List the service  
> kubectl get svc -n backend
----------------------------------------------------------------------------------------------------
NAME      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
backend   ClusterIP   10.101.154.161   <none>        80/TCP    23h
----------------------------------------------------------------------------------------------------

2.3 Уровень фронтенда

# Deploy a deployment named "frontend" with 2 replicas
> kubectl create deploy frontend -n frontend  --image=nginx --replicas=2
# List the pods of "frontend" deployments
> kubectl get pods -n frontend
----------------------------------------------------------------------------------------------------
NAME                        READY   STATUS    RESTARTS   AGE
frontend-5d7445bdb8-g8rpb   1/1     Running   0          24h
frontend-5d7445bdb8-kqtnc   1/1     Running   0          24h
----------------------------------------------------------------------------------------------------

# Create a service (load balancer) named "frontend" for accessing the pods of the "frontend" deployment, 
# From internet through the load balancer IP or DNS
> kubectl create service loadbalancer frontend --tcp=80:80 -n frontend
# List the service, and note down the external IP  
> kubectl get svc -n frontend 
----------------------------------------------------------------------------------------------------
NAME       TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)        AGE
frontend   LoadBalancer   10.102.187.203   45.76.197.98   80:30008/TCP   30m
----------------------------------------------------------------------------------------------------

Фронтенд мы предоставляем через балансировщик нагрузки. Мы указываем EXTERNAL-IP сервиса балансировки нагрузки, чтобы пользователи могли обращаться к приложению на фронтенде.

3. Риски для безопасности

3.1 Проблема

Сейчас к pod’ам и пространствам имён не применяются никакие политики. Все pod’ы в кластере могут общаться друг с другом. А что если это мультитенантный кластер или там хранятся конфиденциальные данные? Любой злоумышленник с уровня фронтенда получит прямой доступ к базе данных и всем пространствам имён в кластере. Это серьёзный риск для безопасности.

3.2 Решение

Чтобы защититься от этих рисков, можно использовать сетевые политики. С их помощью мы можем изолировать все три уровня друг от друга, ограничить входящий трафик для базы данных и бэкенда, а также разрешить трафик с фронтенда только на бэкенд, чтобы злоумышленник не мог с фронтенда получить прямой доступ к базе данных и другим пространствам имён. Вот как это будет выглядеть на схеме:

4. Применяем сетевые политики

4.1 Уровень базы данных

• По умолчанию запрещаем весь входящий и исходящий трафик
  Мы может создать политику по умолчанию, которая будет запрещать весь входящий и исходящий трафик в этом пространстве имён.

# Deny all ingress and egress traffic
> kubectl create -f \
 https://raw.githubusercontent.com/shamimice03/Network_Policies_Kubernetes/main/netpol-deny-all-database.yaml
 
---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny-all-database
  namespace: database
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Ingress
  - Egress
---

Уровень базы данных теперь будет изолирован от остальных пространств имён в кластере.

• Разрешаем входящий трафик из бэкенда
  Применим к уровню базы данных ещё одну политику, чтобы разрешить входящий трафик только с бэкенда.

# Allow ingress traffic from "backend-tier" using the following manifest file:
> kubectl create -f  \
https://raw.githubusercontent.com/shamimice03/Network_Policies_Kubernetes/main/netpol-allow-ingress-from-backend.yaml

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-from-backend
  namespace: database
spec:
  podSelector:
    matchLabels: {}
  ingress:
    - from:
      - podSelector:
          matchLabels: {}
        namespaceSelector:
           matchLabels:
              tier: backend
---

4.2 Уровень бэкенда

● По умолчанию запретим весь входящий и исходящий трафик
Применим такую же политику, как для базы данных, чтобы изолировать бэкенд от других пространств имён.

# Deny all ingress and egress traffic
> kubectl create -f \
https://raw.githubusercontent.com/shamimice03/Network_Policies_Kubernetes/main/netpol-deny-all-backend.yaml

---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny-all-backend
  namespace: backend
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Ingress
  - Egress
---

● Разрешим исходящий трафик к базе данных
На уровне базы данных мы разрешили входящий трафик только с бэкенда, а на предыдущем шаге запретили весь трафик в обе стороны для бэкенда. Поэтому уровень базы данных готов принимать входящий трафик от бэкенда, а самому бэкенду запрещено отправлять исходящий трафик. Чтобы наладить взаимодействие между бэкендом и базой данных, нужно разрешить трафик в этом направлении.

Плюс мы используем сервисы для доступа к pod’ам, а значит нужно создать для исходящего трафика ещё одно правило, чтобы разрешать DNS-имена сервисов. В кластере Kubernetes сервер DNS представляет собой набор pod’ов в пространстве имён kube-system. Получается, нужно разрешить исходящий трафик к пространству kube-system, но не ко всему, а только к уровню kube-dns. Теперь pod’ы на бэкенде смогут разрешать DNS-имена сервисов.

Пишем политику, чтобы разрешить исходящий трафик с бэкенда в базу данных, а также на порт 53 пространства имён kube-system:

# allow egress from backend-tier to database-tier and allow dns resolving of services
> kubectl create -f \
  https://raw.githubusercontent.com/shamimice03/Network_Policies_Kubernetes/main/netpol-allow-egress-to-database.yaml

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-database
  namespace: backend
spec:
  podSelector:
    matchLabels: {}
  egress:
    - to:
      - podSelector:
          matchLabels: {}
        namespaceSelector:
           matchLabels:
              tier: database
    - to:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: kube-system
        podSelector:
          matchLabels:
            k8s-app: kube-dns
      ports:
      - protocol: UDP
        port: 53
---

Вот что мы в итоге получаем:

Как видите, бэкенд может отправлять исходящий трафик к базе данных, но пока не принимает никакой входящий трафик.

● Разрешаем входящий трафик из фронтенда
Применим к уровню бэкенда ещё одну политику, чтобы разрешить входящий трафик только с фронтенда.

# Allow ingress from frontend-tier
> kubectl create -f \
https://raw.githubusercontent.com/shamimice03/Network_Policies_Kubernetes/main/netpol-allow-ingress-from-frontend.yaml

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-from-frontend
  namespace: backend
spec:
  podSelector:
    matchLabels: {}
  ingress:
    - from:
      - podSelector:
          matchLabels: {}
        namespaceSelector:
           matchLabels:
              tier: frontend
---

Таким образом бэкенд будет принимать входящий трафик с фронтенда и отправлять исходящий трафик в базу данных.

4.3 Уровень фронтенда

● По умолчанию запрещаем весь трафик
Как и для предыдущих уровней, применим сетевую политику, которая полностью запретит весь входящий и исходящий трафик.

# Deny all ingress and egress traffic
> kubectl create -f \
https://raw.githubusercontent.com/shamimice03/Network_Policies_Kubernetes/main/netpol-deny-all-frontend.yaml

---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny-all-frontend
  namespace: frontend
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Ingress
  - Egress
---

● Разрешаем исходящий трафик на бэкенд
Сейчас весь трафик для фронтенда запрещён. Для отправки трафика на бэкенд нужно разрешить исходящий трафик на бэкенд и в пространство имён kube-system, чтобы разрешать DNS-имена сервисов, как мы говорили чуть выше.

# Allow egress to backend-tier
> kubectl create -f \
  https://github.com/shamimice03/Network_Policies_Kubernetes/blob/main/netpol-allow-egress-to-backend.yaml
  
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-backend
  namespace: frontend
spec:
  podSelector:
    matchLabels: {}
  egress:
    - to:
      - podSelector:
          matchLabels: {}
        namespaceSelector:
           matchLabels:
              tier: backend
    - to:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: kube-system
        podSelector:
          matchLabels:
            k8s-app: kube-dns
      ports:
      - protocol: UDP
        port: 53
---

Вот что мы получаем теперь:

● Разрешаем входящий трафик из интернета
Раз мы обращаемся к фронтенду через сервис балансировки нагрузки, запрос будет поступать с IP-адреса внешнего балансировщика нагрузки. Мы запретили весь входящий трафик, так что пока не сможем получить доступ к приложению на фронтенде через внешний IP. Нужно создать сетевую политику, которая разрешит входящий трафик из любого места, кроме частных IP-адресов pod’ов. Так мы запретим трафик с pod’ов, которые находятся в других пространствах имён.

# Allow ingress from everywhere except pod-network
> kubectl create -f \
  https://raw.githubusercontent.com/shamimice03/Network_Policies_Kubernetes/main/netpol-allow-ingress-from-everywhere.yaml
  
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-from-loadbalancer
  namespace: frontend
spec:
  podSelector:             
    matchLabels: {}
  ingress:                   
    - from:
      - ipBlock:           
          cidr: 0.0.0.0/0    
          except:            # Restrict the Private IP CIDR Block of your pod network. 
           - 10.0.0.0/8      # So that, pods from other namespaces cannot send ingress traffic.
      ports:                
      - protocol: TCP
        port: 80 
---

Мы применили все сетевые политики, которые нужны для защиты и изоляции рабочих нагрузок Kubernetes. Вот как всё работает теперь:

5. Проверяем, что получилось

Давайте протестируем нашу систему и убедимся, что сетевые политики работают, как ожидалось.

● Для начала попробуем получить к приложению доступ через внешний IP-адрес сервиса балансировки нагрузки.

Мы видим, что приложение во фронтенде доступно с внешнего IP-адреса.

Практический курс, охватывает все аспекты безопасности проекта на Kubernetes.

● Давайте попробуем через pod во фронтенде получить доступ к сервисам в бэкенде и базе данных. Первое должно получиться, второе — нет.

# Dive into a pod of the "frontend" deployment
> kubectl exec -it frontend-5d7445bdb8-g8rpb  -n frontend bash
# Try to access a service(clusterIP) named "backend", resides in the backend-tier 
>>  curl backend.backend     
---------------------------------------------------------------------------------
<!DOCTYPE html>
<html>
<head>                                 #Successfully Accessed
<title>Welcome to nginx!</title>
<style>
...
---------------------------------------------------------------------------------
 # Try to access a service(clusterIP) named "database", resides in the database-tier 
>>  curl database.database 
---------------------------------------------------------------------------------
# curl: (28) Failed to connect to database.database port 80: Connection timed out
---------------------------------------------------------------------------------

● Теперь проверим сетевые политики через pod на бэкенде.

# Dive into a pod of the "backend" deployment
> kubectl exec -it backend-5c5c74cbf6-h4d9p  -n backend bash
# Try to access a service(clusterIP) named "frontend", resides in the frontend-tier 
>>  curl frontend.frontend    
---------------------------------------------------------------------------------
# curl: (28) Failed to connect to frontend.frontend port 80: Connection timed out
---------------------------------------------------------------------------------

# Try to access a service(clusterIP) named "database", resides in the database-tier 
>>  curl database.database 
----------------------------------------------------------------------------------
<!DOCTYPE html>
<html>
<head>                                 #Successfully Accessed
<title>Welcome to nginx!</title>
<style>
...
----------------------------------------------------------------------------------

● Наконец, сделаем то же самое из pod’а в базе данных.

# Dive into a pod of the "database" deployment
> kubectl exec -it database-7d94797799-b9sdw   -n database bash
# Try to access a service(clusterIP) named "backend", resides in the backend-tier 
>>  curl backend.backend     
---------------------------------------------------------------------------------
# curl: (28) Failed to connect to backend.backend port 80: Connection timed out
---------------------------------------------------------------------------------

# Try to access a service(clusterIP) named "frontend", resides in the frontend-tier 
>>  curl frontend.frontend    
---------------------------------------------------------------------------------
# curl: (28) Failed to connect to frontend.frontend port 80: Connection timed out
---------------------------------------------------------------------------------

Как видите, все наши сетевые политики работают, как ожидалось.