Первичная настройка
С помощью этого рецепта вы научитесь выполнять базовую настройку кластера Stackland после инсталляции — она повысит безопасность и удобство работы.
Создание учетной записи администратора
Ниже собран набор действий, которые пригодятся для дальнейшей работы с кластером.
Шаг 1. Создание пользователя
Не используйте учетную запись admin@stackland для повседневной работы. После первого входа в консоль управления сразу создайте персонализированную учетную запись администратора.
Примечание
Создание локального пользователя доступно только через консоль управления.
-
В консоли управления перейдите в раздел Пользователи и группы.
-
На вкладке Пользователи нажмите Создать пользователя.
-
Укажите имя пользователя.
-
Задайте временный пароль.
-
Активируйте учетную запись (по умолчанию новая учетная запись не активна).
-
Нажмите Создать.
При первом входе пользователю потребуется изменить временный пароль.

Шаг 2. Назначение прав
Необходимые права можно выдать двумя способами: напрямую пользователю через AccessBinding или RoleBinding, либо через группу, у которой уже есть нужные права.
Совет
Права лучше выдавать через группы, а не напрямую пользователю. Так проще масштабировать доступ при большом количестве пользователей, ниже вероятность ошибок и выше прозрачность.
Для выдачи административных прав подойдет группа stackland-cluster-admins. Она создается автоматически при установке Stackland и уже имеет роль admin на уровне кластера.
Примечание
Управление членством в группах доступно только через консоль управления.
Чтобы добавить пользователя в группу:
-
В консоли управления перейдите в раздел Пользователи и группы.
-
На вкладке Группы выберите
stackland-cluster-admins. -
Нажмите Добавить участника.
-
Выберите пользователей, которых нужно добавить в группу.
-
Нажмите Добавить.

После этих шагов пользователь получит административные права на уровне кластера — они наследуются через группу.
Настройка Policy Manager
-
Policy Manager объединяет инструменты, которые проверяют ресурсы Kubernetes на соответствие политикам и генерируют отчеты. В него входят пресеты политик, которые проверяют ресурсы на соответствие Pod Security Standards (PSS).
Подробнее о компоненте — в статье Policy Manager.
-
PSS — это стандарт Kubernetes, который определяет три уровня безопасности подов: Privileged, Baseline и Restricted. В Stackland можно выбрать два из них — Baseline и Restricted.
Подробнее о PSS — на сайте Kubernetes
.
По умолчанию после установки Stackland включен пресет Baseline — это базовая защита от известных эскалаций привилегий, которая подходит для большинства приложений. Для повышения безопасности рекомендуется дополнительно активировать пресет Restricted: он следует принципу наименьших привилегий.
Активация пресета Restricted
Включить Restricted можно двумя способами — через консоль управления и с помощью CLI.
-
В левом меню выберите Политики безопасности.
-
Перейдите на вкладку Настройки.
-
В разделе Kyverno отметьте оба пресета: Baseline и Restricted — изменения применятся автоматически.

