Глава 5. Настройка границ безопасности Kubernetes

Границы безопасности присутствуют на уровне данных, сетевом уровне и системном уровне. Границы безопасности щависят от технологий, которые используются соответствующим подразделением ИТ или командой инфраструктуры. Например, когда команды используют виртуальные машины для управления их приложениями - границы для виртуальных машин пролегают в гипервизоре. Гипервизоры обеспечивают, что запускаемы в некой виртуальной машине код не выходит из соответствующей виртуальной машины и не воздействуют н сам физический узел. Компании начинают осваивать микрослужбы и применять оркестрторы для управления своими приложениями, одной из границ безопасности являются контейнеры. Тем не менее, по сравнению с гипервизорами, контейнеры не предоставляют строгие границы безопасности и не стремятся к этому. Контейнеры устанавливают ограничения на уровне приложения, но не препятствуют злоумышленникам обходить эти ограничения на уровне ядра.

На сетевом уровне, обычно межсетевые экраны предоставляют сильные границы безопасности приложениям. В архитектуре микрослужб Поды в Kubernetes способны взаимодействовать с прочими. Сетевые политики используются для ограничения взаимодействия между Подами и Службами.

Границы безопасности на уровне данных хорошо известны. Ядра ограничивают доступ на запись к каталогам system или bin только для пользователей root или system это простейший пример границ безопасности на уровне данных. В заключаемых в контейнеры средах, chroot препятствует вмешательству контейнеров в файловые системы прочих контейнеров. Kubernetes реструктурирует развёртывание приложения таким образом, что строгие границы безопасности могут применться как на сетевом уровне, так и на системном уровнях.

Границы безопасности и границы доверительных отношений часто применяются в качестве синонимов. Несмотря на их схожесть, у этих двух понятий имеется небольшое отличие. Границы доверительных отношений пролегают там, где система изменяет свой уровень доверия. Приведение в исполнение границ доверия, это когда инструкциям для их осуществления требуются различные привилегии. Например, выполняющий код из /bin сервер баз данных выступает примером пересекающего границы доверия исполнения. Точно также, граница доверительного отношения к данным пролегают там, где данные перемещаются между логическими элементами с различными уровнями доверия. Вставвляемые конечным пользователем в обладающую доверием базу данных является примером пересечения данными границ доверительных отношений.

В то время как граница безопасности это некий пункт демаркации между различными областями (доменами) безопасности, домен безопасности это набор логических элементов, которые пребывают внутри одного и того же уровня доступа. Например, в традиционной веб архитектуре ориентированные на пользователя приложения выступают частью домена безопасности, а внутренняя сетевая среда это часть другого домена безопасности. Границы безопасности обладают связанным с ними контролем доступа. Представляйте себе границы доверия как стену, а ограничение безопасности как некий забор вокруг этой стены.

Важно выяволять границы безопасности и доверительных отношений. Это способствует обеспечению надлежащщей проверки инструкций и данных до того как они покинут установленниые границы. В Kubernetes компоненты и объекты выходят за различные границы безопасности. Важно осознавать эти границы для внедрения планов снижения рисков при пересечении злоумышленниками границ безопасности. CVE-2018-1002105 является ярким примером атаки, вызванной отсутствиемроверки границ доверительных отношений; обработка посреднического (прокси) запроса на сервере API сделала возможным для не имеющего аутентификации пользователя заполучить права администратора в этом кластере. Точно так же CVE-2018-18264 сделала возможным пользователям пропускать процесс аутентификации в инструментальной панели для того чтобы позволять пользователям без аутентификации осуществлять доступ к конфиденциальным сведениям кластера.

Давайте рассмотрим различные области безопасности Kubernetes.

В широком плане кластер Kubernetes можно подразделить на три области безопасности:

Такое подразделение областей безопасности на верхнем уровне должно помочь вам сосредоточиться на самых ключевых средствах. Имейте в виду, мы приступаем к рассмотрению логических элементов Kubernetes и того как возводить вокруг них границы безопасности.

В кластере Kubernetes те логические элементы Kubernetes (объекты и компоненты), с которыми вы взаимодействуете обладают своими собственными встроенными границами безопасности. Эти границы безопасности приосходят из самой архитектуры или реализации таких логических элементов. Важно осознавать те границы безопасности, которые воздвигаются внутри или вокруг них:

