Table of Contents

URL: https://www.progressiverobot.com/recommended-steps-to-secure-a-cloud-provider-kubernetes-cluster-ru/

*Автор выбрал организацию Open Sourcing Mental Illness Ltd для получения пожертвований в рамках программы Write for DOnations.*

Введение

Kubernetes, платформа для управления контейнерами с открытым исходным кодом, повсеместно становится предпочитаемым решением для автоматизации, масштабирования и управления кластерами с высоким уровнем доступности. Благодаря растущей популярности данной платформы, безопасность Kubernetes становится все более актуальной.

Учитывая составные части Kubernetes, а также разнообразие сценариев развертывания, защита Kubernetes иногда может быть сопряжена с трудностями. Поэтому цель этой статьи заключается в том, чтобы заложить прочную основу безопасности для кластера Kubernetes (DOKS). Необходимо отметить, что настоящий обучающий модуль охватывает базовые меры безопасности для Kubernetes и служит отправной точкой, а не исчерпывающим руководством. Дополнительные шаги можно найти в официальной документации Kubernetes.

В этом руководстве вы будете выполнять основные шаги для защиты кластера Kubernetes. Вы настроите защищенную локальную аутентификацию с сертификатами TLS/SSL, предоставите разрешения локальным пользователям с помощью механизмов управления доступом на базе ролей (RBAC), предоставите разрешения приложениям Kubernetes и развертыванию со служебными учетными записями, а также установите ограничения ресурсов при помощи контроллеров допуска ResourceQuota и LimitRange.

Предварительные требования

kubernetes illustration for: Предварительные требования

Чтобы выполнить это руководство, вам потребуется следующее:

  • Управляемый кластер Kubernetes (DOKS) с тремя стандартными узлами, имеющими не менее чем 2 Гбайт ОЗУ и 1 виртуального процессора каждый. Подробные инструкции по созданию кластера DOKS можно найти в обучающем модуле Начало работы с Kubernetes. В этом обучающем руководстве используется версия DOKS 1.16.2-do.1.
  • Интерфейс командной строки kubectl, установленный на локальном компьютере. Дополнительную информацию об установке и настройке kubectl можно найти в официальной документации. В этом обучающем руководстве будет использоваться версия kubectl 1.17.0-00.
  • Официальный инструмент командной строки the cloud provider — doctl. Информацию о выполнении установки можно найти на странице doctl GitHub. В этом обучающем руководстве будет использоваться версия doctl 1.36.0.

Шаг 1 — Активация аутентификации удаленного пользователя

После завершения предварительных действий вы будете выполнять работу с одним суперпользователем Kubernetes, который аутентифицируется посредством заданного токена the cloud provider. Однако обмен этими учетными данными не является эффективной практикой безопасности, поскольку данная учетная запись может вызвать масштабные и даже деструктивные изменения в вашем кластере. Чтобы снизить этот риск, вы можете настроить дополнительных пользователей, которые будут аутентифицироваться из соответствующих локальных клиентов.

В этом разделе вы будете выполнять аутентификацию новых пользователей в удаленном кластере DOKS из локальных клиентов при помощи защищенных сертификатов SSL/TLS. Этот процесс будет проходить в три этапа: во-первых, вы создадите запросы подписи сертификатов (CSR)) для каждого пользователя, а затем вы будете одобрять эти сертификаты непосредственно в кластере через kubectl. Наконец, вы создадите для каждого пользователя файл kubeconfig с соответствующими сертификатами. Расширенную информацию о дополнительных методах аутентификации при поддержке Kubernetes можно найти в документации по аутентификации Kubernetes.

Создание запросов подписи сертификатов для новых пользователей

Перед началом необходимо проверить подключение кластера DOKS к локальному компьютеру, настроенному с предварительными условиями:

				
					
kubectl cluster-info

В зависимости от конфигурации, вы увидите примерно следующее:

				
					
[secondary_label Output]

Kubernetes master is running at https://www.progressiverobot.com/

CoreDNS is running at https://www.cloudflare.com/learning/dns/what-is-dns/