-
Создайте файл
clusterpolicyset.yaml:apiVersion: policy.stackland.yandex.cloud/v1alpha1 kind: ClusterPolicySet metadata: name: stackland-policies spec: engines: kyverno: presets: - baseline - restricted -
Примените манифест:
kubectl apply -f clusterpolicyset.yaml
Включение и настройка Secrets Store
Secrets Store — компонент для безопасного хранения и доставки секретов в приложения: паролей, токенов, ключей API.
Примечание
По умолчанию после установки Stackland компонент Secrets Store выключен, и его нужно включить вручную.
Включение Secrets Store
Включить Secrets Store можно двумя способами.
-
В левом меню выберите Компоненты.
-
Активируйте компонент Secrets Store.
-
Подтвердите активацию.
-
Откройте ресурс
SecretsStoreConfigдля редактирования. Он управляет всеми настройками компонента.kubectl edit secretsstoreconfigs main -
Установите для параметра
enabledзначениеtrue.
Чтобы проверить, что компонент включился, убедитесь, что появилось пространство имен stackland-secrets-store и ресурсы в нем.
Получение доступа к Secrets Store
Примечание
Интерфейс и доступ к API Secrets Store по умолчанию выключены.
Откройте ресурс SecretsStoreConfig для редактирования.
-
Чтобы открыть доступ к API Secrets Store извне кластера, установите флаг
server.ingress.enabled = true. -
Чтобы открыть доступ к интерфейсу Secrets Store извне кластера, установите флаги
server.ingress.enabled = trueиui.enabled = true.
Интерфейс и API станут доступны по адресу https://secrets.sys.<домен кластера>. Если ui.enabled = true, а server.ingress.enabled = false, то доступ к интерфейсу будет только внутри кластера.
Root-токен для доступа к API или входа в интерфейс можно взять из секрета openbao-root-token в пространстве имен stackland-secrets-store:
kubectl get secret openbao-root-token -n stackland-secrets-store -o jsonpath='{.data.token}' | base64 -d
Выпуск сертификата для публичных сервисов
Если планируется публикация веб-сервисов в интернете, для их корректной работы в браузерах нужны доверенные TLS-сертификаты.
Важно
Самоподписанные сертификаты, которые Stackland использует по умолчанию, будут вызывать в браузере предупреждение безопасности.
Выпустить доверенный сертификат можно с помощью компонента Certificate Manager через эмитент Let's Encrypt. Порядок действий:
-
Включите эмитент Let's Encrypt. По умолчанию эмитент Let's Encrypt HTTP01 выключен и требует настройки. Отредактируйте глобальный ресурс
CertificateManagerConfig— блокclusterIssuersдолжен выглядеть так:clusterIssuers: letsencryptHttp01: enabled: true # Включить поддержку Let's Encrypt HTTP01 email: your-email@example.com # Действительный адрес электронной почты, на который будут приходить уведомления Let's Encrypt -
Создайте ресурс
Certificate.apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: my-app-tls namespace: <пространство_имен_приложения> spec: secretName: my-app-tls-secret issuerRef: name: stackland-letsencrypt kind: ClusterIssuer dnsNames: - app.example.com-
secretName— имя секрета, в который будут сохранены выпущенный сертификат и приватный ключ; -
issuerRef.name— используемый эмитентstackland-letsencrypt; -
dnsNames— список доменов, для которых выпускается сертификат.
-
-
После создания ресурса
Certificateкомпонент Certificate Manager автоматически создает Ingress в указанном пространстве имен для прохождения проверки и размещает по нему токенhttp://app.example.com/.well-known/acme-challenge/<токен>.Важно
Let's Encrypt проверяет, что токен доступен по этому URL. Поэтому убедитесь, что домен, для которого выпускается сертификат, разрешается из интернета. Трафик должен приходить на IP-адрес Ingress-контроллера Stackland, выбранного для эмитента.
kubectl get ingress -n default NAME CLASS HOSTS ADDRESS PORTS AGE cm-acme-http-solver-8h9b5 stackland-default app.example.com 172.19.11.72 80 35m -
После прохождения проверки сертификат будет выпущен и помещен в указанный ранее секрет
my-app-tls-secret.
Настройка мониторинга
В Stackland по умолчанию настроен набор алертов. Чтобы получать их, настройте канал уведомлений.
Настройка SMTP для Alertmanager
Alertmanager в Stackland настраивается через ресурс AlertmanagerConfig в пространстве имен stackland-monitoring. Этот ресурс описывает получателей, правила группировки и маршрутизации алертов.
-
Для безопасного хранения пароля от SMTP создайте секрет Kubernetes.
apiVersion: v1 kind: Secret metadata: name: smtp-secret namespace: stackland-monitoring type: Opaque stringData: password: "<ваш-smtp-пароль>" -
Создайте ресурс
AlertmanagerConfig.Подробнее о конфигурации Alertmanager — в документации Prometheus
.apiVersion: monitoring.coreos.com/v1alpha1 kind: AlertmanagerConfig metadata: name: stackland-email-config namespace: stackland-monitoring spec: route: groupBy: ['namespace', 'alertname'] groupWait: 30s groupInterval: 5m repeatInterval: 4h receiver: email-receiver routes: - matchers: - name: severity value: critical matchType: "=" receiver: email-receiver groupWait: 10s repeatInterval: 1h receivers: - name: email-receiver emailConfigs: - to: "admin@example.com" from: "infra@example.com" smarthost: "email-smtp.example.com:587" authUsername: "<smtp-username>" authPassword: name: smtp-secret key: password authIdentity: "<smtp-username>" requireTLS: true sendResolved: true headers: - key: Subject value: '[{{ .Status | toUpper }}] {{ .GroupLabels.alertname }}'После этого алерты начнут приходить, но только из пространства имен
stackland-monitoring. Чтобы получать алерты из всех пространств имен, добавьте в ресурсAlertmanagerпараметрalertmanagerConfigMatcherStrategy:kubectl patch alertmanager kube-monitoring -n stackland-monitoring --type='merge' -p '{"spec":{"alertmanagerConfigMatcherStrategy":{"type":"None"}}}'
Настройка срока хранения метрик Prometheus
По умолчанию Prometheus хранит метрики десять дней. При активной эксплуатации этого может быть недостаточно для анализа инцидентов.
-
Отредактируйте конфигурацию мониторинга.
kubectl edit monitoringconfigs main -
Измените параметры в секции
prometheus.spec: settings: prometheus: retention: 30d resources: limits: cpu: "2" memory: 4Gi requests: cpu: 200m memory: 800Mi
Важно
При увеличении срока хранения убедитесь, что на узлах достаточно свободного места.
Итоги
Вы выполнили первичную настройку кластера Stackland после инсталляции. Вот что важно запомнить:
-
Не используйте стандартную учетную запись
admin@stackland— создайте персонализированную. -
Настройка Policy Manager с пресетом Restricted усиливает контроль безопасности подов по стандарту Pod Security Standards.
-
Включение и настройка Secrets Store позволяют использовать единое хранилище секретов.
-
Выпуск доверенных сертификатов через Certificate Manager и Let's Encrypt дает веб-сервисам валидные TLS-сертификаты для безопасной публикации в интернете.
-
Для надежной эксплуатации можно подключить уведомления мониторинга о критических событиях и при необходимости увеличить срок хранения метрик Prometheus.