Мы уже обсуждали три различных субъекта угроз в Главе 3, Моделирование угроз: Привилегированные злоумышленники, внутренние злоумышленники и конечные пользователи. Эти субъекты угроз способны также взаимодействовать со всеми предыдущими логическими элементами Kubernetes. Мы рассмотрим с каими из ограничений безопасности сталкиваются эти злоумышленники:

В этом разделе мы рассмотрели ограничения безопасности с точки зрения пользователя и показали вам как возводятся границы безопасности в соответствующей экосистеме Kubernetes. Далее давайте рассмотрим ограничения безопасности на общем системном уровне, с точки зрения микрослужб.

Микрослужбы исполняются внутри Подов, причём Полы планируются к запуску в узлах исполнителей в кластере. В своих предыдущих главах мы уже делали акцент на то, что некий контейнер это какой- то процесс, которому назначены выделенные пространства имён Linux. Контейнер или Под потребляют все необходимые им ресурсы, предоставляемые соответствующим узлом исполнителя. А потому важно осознавать ограничения безопасности с точки зрения самой системы и то как их возводить. В этом разделе мы обсудим построение границ безопасности поверх пространтсв имён Linux и возможности Linux совместно с микрослужбами.

Пространства имён Linux являются функциональной возможностью самого ядра Linux для разбиения ресурсов на части с целью их изоляции. Обладая выделенными им пространствами имён, некий набор процессов наблюдает один набор ресурсов, в то время как другой набор процессов видит иной набор ресурсов. Мы уже вводили пространства имён Linux в Главе 2, Построение сетевой среды Kubernetes {Прим. пер.: более углублённо стреоние пространств имён рассматривается в только что выполненном нами переводе книги Шашанка Мохана Джейна Контейнеры Linux и Виртуализация: с точки зрения ядра, Apress, октябрь 2020}. По умолчанию, каждый Под обладает своим собственным сетевым пространством имён и пространтсвом имён IPC. Всякий контейнер внутри того же самомого пода облдает своим собственным пространством имён PID с тем, чтобы прочие контейнеры не были осведомлены относительно прочих запущенных внутри этого Пода контейнерах. Аналогично, некий Под не осведомлён о прочих имеющихся в том же самом узле исполнителя Подах.

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

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

root@nginx-2:/# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.1  0.0  32648  5256 ?        Ss   23:47   0:00 nginx: master process nginx -g daemon off;
nginx          6  0.0  0.0  33104  2348 ?        S    23:47   0:00 nginx: worker process
root           7  0.0  0.0  18192  3248 pts/0    Ss   23:48   0:00 bash
root          13  0.0  0.0  36636  2816 pts/0    R+   23:48   0:00 ps aux
 	   

Как вы можете видеть, изнутри нашего контейнера nginx в прочих контейнерах видны только процесс nginx и процесс bash. Этот под nginx не пользуется пространством имён PID хоста. Давайте рассмотрим что происходит когда под пользуется прострнством имён PID хоста:

root@gke-demo-cluster-default-pool-c9e3510c-tfgh:/# ps axu
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.2  0.0  99660  7596 ?        Ss   22:54   0:10 /usr/lib/systemd/systemd noresume noswap cros_efi
root          20  0.0  0.0      0     0 ?        I<   22:54   0:00 [netns]
root          71  0.0  0.0      0     0 ?        I    22:54   0:01 [kworker/u4:2]
root         101  0.0  0.1  28288  9536 ?        Ss   22:54   0:01 /usr/lib/systemd/systemd-journald
201          293  0.2  0.0  13688  4068 ?        Ss   22:54   0:07 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile
274          297  0.0  0.0  22520  4196 ?        Ss   22:54   0:00 /usr/lib/systemd/systemd-networkd
root         455  0.0  0.0      0     0 ?        I    22:54   0:00 [kworker/0:3]
root        1155  0.0  0.0   9540  3324 ?        Ss   22:54   0:00 bash /home/kubernetes/bin/health-monitor.sh container-runtime
root        1356  4.4  1.5 1396748 118236 ?      Ssl  22:56   2:30 /home/kubernetes/bin/kubelet --v=2 --cloud-provider=gce --experimental
root        1635  0.0  0.0 773444  6012 ?        Sl   22:56   0:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.contai
root        1660  0.1  0.4 417260 36292 ?        Ssl  22:56   0:03 kube-proxy --master=https://35.226.122.194 --kubeconfig=/var/lib/kube-
root        2019  0.0  0.1 107744  7872 ?        Ssl  22:56   0:00 /ip-masq-agent --masq-chain=IP-MASQ --nomasq-all-reserved-ranges
root        2171  0.0  0.0  16224  5020 ?        Ss   22:57   0:00 sshd: gke-1a5c3c1c4d5b7d80adbc [priv]
root        3203  0.0  0.0   1024     4 ?        Ss   22:57   0:00 /pause
root        5489  1.3  0.4  48008 34236 ?        Sl   22:57   0:43 calico-node -felix
root        6988  0.0  0.0  32648  5248 ?        Ss   23:01   0:00 nginx: master process nginx -g daemon off;
nginx       7009  0.0  0.0  33104  2584 ?        S    23:01   0:00 nginx: worker process
 	   