To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Это означает, что вы подключены к кластеру DOKS.

Далее создайте локальную папку для сертификатов клиента. Для целей настоящего руководства будет использоваться папка ~/certs для хранения всех сертификатов:

				
					
mkdir ~/<^>certs<^>

В этом обучающем руководстве мы дадим новому пользователю с именем sammy доступ к кластеру. Вы можете изменить это на любого пользователя по вашему выбору. Используя библиотеку SSL и TLS OpenSSL, создайте новый закрытый ключ для вашего пользователя с помощью следующей команды:

				
					
openssl genrsa -out ~/<^>certs<^>/<^>sammy<^>.key 4096

Флаг -out будет создавать выходной файл ~/<^>certs<^>/<^>sammy<^>.key, а 4096 устанавливает ключ длиной 4096 бит. Дополнительную информацию по OpenSSL можно найти в нашем руководстве по основам OpenSSL.

Теперь создайте файл конфигурации запроса подписи сертификатов. Откройте следующий файл в текстовом редакторе (в этом обучающем модуле мы будем использовать nano):

				
					
nano ~/&lt;^&gt;certs/sammy.csr.cnf&lt;^&gt;

Добавьте в файл <^>sammy.csr.cnf<^> следующее содержимое, чтобы задать в строке темы желаемое имя пользователя как обычное имя (CN) и группу в качестве организации (O):

				
					
[label ~/certs/sammy.csr.cnf]

[ req ]

default_bits = 2048

prompt = no

default_md = sha256

distinguished_name = dn

[ dn ]

CN = &lt;^&gt;sammy&lt;^&gt;

O = &lt;^&gt;developers&lt;^&gt;

[ v3_ext ]

authorityKeyIdentifier=keyid,issuer:always

basicConstraints=CA:FALSE

keyUsage=keyEncipherment,dataEncipherment

extendedKeyUsage=serverAuth,clientAuth

Файл конфигурации запроса подписи сертификатов содержит всю необходимую информацию, идентификационные данные пользователя и соответствующие параметры использования для данного пользователя. Последний аргумент extendedKeyUsage=serverAuth,clientAuth позволит пользователям аутентифицировать локальных клиентов с кластером DOKS при помощи сертификата после его подписания.

Далее создайте запрос подписи сертификатов пользователя sammy:

				
					
openssl req -config ~/&lt;^&gt;certs&lt;^&gt;/&lt;^&gt;sammy&lt;^&gt;.csr.cnf -new -key ~/&lt;^&gt;certs&lt;^&gt;/&lt;^&gt;sammy&lt;^&gt;.key -nodes -out ~/&lt;^&gt;certs&lt;^&gt;/&lt;^&gt;sammy&lt;^&gt;.csr

Параметр -config позволяет задать файл конфигурации для CSR, а сигналы -new, которые вы создаете — для нового CSR для ключа, указанного в -key.

Вы можете проверить запрос подписи сертификатов посредством следующей команды:

				
					
openssl req -in ~/&lt;^&gt;certs&lt;^&gt;/&lt;^&gt;sammy&lt;^&gt;.csr -noout -text

Здесь вы передаете в CSR с -in и используете -text, чтобы распечатать запрос сертификата в текстовом сообщении.

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

				
					
[secondary_label Output]

Certificate Request:

 Data:

 Version: 1 (0x0)

 Subject: CN = &lt;^&gt;sammy&lt;^&gt;, O = &lt;^&gt;developers&lt;^&gt;

 Subject Public Key Info:

 Public Key Algorithm: rsaEncryption

 RSA Public-Key: (4096 bit)

...

Повторите эту же процедуру для создания CSR для всех дополнительных пользователей. Когда все запросы подписи сертификатов будут сохранены в папке администратора ~/certs, выполните следующий шаг для их утверждения.

Управление запросами подписи сертификатов с API Kubernetes

Вы можете одобрять или отклонять сертификаты TLS, выданные для API Kubernetes, используя инструмент командной строки kubectl. Это дает возможность убедиться, что запрошенный доступ соответствует данному пользователю. В этом разделе мы направим запрос сертификатов для пользователя sammy и одобрим его.