Наш предыдущий вывод отображает все запущенные в узле исполнителя процессы из контейнера nginx. Помимо этих процессов имеются системные процессы, такие как sshd, kubelet, kube-proxy и тому подобные. Помимо применения этим Подом пространства имён своего хоста, вы способны отправлять сигналы в прочие процессы микрослужб, например, SIGKILL для уничтожения некого процесса.

Возможности Linux это некое понятие, вовлекаемое из проверки полномочий традиционного Linux: привилегированные и без привилегий. Привилегированные процессы обходят все проверки полномочий ядра. Далее Linux подразделяет ассоциируемые с суперпользовтелями Linux полномочия на отличающиеся элементы - возможности Linux. Имеются относящиеся к сетевой среде возможности, такие как CAP_NET_ADMIN, CAP_NET_BIND_SERVICE, CAP_NET_BROADCAST и CAP_NET_RAW. А также связанные с аудитом возможности: CAP_AUDIT_CONTROL, CAP_AUDIT_READ и CAP_AUDIT_WRITE. Естественно, всё ещё существуют и возможности подобные администрированию: CAP_SYS_ADMIN.

Как это уже упоминалось в Главе 4, Применение принципа наименьших прав в Kubernetes, вы имеете возможность настройки возможностей Linux для уонтейнеров в неком поде. Вот список устанавливаемых по умолчанию возможностей, которые выделяются контейнерам в кластерах Kubernetes:

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

root@gke-demo-cluster-default-pool-c9e3510c-tfgh:/# tcpdump -i cali01fb9a4e4b4 -v
tcpdump: listening on cali01fb9a4e4b4, link-type EN10MB (Ethernet), capture size 262144 bytes
23:18:36.604766 IP (tos 0x0, ttl 64, id 27472, offset 0, flags [DF], proto UDP (17), length 86)
    10.56.1.14.37059 > 10.60.0.10.domain: 35359+ A? www.google.com.default.svc.cluster.local. (58)
23:18:36.604817 IP (tos 0x0, ttl 64, id 27473, offset 0, flags [DF], proto UDP (17), length 86)
    10.56.1.14.37059 > 10.60.0.10.domain: 35789+ AAAA? www.google.com.default.svc.cluster.local. (58)
23:18:36.606864 IP (tos 0x0, ttl 62, id 8294, offset 0, flags [DF], proto UDP (17), length 179)
    10.60.0.10.domain > 10.56.1.14.37059: 35789 NXDomain 0/1/0 (151)
23:18:36.606959 IP (tos 0x0, ttl 62, id 8295, offset 0, flags [DF], proto UDP (17), length 179)
    10.60.0.10.domain > 10.56.1.14.37059: 35359 NXDomain 0/1/0 (151)
23:18:36.607013 IP (tos 0x0, ttl 64, id 27474, offset 0, flags [DF], proto UDP (17), length 78)
    10.56.1.14.59177 > 10.60.0.10.domain: 7489+ A? www.google.com.svc.cluster.local. (50)
23:18:36.607053 IP (tos 0x0, ttl 64, id 27475, offset 0, flags [DF], proto UDP (17), length 78)
    10.56.1.14.59177 > 10.60.0.10.domain: 7915+ AAAA? www.google.com.svc.cluster.local. (50)
 	   

Приведённый вывод отображает нам, что внутри контейнера имеется tcpdump, осуществляющий ожидание в своём сетевом интерфнйсе, cali01fb9a4e4b4, который был создан для сетевого взаимодействия другого пода. Имия предоставленными сетевое пространство им1н и CAP_NET_ADMIN, вы способны отслеживать сетевой обмен со всего узла исполнителя внутри контейнера. В целом, чем меньше возможностей предоставляется контейнерам, тем больше безопасности для ограничений прочих микрослужб.

Выделенные пространства имён Linux и заданные по умолчанию пределы назначаемых контейнеру или Поду возмжностей Linux устанавливают неплохие ограничения безопасности для микрослужб. Тем не менее, пользовтелям всё ещё дозволяется настраивать пространства имён хоста или добавлять дополнительные возможности Linux в енкую рабочую нагрузку. Это разузорожит установленные для прочих запущенных в том же самом узле исполнителя границы безопасности. Вам следует осуществлять это очень внимательно. Обычно инструменты мониторинга или средства безопасности требуют доступа к пространствам имён хоста чтобы выполнять свои задания мониторинга или задания выявления. А потому настроятельно рекомендуется пользоваться PodSecurityPolicy для ограничения использования пространств имён хоста, а также избыточных возможнотей с тем, чтобы держать взаперти границы безопасности микрослужб.

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

Сетевая политика Kubernetes определяет необходимые правила для различных групп Подов, которым позволяется взаимодействие друг с другом. В нашей предыдущей главе мы кратко обсудили исходящие правила сетевой политики Kuberneted, которые могут применяться для усиления основного принципа наименьшихполномочий для микрослужб. В этом разделе мы продвинемся слегка далее в сетевые политики Kubernetes и сосредоточимся на его входящих правилах. Мы покажем как входящие правила сетевых политик способны помогать установлению границ доверительных отношений между микрослужбами.

Как это уже упоминалось в наших предыдущих главах, согласно требований имеющейся сетевой модели, Поды внутри кластера имеют возможность взаимодействия друг с другом. Но всё- таки, с точки зрения безопасности, вы можете пожелать ограничить свои микрослужбы на доступ всего лишь несколькими службами. Как мы можем достичь этого в Kubernetes? Давайте взглянем на следующий образец сетевой политики Kubernetes:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978
 	   

Наша политика NetworkPolicy носит название test-network-policy. Здесь неплохо будет перечислить несколько ключевых атрибутов из определения этой сетевой политики чтобы помочь вам разобраться с тем что собой представляют эти ограничения:

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

Для усиления границ доверительных отношений для микрослужб со стороны сетевой среды вы можете пожелать определить либо значения допустимого ipBlock извне, либо допустимые микрослужбы из определённого пространства имён. Ниже приводится ещё один пример для ограничения значения источника на вход определёнными Подами и пространствами имён при помощи namespaceSelector podSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-good
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          from: good
      podSelector:
        matchLabels:
          from: good
 	   

Обратите внимание, что перед podSelector нет никакого атрибута. Это означает, что источником на вход могут быть лишь поды с меткой from: good в значении пространства имён с меткой from: good. Такая сетевая поилитика защищает Полы с меткой app: web в установленном по умолчанию пространстве имён:

В нашей приведённой выше схеме пространство имён good обладает значением метки from: good, в то время как пространтсво имён bad имеет значение метки from: bad. Это иллюстрирует что только Поды со значением метки from: good в своём пространстве имйн имеющем пометку from: good имеют возможность доступа к нашей службе nginx-web из пространства имён по умолчанию. Прочие Поды, вне зависимости от того будут ли они из пространства имён good, но без значения метки from: good, либо из прочих пространств имён, не смогут получать доступ к нашей службе nginx-web из пространства имён по умолчанию.

В этой главе мы обсудили значение важности ограничений безопасности. Понимание установленных областей безопасности и границ безопасности внутри своей экосистемы Kubernetes помогает администраторам осознавать радиус подрыва при некоторой атаке и разрабатывать стратегии смягчения последствий для ограничения ущерба, наносимого в результате атаки. Знание логических элементов Kubernetes является отправной точкой для возведения границ безопасности. Понимание встроенных в сам системный уровени ограничений безопасности при помощи пространств имён Linux и его возможностей это следующий шаг. И последнее, но не по значимости, осознание сетевых политик также критически важно для построения сегментации безопасности в микрослужбах.

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

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

Сетевые политики Kubernetes

CVE-2018-18264

CVE-2018-1002105

{Прим. пер.: наш перевод книги Шашанка Мохана Джейна Контейнеры Linux и Виртуализация: с точки зрения ядра, изданной Apress в октябре 2020}