Чтобы направить CSR в кластер DOKS, используйте следующую команду:

				
					
cat &lt;&lt;EOF | kubectl apply -f -

apiVersion: certificates.k8s.io/v1beta1

kind: CertificateSigningRequest

metadata:

 name: &lt;^&gt;sammy-authentication&lt;^&gt;

spec:

 groups:

 - system:authenticated

 request: $(cat ~/&lt;^&gt;certs&lt;^&gt;/&lt;^&gt;sammy&lt;^&gt;.csr | base64 | tr -d '\n')

 usages:

 - digital signature

 - key encipherment

 - server auth

 - client auth

EOF

Используя heredoc-синтаксис в Bash*,* эта команда использует cat для передачи запроса сертификатов в команду kubectl apply.

Рассмотрим запрос сертификатов более подробно:

  • name: <^>sammy-authentication<^> создает идентификатор метаданных, в данном случае с именем sammy-authentication.
  • request: $(cat ~/<^>certs<^>/<^>sammy<^>.csr | bar64 | tr -d 'n' направляет запрос подписи сертификатов sammy.csr в кластер, кодифицированный как base64.
  • В server auth и client auth указывается предполагаемое использование сертификата. В данном случае цель — аутентификация пользователя.

Результат будет выглядеть примерно следующим образом:

				
					
[secondary_label Output]

certificatesigningrequest.certificates.k8s.io/&lt;^&gt;sammy-authentication&lt;^&gt; created

Вы можете проверить состояние запроса подписи сертификатов с помощью команды:

				
					
kubectl get csr

В зависимости от конфигурации кластера, вы увидите примерно следующее:

				
					
[secondary_label Output]

NAME AGE REQUESTOR CONDITION

&lt;^&gt;sammy-authentication&lt;^&gt; 37s &lt;^&gt;your_DO_email&lt;^&gt; Pending

Далее одобрите CSR с помощью команды:

				
					
kubectl certificate approve &lt;^&gt;sammy-authentication&lt;^&gt;

Вы получите сообщение, подтверждающее операцию:

				
					
[secondary_label Output]

certificatesigningrequest.certificates.k8s.io/&lt;^&gt;sammy-authentication&lt;^&gt; approved

Примечание: Как администратор, вы также можете отклонить CSR посредством команды ​​​kubectl certificate deny <^>sammy-authentication<^>. Дополнительную информацию по управлению сертификатами TLS можно найти в официальной документации Kubernetes.

После утверждения CSR вы можете загрузить его на локальный компьютер с помощью следующей команды:

				
					
kubectl get csr &lt;^&gt;sammy-authentication&lt;^&gt; -o jsonpath='{.status.certificate}' | base64 --decode &gt; ~/&lt;^&gt;certs&lt;^&gt;/&lt;^&gt;sammy&lt;^&gt;.crt

Эта команда декодирует сертификат Base64 для надлежащего использования с помощью kubectl, а затем сохраняет его как ~/<^>certs<^>/<^>sammy<^>.crt.

С подписанным сертификатом sammy вы можете создавать пользовательский файл kubeconfig.

Создание удаленных пользователей Kubeconfig

Далее вы создадите специальный файл kubeconfig для пользователя sammy. Это позволит лучше контролировать возможность доступа пользователя к вашему кластеру.

Первый шаг в создании нового kubeconfig — создание копии текущего файла kubeconfig. Для целей настоящего руководства новый файл kubeconfig будет иметь имя <^>config-sammy<^>:

				
					
cp ~/.kube/config ~/.kube/&lt;^&gt;config-sammy&lt;^&gt;

Далее, измените новый файл:

				
					
nano ~/.kube/&lt;^&gt;config-sammy&lt;^&gt;

Сохраните первые восемь строк этого файла, поскольку они содержат необходимую информацию для подключения SSL/TLS к кластеру. Далее, начиная с параметра user, замените текст следующими выделенными строками, чтобы файл выглядел примерно следующим образом:

				
					
[label config-sammy]

apiVersion: v1

clusters:

- cluster:

 certificate-authority-data: certificate_data

 name: do-nyc1-do-cluster

contexts:

- context:

 cluster: do-nyc1-do-cluster

 user: &lt;^&gt;sammy&lt;^&gt;

 name: do-nyc1-do-cluster

current-context: do-nyc1-do-cluster

kind: Config

preferences: {}

users:

- name: &lt;^&gt;sammy&lt;^&gt;

 user:

 &lt;^&gt;client-certificate: /home/your_local_user/certs/sammy.crt&lt;^&gt;

 &lt;^&gt;client-key: /home/your_local_user/certs/sammy.key&lt;^&gt;

Примечание: для client-certificate и client-key используйте абсолютный путь к соответствующему местоположению их сертификатов. В противном случае kubectl выдаст ошибку.

Сохраните и закройте файл.

Вы можете протестировать новое подключение пользователя с помощью kubectl cluster-info:

				
					
kubectl --kubeconfig=/home/&lt;^&gt;your_local_user&lt;^&gt;/.kube/&lt;^&gt;config-sammy&lt;^&gt; cluster-info

Ошибка будет выглядеть примерно так:

				
					
[secondary_label Output]

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Error from server (Forbidden): services is forbidden: User "&lt;^&gt;sammy&lt;^&gt;" cannot list resource "services" in API group "" in the namespace "kube-system"

Эта ошибка ожидается, поскольку пользователь sammy еще не имеет разрешения на запись каких-либо ресурсов в кластер. На следующем шаге будет рассмотрено предоставление разрешений пользователям. В результате вы увидите, что подключение SSL/TLS прошло успешно, а данные аутентификации sammy приняты в Kubernetes API.

Шаг 2 — Авторизация пользователй через систему контроля доступа на основе ролей (RBAC)

После аутентификации пользователя API определяет свои разрешения с помощью встроенной модели Kubernetes по контролю доступа на основе ролей (RBAC) RBAC — эффективный способ ограничения прав пользователя на основании его роли. С точки зрения безопасности, RBAC разрешает устанавливать детальные разрешения, чтобы ограничить возможность доступа пользователей к чувствительным данным или выполнения команд уровня суперпользователя. Более подробная информация о ролях пользователей содержится в документации Kubernetes RBAC.

На этом шаге вы будете использовать kubectl для назначения заранее определенной роли edit пользователю sammy в области имен default. В производственной среде можно использовать настраиваемые роли и/или привязки ролей.

Предоставление разрешений

В Kubernetes предоставление разрешений означает назначение требуемой роли пользователю. Назначьте разрешения edit пользователю sammy в пространстве имен default с помощью следующей команды:

				
					
kubectl create rolebinding &lt;^&gt;sammy-edit-role&lt;^&gt; --clusterrole=edit --user=&lt;^&gt;sammy&lt;^&gt; --namespace=default

Результат будет выглядеть примерно следующим образом:

				
					
[secondary_label Output]

rolebinding.rbac.authorization.k8s.io/&lt;^&gt;sammy-edit-role&lt;^&gt; created

Рассмотрим эту команду более подробно:

  • create rolebinding <^>sammy-edit-role<^> создает новую привязку ролей, в данном случае с именем <^>sammy-edit-role<^>.
  • --clusterrole=edit назначает заранее определенную роль edit в глобальном масштабе (роль кластера).
  • --user=<^>sammy<^> указывает, к какому пользователю следует привязать роль.
  • --namespace=default предоставляет пользователю разрешения ролей в пределах указанного пространства имен, в данном случае default.

Далее проверьте разрешения пользователя посредством указания подов в пространстве имен default. Если ошибки не отображаются, то это означает, что авторизация RBAC работает так, как ожидается.

				
					
kubectl --kubeconfig=/home/&lt;^&gt;your_local_user&lt;^&gt;/.kube/&lt;^&gt;config-sammy&lt;^&gt; auth can-i get pods

Результат будет выглядеть следующим образом:

				
					
[secondary_label Output]

yes

Теперь, когда вы назначили разрешения пользователю sammy, вы можете (в качестве упражнения) отозвать эти разрешения в следующем разделе.

Отзыв разрешений

Чтобы отозвать разрешения в Kubernetes, необходимо удалить привязку ролей пользователя.

В этом обучающем модуле мы удалим роль edit пользователя sammy посредством следующей команды:

				
					
kubectl delete rolebinding &lt;^&gt;sammy-edit-role&lt;^&gt;

Результат будет выглядеть следующим образом:

				
					
[secondary_label Output]

rolebinding.rbac.authorization.k8s.io "&lt;^&gt;sammy-edit-role&lt;^&gt;" deleted

Убедитесь, что разрешения пользователя были правильно отозваны посредством указания подов в пространстве имен default:

				
					
kubectl --kubeconfig=/home/&lt;^&gt;localuser&lt;^&gt;/.kube/&lt;^&gt;config-sammy&lt;^&gt; --namespace=default get pods

Вы получите следующую ошибку:

				
					
[secondary_label Output]

Error from server (Forbidden): pods is forbidden: User "&lt;^&gt;sammy&lt;^&gt;" cannot list resource "pods" in API group "" in the namespace "default"

Это показывает, что авторизация отозвана.

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

Дополнительную информацию об авторизации RBAC и создании настраиваемых ролей можно найти в официальной документации.

Шаг 3 — Управление разрешениями приложений со служебными учетными записями

Как упоминалось в предыдущем разделе, механизмы авторизации RBAC распространяются не только на физических пользователей. Виртуальные пользователи кластера — например, приложения, службы и процессы, запущенные внутри подов — аутентифицируются на сервере API при помощи того, что в Kubernetes называется *«служебные учетные записи»*. Когда под создается в пространстве имен, вы можете либо позволить ему использовать служебную учетную запись default, либо определить служебную учетную запись по своему выбору. Благодаря способности назначать отдельные служебные учетные записи приложениям и процессам администраторы получают возможность предоставлять или отзывать разрешения, по мере необходимости. Кроме того, назначение конкретных служебных учетных записей для приложений, критичных для производства, считается наилучшей практикой безопасности. Поскольку учетные записи используются для аутентификации и, т.о., для проверки авторизации RBAC, администраторы кластеров могут устранять угрозы безопасности посредством изменения прав доступа к служебным учетным записям и изоляции процесса, угрожающего безопасности.

Чтобы продемонстрировать служебные учетные записи, в этом обучающем руководстве будет использоваться веб-сервер Nginx как образец приложения.

Перед назначением конкретной служебной учетной записи для вашего приложения ее необходимо создать. Создайте новую учетную запись с именем <^>nginx-sa<^> в пространстве имен default:

				
					
kubectl create sa &lt;^&gt;nginx-sa&lt;^&gt;

Вы получите следующее:

				
					
[secondary_label Output]

serviceaccount/&lt;^&gt;nginx-sa&lt;^&gt; created

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

				
					
kubectl get sa

В результате вы получите список ваших служебных учетных записей:

				
					
[secondary_label Output]

NAME SECRETS AGE

default 1 22h

&lt;^&gt;nginx-sa&lt;^&gt; 1 80s

Теперь вы назначите эту роль для служебной учетной записи <^>nginx-sa<^>. В данном примере необходимо предоставить для <^>nginx-sa<^> те же разрешения, что и для пользователя sammy:

				
					
kubectl create rolebinding &lt;^&gt;nginx-sa-edit&lt;^&gt; \

 --clusterrole=edit \

 --serviceaccount=default:&lt;^&gt;nginx-sa&lt;^&gt; \

 --namespace=default

В результате будет получено следующее:

				
					
[secondary_label Output]

rolebinding.rbac.authorization.k8s.io/&lt;^&gt;nginx-sa-edit&lt;^&gt; created

Эта команда использует такой же формат, как для пользователя sammy, кроме флага --serviceaccount=default:nginx-sa, где вы назначаете служебную учетную запись <^>nginx-sa<^> в области имен default.

Убедитесь, что привязка ролей успешно выполнена при помощи этой команды:

				
					
kubectl get rolebinding

Результат будет выглядеть следующим образом:

				
					
[secondary_label Output]

NAME AGE

&lt;^&gt;nginx-sa-edit&lt;^&gt; 23s

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

В этом обучающем модуле в качестве образца приложения мы будем использовать под nginx. Создайте новый под и укажите служебную учетную запись <^>nginx-sa<^> с помощью следующей команды:

				
					
kubectl run nginx --image=nginx --port 80 --serviceaccount="&lt;^&gt;nginx-sa&lt;^&gt;"

Первая часть команды создает новый под на веб-сервере nginx на порту :80, а последняя часть --serviceaccount="<^>nginx-sa<^>" "<^>nginx-sa<^>" показывает, что данный под должен использовать служебную учетную запись <^>nginx-sa<^>, а не служебную учетную запись default.

Результат будет выглядеть примерно следующим образом:

				
					
[secondary_label Output]

deployment.apps/nginx created

Убедитесь, что новое приложение использует служебную учетную запись с помощью kubectl describe:

				
					
kubectl describe deployment nginx

В результате будет выведено подробное описание параметров развертывания. В разделе Pod Template вы увидите примерно следующее:

				
					
[secondary_label Output]

...

Pod Template:

 Labels: run=nginx

 Service Account: &lt;^&gt;nginx-sa&lt;^&gt;

...

В этом разделе мы создали служебную учетную запись <^>nginx-sa<^> в пространстве имен default и назначили ее для веб-сервера nginx. Теперь вы можете контролировать разрешения nginx в реальном времени посредством изменения его роли, по мере необходимости. Также вы можете группировать приложения посредством назначения одной служебной учетной записи для каждого из них и последующего внесения массовых изменений в разрешения. Наконец, вы можете изолировать критические приложения посредством назначения для них уникальной служебной учетной записи.

В целом, смысл назначения ролей для ваших приложений/развертываний состоит в отладке разрешений. В реальной производственной среде может быть установлено несколько развертываний, требующих различных разрешений — от «только для чтения» до полных административных прав. Использование RBAC обеспечивает гибкость для ограничения доступа к кластеру, по мере необходимости.

Далее вы настроите контроллеры допуска для контроля ресурсов и защиты от атак, вызывающих нехватку ресурсов.

Шаг 4 — Настройка контроллеров допуска

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

Результаты проверки аутентификации или разрешения являются булевыми величинами, разрешающими или отклоняющими запрос, а контроллеры допуска могут быть значительно более разнообразными. Контроллеры допуска могут подтверждать запросы таким же образом, как аутентификация, но также могут *изменять* запросы и объекты перед их допуском.

На данном шаге мы будем использовать контроллеры допуска ResourceQuota и LimitRange допуска для защиты кластера посредством изменения запросов, которые могут способствовать возникновению нехватки ресурсов или DoS-атак. Контроллер допуска ResourceQuota позволяет администраторам ограничивать вычислительные ресурсы, ресурсы хранения, а также количество любых объектов в пространстве имен, а контроллер допуска LimitRange ограничивает количество ресурсов, используемых контейнерами. При совместном использовании этих двух контроллеров допуска ваш кластер будет защищен от атак, приводящих к недоступности ресурсов.

Чтобы продемонстрировать работу ResourceQuota, зададим несколько ограничений в пространстве имен default. Начнем с создания нового файла объекта ResourceQuota:

				
					
nano &lt;^&gt;resource-quota-default&lt;^&gt;.yaml

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

				
					
[label resource-quota-default.yaml]

apiVersion: v1

kind: ResourceQuota

metadata:

 name: &lt;^&gt;resource-quota-default&lt;^&gt;

spec:

 hard:

 pods: "&lt;^&gt;2&lt;^&gt;"

 requests.cpu: "&lt;^&gt;500m&lt;^&gt;"

 requests.memory: &lt;^&gt;1Gi&lt;^&gt;

 limits.cpu: "&lt;^&gt;1000m&lt;^&gt;"

 limits.memory: &lt;^&gt;2Gi&lt;^&gt;

 configmaps: "&lt;^&gt;5&lt;^&gt;"

 persistentvolumeclaims: "&lt;^&gt;2&lt;^&gt;"

 replicationcontrollers: "&lt;^&gt;10&lt;^&gt;"

 secrets: "&lt;^&gt;3&lt;^&gt;"

 services: "&lt;^&gt;4&lt;^&gt;"

 services.loadbalancers: "&lt;^&gt;2&lt;^&gt;"

В этом определении используется ключевое слово hard для определения жестких ограничений — например, максимальное количество подов, карт configmaps, объектов PersistentVolumeClaims, контроллеров ReplicationControllers, объектов secrets, сервисов services и типов loadbalancers. В результате также устанавливаются ограничения вычислительных ресурсов:

  • requests.cpu, устанавливающий максимальное значение ЦП запросов в *milliCPU*, или одну тысячную ядра ЦП.
  • requests.memory, устанавливающий максимальное значение памяти запросов в байтах.
  • limits.cpu, устанавливающий максимальное значение ЦП предельных значений в milliCPU.
  • limits.memory, устанавливающий максимальное значение памяти предельных значений в байтах.

Сохраните и закройте файл.

Теперь создайте объект в пространстве имен при помощи следующей команды:

				
					
kubectl create -f &lt;^&gt;resource-quota-default.yaml&lt;^&gt; --namespace=default

В результате вы получите следующее:

				
					
[secondary_label Output]

resourcequota/&lt;^&gt;resource-quota-default&lt;^&gt; created

Обратите внимание, что вы используете флаг -f для указания в Kubernetes места расположения файла ResourceQuota и флаг --namespace для указания, в каком пространстве будет обновлено пространство имен.

После создания объекта ваш файл ResourceQuota будет активен. Вы можете проверить квоты пространств имен default с помощью describe quota:

				
					
kubectl describe quota --namespace=default

Результат будет выглядеть примерно так, с жесткими ограничениями, которые вы задали в файле <^>resource-quota-default<^>.yaml:

				
					
[secondary_label Output]

Name: &lt;^&gt;resource-quota-default&lt;^&gt;

Namespace: default

Resource Used Hard

-------- ---- ----

configmaps 0 &lt;^&gt;5&lt;^&gt;

limits.cpu 0 &lt;^&gt;1&lt;^&gt;

limits.memory 0 &lt;^&gt;2Gi&lt;^&gt;

persistentvolumeclaims 0 &lt;^&gt;2&lt;^&gt;

pods 1 &lt;^&gt;2&lt;^&gt;

replicationcontrollers 0 &lt;^&gt;10&lt;^&gt;

requests.cpu 0 &lt;^&gt;500m&lt;^&gt;

requests.memory 0 &lt;^&gt;1Gi&lt;^&gt;

secrets 2 &lt;^&gt;3&lt;^&gt;

services 1 &lt;^&gt;4&lt;^&gt;

services.loadbalancers 0 &lt;^&gt;2&lt;^&gt;

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

Если вам потребуется изменить определенный файл ResourceQuota, обновите соответствующий файл .yaml и примените изменения с помощью следующей команды:

				
					
kubectl apply -f &lt;^&gt;resource-quota-default&lt;^&gt;.yaml --namespace=default

Дополнительную информацию по контроллеру допуска ResourceQuota можно найти в официальной документации.

После настройки вашего ResourceQuota вы перейдете к настройке контроллера допуска LimitRange. Аналогично тому, как ResourceQuota ограничивает пространства имен, LimitRange обеспечивает ограничения, заданные посредством подтверждения контейнеров и их изменения.

Как и ранее, необходимо начать с создания файла объекта:

				
					
nano &lt;^&gt;limit-range-default&lt;^&gt;.yaml

Теперь вы можете использовать объект LimitRange для ограничения использования ресурсов, по мере необходимости. Добавьте следующее содержимое в качестве образца типичного случая использования:

				
					
[label limit-ranges-default.yaml]

apiVersion: v1

kind: LimitRange

metadata:

 name: &lt;^&gt;limit-range-default&lt;^&gt;

spec:

 limits:

 - max:

 cpu: "&lt;^&gt;400m&lt;^&gt;"

 memory: "&lt;^&gt;1Gi&lt;^&gt;"

 min:

 cpu: "&lt;^&gt;100m&lt;^&gt;"

 memory: "&lt;^&gt;100Mi&lt;^&gt;"

 default:

 cpu: "&lt;^&gt;250m&lt;^&gt;"

 memory: "&lt;^&gt;800Mi&lt;^&gt;"

 defaultRequest:

 cpu: "&lt;^&gt;150m&lt;^&gt;"

 memory: "&lt;^&gt;256Mi&lt;^&gt;"

 type: Container

Шаблонные значения, используемые в <^>limit-ranges-default<^>.yaml , ограничивают память контейнера максимальным значением 1Gi и ограничивают загрузку ЦП максимальным значением 400m — метрический эквивалент 400 milliCPU в Kubernetes, что означает, что контейнер ограничен использованием почти половины его ядра.

Далее, разверните объект для сервера API с помощью следующей команды:

				
					
kubectl create -f &lt;^&gt;limit-range-default&lt;^&gt;.yaml --namespace=default

Результат будет выглядеть следующим образом:

				
					
[secondary_label Output]

limitrange/&lt;^&gt;limit-range-default&lt;^&gt; created

Теперь вы можете проверить новые пределы с помощью следующей команды:

				
					
kubectl describe limits --namespace=default

Результат будет выглядеть примерно следующим образом:

				
					
[secondary_label Output]

Name: &lt;^&gt;limit-range-default&lt;^&gt;

Namespace: default

Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio

---- -------- --- --- --------------- ------------- -----------------------

Container cpu &lt;^&gt;100&lt;^&gt;m &lt;^&gt;400&lt;^&gt;m &lt;^&gt;150&lt;^&gt;m &lt;^&gt;250&lt;^&gt;m -

Container memory &lt;^&gt;100&lt;^&gt;Mi &lt;^&gt;1&lt;^&gt;Gi &lt;^&gt;256&lt;^&gt;Mi &lt;^&gt;800&lt;^&gt;Mi -

Чтобы увидеть LimitRanger в действии, разверните стандартный контейнер nginx с помощью следующей команды:

				
					
kubectl run nginx --image=nginx --port=80 --restart=Never

Результат будет выглядеть следующим образом:

				
					
[secondary_label Output]

pod/nginx created

Проверьте, как контроллер допуска изменил контейнер, с помощью следующей команды:

				
					
kubectl get pod nginx -o yaml

В результате будет получено много строк результатов. Посмотрите раздел спецификаций контейнера, чтобы узнать ограничения ресурсов, указанные контроллером допуска LimitRange:

				
					
[secondary_label Output]

...

spec:

 containers:

 - image: nginx

 imagePullPolicy: IfNotPresent

 name: nginx

 ports:

 - containerPort: 80

 protocol: TCP

 &lt;^&gt;resources:&lt;^&gt;

 &lt;^&gt;limits:&lt;^&gt;

 &lt;^&gt;cpu: 250m&lt;^&gt;

 &lt;^&gt;memory: 800Mi&lt;^&gt;

 &lt;^&gt;requests:&lt;^&gt;

 &lt;^&gt;cpu: 150m&lt;^&gt;

 &lt;^&gt;memory: 256Mi&lt;^&gt;

...

Это будет выглядеть примерно так, как если бы вы декларировали вручную ресурсы и запросы в спецификации контейнера.

На данном шаге вы использовали контроллеры допуска ResourceQuota и LimitRange для защиты от нападений злоумышленников на ресурсы вашего кластера. Дополнительную информацию по контроллеру допуска LimitRange можно найти в официальной документации.

Заключение

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

Если вы хотите узнать больше о Kubernetes, ознакомьтесь с нашей страницей ресурсов Kubernetes или посмотрите наш самостоятельный обучающий модуль «Kubernetes для разработчиков широкого профиля».