Sass

Sass

Sass is an extension of CSS adding features like nested rules, variables, mixins and class extensions. This enables developers to write structured, manageable and reusable CSS. Sass is compiled into standard CSS.

Как реализовать многопользовательскую SaaS в кластере Kubernetes

В этой статье конкретно показано, как реализовать многопользовательскую SaaS в кластере Kubernetes .

В примере из предыдущей статьи вымышленное автономное приложение Clyde's Clarinets было преобразовано в платформу SaaS под названием Instrument Resellers. Кларнеты Клайда предназначались для приобретения, ремонта и перепродажи бывших в употреблении кларнетов. Кларнеты Клайда превратились в платформу SaaS для реселлеров инструментов, чтобы любой бизнес мог приобретать, ремонтировать и перепродавать определенный тип инструментов. Таким образом, у реселлеров инструментов есть возможность поддерживать таких арендаторов, как духовые инструменты Бетти и саксофоны Сидни, а также кларнеты Клайда. (См. рис. 1.)

Автономное веб-приложение было преобразовано в платформу SaaS.

Рисунок 1: Автономное веб-приложение было преобразовано в платформу SaaS.

Внедрение SaaS в Kubernetes

В этой статье описывается, как использовать стандартные ресурсы Kubernetes — пространства имен, развертывания и службы — для создания различных арендаторов с использованием общей базы кода. В дополнение к стандартным ресурсам Kubernetes мы используем ресурс маршрута , предоставляемый Red Hat OpenShift , для создания общедоступного URL-адреса, который обеспечивает доступ к внутренней службе Kubernetes, представляющей конкретный экземпляр приложения клиента.

Демонстрационный код работает на платформе Red Hat OpenShift Container Platform, поскольку его ресурс маршрута обеспечивает простой способ создания доменного имени, обеспечивающего доступ к арендатору, работающему в кластере Kubernetes.

Эта статья относится к демонстрационному коду для реализации платформы SaaS Instrument Reseller. В следующей статье этой серии будет подробно описан код в демонстрационном проекте. На данный момент вы можете использовать демонстрационный проект в качестве вспомогательного материала для этой статьи.

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

В следующих разделах описано, как:

  • Используйте пространства имен Kubernetes для изоляции арендаторов на платформе SaaS.
  • Настройте развертывания Kubernetes, чтобы выделить логику приложения конкретному арендатору.
  • Привяжите базу данных к конкретному арендатору с помощью секрета Kubernetes.
  • Представьте логику приложения арендатора во внутренней сети в кластере с помощью службы Kubernetes.
  • Предоставьте доступ к арендатору за пределами кластера с помощью маршрута OpenShift.
  • Развертывайте и обновляйте логику клиентского приложения, используя базовый процесс непрерывной интеграции/непрерывного развертывания (CI/CD) .

Роль пространств имен Kubernetes в SaaS

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

Существует несколько возможных подходов к мультиарендности на платформе SaaS в Kubernetes:

  • Встраивайте изоляцию арендаторов прямо в логику одного приложения.
  • Запустите каждого арендатора в своем собственном кластере.
  • Запускайте каждого арендатора в собственном пространстве имен Kubernetes.

Платформа Instrument Reseller SaaS использует третий подход и использует пространства имен для поддержки нескольких арендаторов в одном кластере Kubernetes. В этом разделе объясняются детали концепции пространства имен.

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

В многопользовательской службе, использующей изоляцию пространства имен, каждый арендатор в кластере Kubernetes представлен определенным пространством имен. Ресурсы развертывания, службы и маршрута для конкретного арендатора создаются в пространстве имен этого арендатора. На рис. 2 показано, как пространства имен Kubernetes изолируют арендаторов на платформе SaaS Instrument Resellers.

Каждый арендатор имеет собственное пространство имен и URL-адрес, но запускает одно и то же приложение.

Рис. 2. У каждого арендатора есть собственное пространство имен и URL-адрес, но выполняется одно и то же приложение.

Хотя на рис. 2 показаны три арендатора, в этой статье показаны конфигурации только для Betty's Brass и Clyde's Clarinets, поскольку двух арендаторов достаточно, чтобы проиллюстрировать концепции, которые вам необходимо знать. В таблице 1 показаны файлы манифеста, в которых объявляются пространства имен Kubernetes для этих арендаторов. Два манифеста одинаковы, за исключением nameсвойств.

Таблица 1: Манифесты, объявляющие пространства имен.

Бетти Брасс

kind: Namespace
apiVersion: v1
metadata:
  name: bettysbrass
  labels:
    name: bettysbrass

Кларнеты Клайда

kind: Namespace
apiVersion: v1
metadata:
  name: clydesclarinets
  labels:
    name: clydesclarinets

Чтобы создать каждое пространство имен в кластере Kubernetes, выполните следующую команду, где <tenant_namespace>— имя файла манифеста, относящегося к арендатору:

$ kubectl apply -f <tenant_namespace>.yaml

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

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

Как упоминалось ранее, ключевой особенностью SaaS Instrument Reseller является то, что единая кодовая база может поддерживать любое количество арендаторов, желающих приобретать и перепродавать музыкальные инструменты. Логика приложения для каждого реселлера инструментов представлена ​​в SaaS ресурсом развертывания Kubernetes.

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

Таким образом, вы можете изменить количество реплик, поддерживаемых развертыванием во время работы приложения. Например, торговый посредник может начать с запуска трех модулей. Но через какое-то время нагрузка на тенанта такова, что pod'ов нужно больше. Чтобы создать больше модулей в развертывании, увеличьте значение, присвоенное replicasсвойству в файле манифеста, например, с трех до пяти. Затем повторно примените файл манифеста развертывания к кластеру. Когда нагрузки уменьшатся, вы можете уменьшить количество модулей в развертывании, изменив replicasпараметр в файле манифеста и таким же образом повторно применив измененный файл к кластеру.

Если модуль отключится, ресурс развертывания создаст замену, если это возможно.

Настройка развертываний

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

Например, в таблице 2 показаны манифесты, которые настраивают развертывание Kubernetes для Betty's Brass и Clyde's Clarinets. Единственными отличиями являются значения имен и инструментов.

Таблица 2: Манифесты настройки развертываний.

Бетти Брасс

apiVersion: apps/v1
kind: Deployment
metadata:
  name: instrumentreseller
  namespace: bettysbrass
  labels:
    app: instrumentreseller
spec:
  replicas: 3
  selector:
    matchLabels:
      app: instrumentreseller
  template:
    metadata:
      labels:
        app: instrumentreseller
    spec:
      initContainers:
        - name: seeder
          image: quay.io/rhdevelopers/instrumentresellerseeder
          env:
            - name: RESELLER_DB_NAME
              value: "brass"
            - name: RESELLER_INSTRUMENT
              value: "brass"
            - name: SEEDER_COUNT
              value: "10"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
      containers:
        - name: instrumentreseller
          image: quay.io/rhdevelopers/instrumentreseller
          env:
            - name: RESELLER_NAME
              value: "Betty's Brass"
            - name: RESELLER_INSTRUMENT
              value: "brass"
            - name: RESELLER_DB_NAME
              value: "brass"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
          ports:
            - containerPort: 8088

Кларнеты Клайда

apiVersion: apps/v1
kind: Deployment
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
  labels:
    app: instrumentreseller
spec:
  replicas: 3
  selector:
    matchLabels:
      app: instrumentreseller
  template:
    metadata:
      labels:
        app: instrumentreseller
    spec:
      initContainers:
        - name: seeder
          image: quay.io/rhdevelopers/instrumentresellerseeder
          env:
            - name: RESELLER_DB_NAME
              value: "clarinets"
            - name: SEEDER_COUNT
              value: "10"
            - name: RESELLER_INSTRUMENT
              value: "clarinet"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
      containers:
        - name: instrumentreseller
          image: quay.io/rhdevelopers/instrumentreseller
          env:
            - name: RESELLER_NAME
              value: "Clyde's Clarinets"
            - name: RESELLER_INSTRUMENT
              value: "clarinet"
            - name: RESELLER_DB_NAME
              value: "clarinets"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
          ports:
            - containerPort: 8088

Ключевым моментом для понимания предыдущих примеров является то, что оба арендатора используют одни и те же образы контейнеров. В каждом арендаторе контейнер инициализации использует quay.io/rhdevelopers/instrumentresellerseeder образ, а основной контейнер — quay.io/rhdevelopers/instrumentreseller образ. Помните, что основной принцип множественной аренды на платформе SaaS заключается в том, что все арендаторы используют одну и ту же кодовую базу. Использование одними и теми же образами контейнеров несколькими арендаторами поддерживает этот базовый принцип.

Каждый арендатор на платформе SaaS привязывается к своей собственной базе данных. Эта база данных может существовать в кластере Kubernetes или быть внешней службой базы данных, определяемой URL-адресом. Часто информация об имени пользователя и пароле, необходимая для доступа к базе данных, будет частью URL-адреса.

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

Заполнение данных

Как кратко упоминалось ранее, модули в развертывании используют контейнеры инициализации в дополнение к стандартным контейнерам. Контейнер инициализации — это контейнер, который запускается перед основным контейнером. В случае SaaS Instrument Reseller контейнер инициализации реализует специальную функцию демонстрационного кода: заполнение данных.

Поскольку в демонстрации мы не работаем с реальными розничными продавцами, мы используем контейнер инициализации для заполнения базы данных экземпляра клиента случайными данными, характерными для типа инструмента, продаваемого торговым посредником. Цель заполнения данных в демонстрации — предоставить некоторые начальные данные для просмотра при первом использовании приложения. Betty's Brass будет заполнен данными о духовых инструментах. Кларнеты Клайда будут заполнены данными о кларнетах. Sidney's Saxophones будет заполнен данными, относящимися к саксофонам.

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

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

Предоставление учетных данных базы данных через Kubernetes Secrets

Секреты — это ресурс Kubernetes для безопасного предоставления конфиденциальной информации другим ресурсам.

В таблице 3 показаны конфигурации, объявляющие секрет с именем mongo-urlв двух разных пространствах имен: одно для духовых инструментов Бетти, а другое — для кларнетов Клайда.

Таблица 3: Манифесты настройки секретов.

Бетти Брасс

apiVersion: v1
kind: Secret
metadata:
  name: mongo-url
  namespace: bettysbrass
type: Opaque
stringData:
  url: <mongo-url-here>

Кларнеты Клайда

apiVersion: v1
kind: Secret
metadata:
  name: mongo-url
  namespace: clydesclarinets
type: Opaque
stringData:
  url: <mongo-url-here>

Обратите внимание, что каждый секрет назначается соответствующему пространству имен. Секрет, названный mongo-urlв честь Betty's Brass, назначается bettysbrassпространству имен. Секрет с тем же mongo-urlименем для кларнетов Клайда назначается clydesclarinetsпространству имен. Несмотря на то, что все секреты имеют одно и то же имя, они отличаются друг от друга, поскольку относятся к разным пространствам имен. Использование одного и того же имени среди ресурсов — одно из преимуществ использования пространств имен.

Предоставление логики приложения с помощью службы Kubernetes

После настройки секрета для каждого арендатора следующим шагом будет создание службы Kubernetes, которая предоставляет логику приложения внутренней сети Kubernetes на платформе SaaS. В таблице 4 показаны конфигурации для службы Kubernetes в Betty's Brass с использованием bettysbrassпространства имен и для Clyde's Clarinets с использованием clydesclarinetsпространства имен. Опять же, назначение каждой службы отдельному пространству имен обеспечивает изоляцию арендаторов.

Таблица 4: Манифесты настройки служб.

Бетти Брасс

apiVersion: v1
kind: Service
metadata:
  name: instrumentreseller
  namespace: bettysbrass
spec:
  selector:
    app: instrumentreseller
  ports:
    - protocol: TCP
      port: 8088
      targetPort: 8088

Кларнеты Клайда

apiVersion: v1
kind: Service
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
spec:
  selector:
    app: instrumentreseller
  ports:
    - protocol: TCP
      port: 8088
      targetPort: 8088

Предоставление арендатора за пределами кластера с использованием маршрута OpenShift

Последним шагом настройки является создание ресурса маршрута OpenShift, который публикует доменное имя, чтобы предоставить арендатору за пределами кластера Kubernetes. Манифесты в Таблице 5 объявляют маршруты OpenShift для Betty's Brass и Clyde's Clarinets. Каждый манифест использует пространство имен своего клиента, а также другой хост.

Таблица 5: Манифесты настройки маршрутов OpenShift.

Бетти Брасс

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: instrumentreseller
  namespace: bettysbrass
spec:
  host: bettysbrass.com
  port:
    targetPort: 8088
  to:
    kind: Service
    name: instrumentreseller

Кларнеты Клайда

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
spec:
  host: clydesclarinets.com
  port:
    targetPort: 8088
  to:
    kind: Service
    name: instrumentreseller

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

Объявление набора файлов манифеста для пространства имен Kubernetes, развертывания, секрета, службы и маршрута — это первые шаги к запуску арендатора в кластере Kubernetes. После создания файлов манифеста выполните следующую команду, чтобы запустить каждого арендатора в кластере Kubernetes, где <manifest_file>это имя файла манифеста для данного арендатора:

$ kubectl apply -f <manifest_file>.yaml

Предполагая правильную конфигурацию, клиент будет запущен и работает, используя всего несколько kubectlкоманд. Однако те из нас, кто потратил много времени на работу с Kubernetes, поняли, что слова «правильная конфигурация» могут означать часы, если не дни труда. Короче говоря, подключить все сложно. Ты должен быть осторожен.

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

Процесс выпуска CI/CD

Развертывание арендаторов на платформе SaaS сопряжено с различной степенью сложности. Вы можете выполнить ручное развертывание, в котором вы создаете образы контейнеров Linux для логики приложения платформы SaaS, а затем отправляете эти образы в реестр образов контейнеров, например Quay.io.

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

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

Только что описанный процесс показан на рисунке 3.

Ручное развертывание поддерживает несколько арендаторов, запустив для нас команду kubectl apply.

Рисунок 3: Развертывание вручную поддерживает несколько арендаторов, запустив для нас команду kubectl apply.

Развертывание вручную — это реальный способ работы с платформой SaaS для исследований и экспериментов. Но это нереально для сегодняшних производственных релизов, которые требуют автоматизации процесса.

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

Центральным элементом автоматизации выпуска является контроллер CI/CD, такой как Jenkins или OpenShift Pipelines . Контроллер CI/CD автоматизирует многие, если не все задачи, необходимые для передачи артефактов приложения из репозитория исходного кода в рабочую среду.

На рис. 4 показан пример процесса CI/CD, который обновляет платформу SaaS. Контроллер CI/CD выполняет работу по упаковке кода, готового к выпуску, в образ контейнера. Затем он помещает этот образ в реестр контейнеров и обновляет платформу SaaS новой версией образа.

Автоматизированный процесс CI/CD для многопользовательской платформы SaaS использует контроллер CI/CD на нескольких этапах.

Рис. 4. Автоматизированный процесс CI/CD для многопользовательской платформы SaaS использует контроллер CI/CD на нескольких этапах.

Пронумерованные шаги на рисунке 4:

  1. Разработчик обновляет код и фиксирует обновленную работу в ветке dev в репозитории исходного кода.
  2. Группа обеспечения качества (Q/A) передает код из ветки разработки в ветку Q/A и запускает модульные тесты. Если тесты пройдены, Q/A выполняет интеграционное тестирование. После успешного выполнения Q/A уведомляет группу управления выпуском о том, что новая версия кода готова для эскалации в основную ветвь репозитория исходного кода.
  3. Управление выпуском объединяет код в основную ветку.
  4. Управление выпуском обновляет файлы манифеста Kubernetes, добавляя тег новой версии образа контейнера, связанного с предполагаемым выпуском. Обновленные файлы фиксируются в репозитории файлов манифеста.
  5. После успешного слияния исходного кода и файлов манифеста контроллер CI/CD уведомляется посредством автоматизации о том, что код готов к упаковке в образ контейнера и развертыванию в реестре образов контейнеров, таком как Quay.io.
  6. Контроллер CI/CD получает обновленный код из репозитория исходного кода и создает обновленный образ контейнера из файла Containerfile , хранящегося в репозитории вместе с исходным кодом приложения.
  7. Контроллер CI/CD отправляет обновленный образ контейнера в репозиторий образов контейнеров.
  8. Контроллер CI/CD получает обновленные файлы манифеста для соответствующих арендаторов из репозитория файлов манифеста и выполняет kubectl applyописанную ранее команду, чтобы обновить модули, работающие в кластере Kubernetes, с помощью образа контейнера с последней версией кода приложения.

Имейте в виду, что процессы выпуска обычно различаются в разных организациях. Редко существует универсальный подход к автоматизированным выпускам с использованием контроллера CI/CD. Этот пример — один из многих возможных.

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

Kubernetes поддерживает масштабируемую многопользовательскую SaaS.

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

Логика приложения, общая для всех арендаторов, инкапсулируется в образы контейнеров, которые хранятся в реестре контейнеров. Образ загружается в кластер в соответствии с информацией о конфигурации, установленной в файле манифеста развертывания для данного арендатора. Наконец, выпуски производственного уровня автоматизируются с помощью контроллера CI/CD.

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

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

Ссылка: https://developers.redhat.com/articles/2022/08/12/implement-multitenant-saas-kubernetes#kubernetes_supports_scalable_multitenant_saas

#sass #kubernetes 

Как реализовать многопользовательскую SaaS в кластере Kubernetes
井上  康弘

井上 康弘

1660386389

如何在 Kubernetes 集群中實現多租戶 SaaS

本文具體演示瞭如何在Kubernetes集群中實現多租戶 SaaS。

上一篇文章中的示例將名為 Clyde's Clarinets 的虛構獨立應用程序轉換為名為 Instrument Resellers 的 SaaS 平台。克萊德單簧管的目的是收購、翻新和轉售二手單簧管。Clyde's Clarinets 演變為 Instrument Resellers SaaS 平台,因此任何企業都可以購買、翻新和轉售特定類型的樂器。因此,樂器經銷商有能力為 Betty's Brass 和 Sidney's Saxophones 以及 Clyde's Clarinets 等租戶提供支持。(參見圖 1。)

一個獨立的 Web 應用程序被轉換為一個 SaaS 平台。

圖 1:將獨立 Web 應用程序轉換為 SaaS 平台。

在 Kubernetes 上實施 SaaS

本文介紹如何使用標準 Kubernetes 資源(命名空間、部署和服務)來使用通用代碼庫創建不同的租戶。除了標準的 Kubernetes 資源外,我們還使用Red Hat OpenShift提供的路由資源來創建一個公共 URL,該 URL 允許訪問代表特定租戶應用程序實例的內部 Kubernetes 服務。

演示代碼在 Red Hat OpenShift 容器平台上運行,因為它的路由資源提供了一種創建域名的簡單方法,該域名提供對在 Kubernetes 集群中運行的租戶的訪問。

本文參考了實現 Instrument Reseller SaaS 平台的演示代碼。本系列後續文章將詳細介紹演示項目中的代碼。目前,您可以將演示項目用作本文的支持參考。

請注意,為了從閱讀本文中獲得全部好處,您需要了解容器和 Kubernetes,尤其是圍繞 Kubernetes pod部署Secrets服務的目的和使用。此外,您需要有使用 Kubernetes 的kubectl客戶端的經驗。此外,您應該習慣於使用清單(又名配置)文件創建 Kubernetes 資源。

以下部分介紹瞭如何:

  • 使用 Kubernetes 命名空間來隔離 SaaS 平台中的租戶。
  • 配置 Kubernetes 部署以將應用程序邏輯專用於特定租戶。
  • 使用 Kubernetes Secret 將數據庫綁定到特定租戶。
  • 使用 Kubernetes 服務將租戶的應用程序邏輯呈現給集群中的內部網絡。
  • 使用 OpenShift 路由將租戶暴露在集群之外。
  • 使用基本的持續集成/持續部署 (CI/CD)流程部署和更新租戶應用程序邏輯。

Kubernetes 命名空間在 SaaS 中的作用

自首次發布以來,在單個集群中支持多個租戶一直是 Kubernetes 的基本功能。在 Kubernetes 下,許多租戶完全可以共享公共代碼庫的實例,同時彼此隔離運行。

在 Kubernetes 下的 SaaS 平台中有幾種可能的多租戶方法:

  • 將租戶隔離直接構建到單個應用程序的邏輯中。
  • 在自己的集群中運行每個租戶。
  • 在其自己的 Kubernetes 命名空間中運行每個租戶。

Instrument Reseller SaaS 平台採用第三種方法,並使用命名空間來支持單個 Kubernetes 集群中的多個租戶。本節解釋命名空間概念的細節。

顧名思義,命名空間創建了一個可以強加於其他資源的操作邊界。例如,您可以創建一個名為 的命名空間foo,然後在該命名空間下創建其他資源,例如 pod 和服務foo。這些資源只知道foo命名空間中的其他資源。該命名空間之外的資源無法訪問該命名空間內的資源。

在使用命名空間隔離的多租戶服務中,Kubernetes 集群中的每個租戶都由一個特定的命名空間表示。特定租戶的部署、服務和路由資源是在該租戶的命名空間中創建的。圖 2 說明了 Kubernetes 命名空間如何隔離 Instrument Resellers SaaS 平台中的租戶。

每個租戶都有自己的命名空間和 URL,但運行相同的應用程序。

圖 2:每個租戶都有自己的命名空間和 URL,但運行相同的應用程序。

儘管圖 2 中顯示了三個租戶,但本文僅展示了 Betty's Brass 和 Clyde's Clarinets 的配置,因為兩個租戶足以說明您需要了解的概念。表 1 顯示了為這些租戶聲明 Kubernetes 命名空間的清單文件。name除了屬性之外,這兩個清單是相同的。

表 1:聲明命名空間的清單。

貝蒂的黃銅

kind: Namespace
apiVersion: v1
metadata:
  name: bettysbrass
  labels:
    name: bettysbrass

克萊德的單簧管

kind: Namespace
apiVersion: v1
metadata:
  name: clydesclarinets
  labels:
    name: clydesclarinets

要在 Kubernetes 集群中創建每個命名空間,請運行以下命令,其中<tenant_namespace>是特定於租戶的清單文件的文件名:

$ kubectl apply -f <tenant_namespace>.yaml

使用 Kubernetes 部署在 SaaS 中創建和配置租戶

創建命名空間後,下一個任務是根據其分配的命名空間實現給定租戶的邏輯。此任務使用 Kubernetes 部署資源。

如前所述,樂器經銷商 SaaS 的一個關鍵特性是單個代碼庫可以支持任意數量的想要購買和轉售樂器的租戶。每個儀器經銷商的應用程序邏輯在 SaaS 中由 Kubernetes 部署資源表示。

一個部署控制一個或多個 pod副本。在部署下運行的 pod 數量由replicas部署資源清單文件中的屬性確定。

因此,您可以在應用程序運行時更改部署支持的副本數。例如,儀器經銷商可能從運行三個 pod 開始。但是,一段時間後,租戶的負載會增加,需要更多的 pod。要在部署中創建更多 pod,請將分配給replicas清單文件中屬性的值增加 - 例如,從 3 增加到 5。然後將部署的清單文件重新應用到集群。當負載減少時,您可以通過更改replicas清單文件中的設置並以相同的方式將更改的文件重新應用到集群來減少部署中的 pod 數量。

如果 pod 脫機,部署資源將在可能的情況下創建替換。

自定義部署

在我們的架構中,每個部署都應專用於單個儀器經銷商。您在該儀器經銷商的命名空間中創建部署,並通過 Kubernetes 清單中的環境變量定義該經銷商所需的參數,例如接受訂單的 URL。

例如,表 2 顯示了為 Betty's Brass 和 Clyde's Clarinets 配置 Kubernetes 部署的清單。唯一的區別是名稱和儀器的值。

表 2:清單配置部署。

貝蒂的黃銅

apiVersion: apps/v1
kind: Deployment
metadata:
  name: instrumentreseller
  namespace: bettysbrass
  labels:
    app: instrumentreseller
spec:
  replicas: 3
  selector:
    matchLabels:
      app: instrumentreseller
  template:
    metadata:
      labels:
        app: instrumentreseller
    spec:
      initContainers:
        - name: seeder
          image: quay.io/rhdevelopers/instrumentresellerseeder
          env:
            - name: RESELLER_DB_NAME
              value: "brass"
            - name: RESELLER_INSTRUMENT
              value: "brass"
            - name: SEEDER_COUNT
              value: "10"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
      containers:
        - name: instrumentreseller
          image: quay.io/rhdevelopers/instrumentreseller
          env:
            - name: RESELLER_NAME
              value: "Betty's Brass"
            - name: RESELLER_INSTRUMENT
              value: "brass"
            - name: RESELLER_DB_NAME
              value: "brass"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
          ports:
            - containerPort: 8088

克萊德的單簧管

apiVersion: apps/v1
kind: Deployment
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
  labels:
    app: instrumentreseller
spec:
  replicas: 3
  selector:
    matchLabels:
      app: instrumentreseller
  template:
    metadata:
      labels:
        app: instrumentreseller
    spec:
      initContainers:
        - name: seeder
          image: quay.io/rhdevelopers/instrumentresellerseeder
          env:
            - name: RESELLER_DB_NAME
              value: "clarinets"
            - name: SEEDER_COUNT
              value: "10"
            - name: RESELLER_INSTRUMENT
              value: "clarinet"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
      containers:
        - name: instrumentreseller
          image: quay.io/rhdevelopers/instrumentreseller
          env:
            - name: RESELLER_NAME
              value: "Clyde's Clarinets"
            - name: RESELLER_INSTRUMENT
              value: "clarinet"
            - name: RESELLER_DB_NAME
              value: "clarinets"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
          ports:
            - containerPort: 8088

了解前面示例的關鍵點是兩個租戶都使用相同的容器映像。在每個租戶中,init 容器使用quay.io/rhdevelopers/instrumentresellerseeder 鏡像,主容器使用quay.io/rhdevelopers/instrumentreseller 鏡像。請記住,SaaS 平台中多租戶的基本原則是所有租戶都使用相同的代碼庫。讓多個租戶使用相同的容器鏡像支持這一基本原則。

SaaS 平台中的每個租戶都綁定到自己的數據庫。該數據庫可能存在於 Kubernetes 集群中,或者是由 URL 定義的外部數據庫服務。通常,訪問數據庫所需的用戶名和密碼信息將是 URL 的一部分。

將用戶名和密碼信息放在集群中始終是一項冒險的工作。使 Kubernetes 集群中的 pod 可以使用用戶名/密碼信息的最佳實踐是使用稱為Secret的 Kubernetes 資源。我們將很快看到我們的應用程序如何將憑據傳遞到數據庫。

數據播種

如前所述,部署中的 Pod 除了使用標準容器外,還使用init容器。初始化容器是在主容器之前運行的容器。對於 Instrument Reseller SaaS,init 容器負責實現演示代碼的一個特殊功能:數據播種。

因為我們在演示中沒有與真正的零售商合作,所以我們使用 init 容器為租戶實例的數據庫提供隨機數據,這些數據特定於儀器經銷商銷售的儀器類型。演示中數據播種的目的是在第一次使用應用程序時提供一些初始數據以供查看。Betty's Brass 將播種有關銅管樂器的數據。克萊德的單簧管將播種有關單簧管的數據。Sidney's Saxophones 將植入特定於薩克斯管的數據。

使用容器中的數據播種模式為應用程序預填充數據會帶來冗餘播種的風險。如果只是在每個 pod 副本中運行 init 容器,則部署會在每個副本啟動時嘗試將數據播種到數據源。除非採取預防措施,否則將發生無根據的數據播種。

因此,數據播種器被編程到數據源並檢查是否存在預先存在的種子數據。如果種子數據已經在數據源中,則播種器退出而不添加更多數據。

通過 Kubernetes Secrets 提供數據庫憑證

Secrets 是一種 Kubernetes 資源,用於以安全的方式向其他資源提供敏感信息。

表 3 顯示了聲明mongo-url在兩個不同命名空間中命名的 Secret 的配置:一個用於 Betty's Brass,另一個用於 Clyde's Clarinets。

表 3:配置機密的清單。

貝蒂的黃銅

apiVersion: v1
kind: Secret
metadata:
  name: mongo-url
  namespace: bettysbrass
type: Opaque
stringData:
  url: <mongo-url-here>

克萊德的單簧管

apiVersion: v1
kind: Secret
metadata:
  name: mongo-url
  namespace: clydesclarinets
type: Opaque
stringData:
  url: <mongo-url-here>

請注意,每個 Secret 都分配給其各自的命名空間。以 Betty's Brass命名的 Secretmongo-url被分配給bettysbrass命名空間。克萊德單簧管的同名秘密mongo-url被分配給clydesclarinets命名空間。儘管每個 Secret 具有相同的名稱,但它們是不同的,因為它們被分配到不同的命名空間。在資源之間使用相同的名稱是使用命名空間的好處之一。

使用 Kubernetes 服務公開應用程序邏輯

為每個租戶配置 Secret 後,下一步是創建 Kubernetes 服務,將應用程序邏輯公開給 SaaS 平台內的內部 Kubernetes 網絡。表 4 顯示了 Betty's Brass 中使用命名空間的 Kubernetes 服務的配置bettysbrass,以及使用命名空間的 Clyde's Clarinets 的配置clydesclarinets。再一次,將每個服務分配給不同的命名空間使租戶保持隔離。

表 4:配置服務的清單。

貝蒂的黃銅

apiVersion: v1
kind: Service
metadata:
  name: instrumentreseller
  namespace: bettysbrass
spec:
  selector:
    app: instrumentreseller
  ports:
    - protocol: TCP
      port: 8088
      targetPort: 8088

克萊德的單簧管

apiVersion: v1
kind: Service
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
spec:
  selector:
    app: instrumentreseller
  ports:
    - protocol: TCP
      port: 8088
      targetPort: 8088

使用 OpenShift 路由將租戶暴露在集群之外

最後一個配置步驟是創建發布域名的 OpenShift 路由資源,以將租戶暴露在 Kubernetes 集群之外。表 5 中的清單聲明了 Betty's Brass 和 Clyde's Clarinets 的 OpenShift 路由。每個清單都使用其租戶的命名空間以及不同的主機。

表 5:配置 OpenShift 路由的清單。

貝蒂的黃銅

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: instrumentreseller
  namespace: bettysbrass
spec:
  host: bettysbrass.com
  port:
    targetPort: 8088
  to:
    kind: Service
    name: instrumentreseller

克萊德的單簧管

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
spec:
  host: clydesclarinets.com
  port:
    targetPort: 8088
  to:
    kind: Service
    name: instrumentreseller

to路由通過每個清單文件底部的屬性知道要綁定到哪個服務。

為 Kubernetes 命名空間、部署、Secret、服務和路由聲明一組清單文件是讓租戶在 Kubernetes 集群中啟動和運行的第一步。創建清單文件後,執行以下命令以獲取在 Kubernetes 集群中運行的每個租戶,其中<manifest_file>是給定租戶的清單文件的名稱:

$ kubectl apply -f <manifest_file>.yaml

假設配置正確,您只需使用幾個kubectl命令即可啟動並運行租戶。然而,正如我們這些花費大量時間使用 Kubernetes 的人所了解的那樣,“正確配置”一詞可能意味著數小時甚至數天的勞動。簡而言之,把所有東西都連接起來很困難。你必須要小心。

因此,在結束本文時,我們將為我們的 SaaS 部署設計一個可以輕鬆自動化的部署流程。

CI/CD 發布流程

將租戶部署到 SaaS 平台具有不同程度的複雜性。您可以進行手動部署,為 SaaS 平台的應用程序邏輯創建 Linux 容器鏡像,然後將這些鏡像推送到容器鏡像註冊表,例如Quay.io。

然後,一旦所需的容器映像在註冊表上,創建清單文件,您將使用這些文件在運行 SaaS 平台的 Kubernetes 集群中實現 Kubernetes 部署資源。這些清單文件聲明將使用的應用程序容器映像。

創建清單文件後,運行kubectl apply上一節末尾附近顯示的命令以在集群中創建關聯的 Kubernetes 資源。

剛剛描述的過程如圖 3 所示。

手動部署支持多租戶,為我們運行一個 kubectl apply 命令。

圖 3:手動部署支持多個租戶,為我們運行 kubectl apply 命令。

手動部署是使用 SaaS 平台進行研究和實驗的可行方式。但對於今天要求自動化流程的生產版本來說,這是不現實的。

使用自動化特別適合擁有多個支持 SaaS 平台的團隊的組織。依靠電子郵件和團隊之間的口口相傳可能是有風險的。自動化有助於為發布過程帶來正式性。

發布自動化的核心是 CI/CD 控制器,例如JenkinsOpenShift Pipelines。CI/CD 控制器自動化了許多(如果不是全部)將應用程序的工件從源代碼存儲庫投入生產所需的任務。

圖 4 顯示了更新 SaaS 平台的 CI/CD 流程示例。CI/CD 控制器負責將準備發布的代碼打包到容器映像中。然後,它將該映像推送到容器註冊表並使用新版本的映像更新 SaaS 平台。

多租戶 SaaS 平台的自動化 CI/CD 流程使用 CI/CD 控制器執行多個步驟。

圖 4:多租戶 SaaS 平台的自動化 CI/CD 流程使用 CI/CD 控制器執行多個步驟。

圖 4 中編號的步驟是:

  1. 開發人員更新代碼並將更新的工作提交到源代碼存儲庫中的 dev 分支。
  2. 質量保證 (Q/A) 團隊將代碼從 dev 分支升級到 Q/A 分支並運行單元測試。如果測試通過,Q/A 將執行集成測試。成功執行後,Q/A 會通知發布管理團隊新版本的代碼已準備好升級到源代碼存儲庫的主分支。
  3. 發布管理將代碼合併到主分支中。
  4. 發布管理使用與預期發布關聯的容器映像的新版本標籤更新 Kubernetes 清單文件。更新的文件被提交到清單文件存儲庫。
  5. 成功合併源代碼和清單文件後,CI/CD 控制器會通過自動化通知代碼已準備好打包到容器映像中並部署到容器映像註冊表(例如 Quay.io)。
  6. CI/CD 控制器從源代碼存儲庫中獲取更新的代碼,並從存儲在存儲庫中的Containerfile以及應用程序源代碼生成更新的容器映像。
  7. CI/CD 控制器將更新的容器鏡像推送到容器鏡像存儲庫。
  8. CI/CD 控制器從清單文件存儲庫中獲取相關租戶的更新清單文件,並運行kubectl apply前面討論的命令,以使用具有最新版本應用程序代碼的容器映像更新 Kubernetes 集群中運行的 pod。

請記住,發布過程通常因組織而異。使用 CI/CD 控制器的自動化發布很少有一種萬能的方法。這個例子是許多可能性之一。

需要了解的重要一點是,當自動化 CI/CD 流程到位時,它會處理將代碼從發布分支獲取到生產中的多租戶 Kubernetes 集群的大部分詳細工作。發布任務各不相同,但通常許多細節都是通過 CI/CD 控制器中的腳本自動化處理的。除非面臨關鍵任務的緊急情況,否則發佈人員不會擺弄手動任務。相反,CI/CD 流程中的更改是通過更改自動化腳本來實現的。

Kubernetes 支持可擴展的多租戶 SaaS

如本文所示,在 Kubernetes 上託管多租戶 SaaS 平台非常簡單。只要平台租戶使用的通用代碼庫是通用的,實現就涉及到配置和部署命名空間、Secret、部署、服務和路由。除了路由之外,所有這些資源都內置在 Kubernetes 中。路由資源由 OpenShift 提供。

所有租戶共有的應用程序邏輯被封裝到存儲在容器註冊表中的容器鏡像中。根據給定租戶的部署清單文件中設置的配置信息,將映像下載到集群。最後,使用 CI/CD 控制器自動發布生產級版本。

大多數 SaaS 平台旨在用於一組特定的用例。每一個往往都是特別的。因此,平台將有自己的一套複雜性和需要適應的例外情況。儘管如此,使用 Kubernetes 實現一個 SaaS 平台比從頭開始構建一個平台要容易得多。Kubernetes 完成了大部分(如果不是全部)繁重的列表。

本文介紹了在 Kubernetes 集群中實現多租戶 SaaS 平台的基本概念和技術。本系列的下一篇文章將詳細介紹本文中使用的演示應用程序。那篇文章將描述如何在演示 SaaS 平台中對所有租戶使用的通用邏輯進行編程。本文還將介紹如何啟動演示項目並將其作為託管在 Kubernetes 集群中的多租戶 SaaS 平台運行。

鏈接:https ://developers.redhat.com/articles/2022/08/12/implement-multitenant-saas-kubernetes#kubernetes_supports_scalable_multitenant_saas

#sass #kubernetes 

如何在 Kubernetes 集群中實現多租戶 SaaS
Minh  Nguyet

Minh Nguyet

1660379160

Cách Triển Khai SaaS Nhiều đối Tượng Trong Một Cụm Kubernetes

Bài viết này trình bày một cách cụ thể cách triển khai SaaS nhiều đối tượng trong một cụm Kubernetes .

Ví dụ trong bài viết trước đã chuyển đổi một ứng dụng độc lập hư cấu có tên Clyde's Clarinets thành một nền tảng SaaS có tên là Instrument Resellers. Mục đích của Clarinets Clyde là mua lại, tân trang và bán lại clarinet đã qua sử dụng. Clyde's Clarinets đã phát triển thành nền tảng SaaS dành cho người bán lại thiết bị để bất kỳ doanh nghiệp nào cũng có thể mua, tân trang và bán lại một loại nhạc cụ cụ thể. Do đó, Đại lý bán nhạc cụ có khả năng hỗ trợ người thuê như Betty's Brass và Sidney's Saxophone cũng như Clyde's Clarinets. (Xem Hình 1.)

Một ứng dụng web độc lập đã được chuyển đổi thành nền tảng SaaS.

Hình 1: Một ứng dụng web độc lập đã được chuyển đổi thành nền tảng SaaS.

Triển khai SaaS trên Kubernetes

Bài viết này mô tả cách sử dụng tài nguyên Kubernetes tiêu chuẩn — không gian tên, triển khai và dịch vụ — để tạo các đối tượng thuê khác nhau bằng cách sử dụng cơ sở mã chung. Ngoài các tài nguyên Kubernetes tiêu chuẩn, chúng tôi sử dụng tài nguyên định tuyến do Red Hat OpenShift cung cấp để tạo một URL công khai cho phép truy cập vào dịch vụ Kubernetes nội bộ đại diện cho phiên bản ứng dụng cụ thể của đối tượng thuê.

Mã trình diễn chạy trên Red Hat OpenShift Container Platform vì tài nguyên định tuyến của nó cung cấp một cách dễ dàng để tạo tên miền cung cấp quyền truy cập cho đối tượng thuê chạy trong cụm Kubernetes.

Bài viết này đề cập đến mã trình diễn để triển khai nền tảng SaaS của người bán lại công cụ. Bài viết tiếp theo trong loạt bài này sẽ mô tả chi tiết mã trong dự án trình diễn. Hiện tại, bạn có thể sử dụng dự án trình diễn làm tài liệu tham khảo hỗ trợ cho bài viết này.

Xin lưu ý rằng để có được lợi ích đầy đủ từ việc đọc bài viết này, bạn cần phải hiểu về vùng chứa và Kubernetes, đặc biệt là về mục đích và việc sử dụng các nhóm Kubernetes , triển khai , Bí mậtdịch vụ . Ngoài ra, bạn cần có kinh nghiệm làm việc với ứng dụng khách kubectl cho Kubernetes. Ngoài ra, bạn sẽ cảm thấy thoải mái khi tạo tài nguyên Kubernetes bằng cách sử dụng tệp kê khai (hay còn gọi là cấu hình) .

Các phần sau đây mô tả cách:

  • Sử dụng không gian tên Kubernetes để cô lập người thuê trong nền tảng SaaS.
  • Định cấu hình các triển khai Kubernetes để cung cấp logic ứng dụng cho một đối tượng thuê cụ thể.
  • Liên kết cơ sở dữ liệu với một đối tượng thuê cụ thể bằng Bí mật Kubernetes.
  • Trình bày logic ứng dụng của người thuê cho mạng nội bộ trong cụm bằng dịch vụ Kubernetes.
  • Đưa người thuê ra bên ngoài cụm bằng cách sử dụng tuyến OpenShift.
  • Triển khai và cập nhật logic ứng dụng của đối tượng thuê bằng quy trình tích hợp liên tục / triển khai liên tục (CI / CD) cơ bản .

Vai trò của không gian tên Kubernetes trong SaaS

Hỗ trợ nhiều người thuê trong một cụm duy nhất đã là một tính năng cơ bản trong Kubernetes kể từ lần phát hành đầu tiên. Theo Kubernetes, nhiều người thuê hoàn toàn có thể chia sẻ các phiên bản của một cơ sở mã chung trong khi chạy tách biệt với nhau.

một số cách tiếp cận khả thi để mang thai hộ trong nền tảng SaaS dưới Kubernetes:

  • Xây dựng sự cô lập đối tượng thuê thành logic của một ứng dụng duy nhất.
  • Chạy từng đối tượng thuê trong cụm riêng của nó.
  • Chạy từng đối tượng thuê trong không gian tên Kubernetes của riêng nó.

Nền tảng SaaS dành cho người bán lại của Instrument sử dụng cách tiếp cận thứ ba và sử dụng không gian tên để hỗ trợ nhiều người thuê trong một cụm Kubernetes duy nhất. Phần này giải thích chi tiết về khái niệm không gian tên.

Không gian tên, như tên của nó, tạo ra một ranh giới hoạt động có thể được áp đặt cho các tài nguyên khác. Ví dụ: bạn có thể tạo một không gian tên được đặt tên foo, rồi tạo các tài nguyên khác như nhóm và dịch vụ trong fookhông gian tên đó. Các tài nguyên đó chỉ biết về các tài nguyên khác trong fookhông gian tên. Các tài nguyên bên ngoài không gian tên đó không có quyền truy cập vào các tài nguyên bên trong không gian tên.

Trong một dịch vụ nhiều đối tượng sử dụng cách ly không gian tên, mỗi đối tượng thuê trong cụm Kubernetes được đại diện bởi một không gian tên cụ thể. Tài nguyên triển khai, dịch vụ và định tuyến cho đối tượng thuê cụ thể được tạo trong không gian tên của đối tượng thuê đó. Hình 2 minh họa cách không gian tên Kubernetes cô lập người thuê trong nền tảng SaaS của nhà bán lại công cụ.

Mỗi đối tượng thuê có không gian tên và URL riêng, nhưng chạy cùng một ứng dụng.

Hình 2: Mỗi đối tượng thuê có không gian tên và URL riêng, nhưng chạy cùng một ứng dụng.

Mặc dù ba người thuê được hiển thị trong Hình 2, bài viết này chỉ ra các cấu hình chỉ dành cho Betty's Brass và Clyde's Clarinets vì hai người thuê đủ để minh họa các khái niệm bạn cần biết. Bảng 1 cho thấy các tệp kê khai khai báo không gian tên Kubernetes cho những người thuê này. Hai biểu hiện giống nhau ngoại trừ các namethuộc tính.

Bảng 1: Các thao tác khai báo không gian tên.

Betty's Brass

kind: Namespace
apiVersion: v1
metadata:
  name: bettysbrass
  labels:
    name: bettysbrass

Clyde's Clarinets

kind: Namespace
apiVersion: v1
metadata:
  name: clydesclarinets
  labels:
    name: clydesclarinets

Để tạo từng không gian tên trong cụm Kubernetes, hãy chạy lệnh sau, đâu <tenant_namespace>là tên tệp của tệp kê khai cụ thể cho đối tượng thuê:

$ kubectl apply -f <tenant_namespace>.yaml

Tạo và định cấu hình người thuê trong SaaS bằng cách sử dụng triển khai Kubernetes

Khi không gian tên được tạo, nhiệm vụ tiếp theo là thực hiện logic cho đối tượng thuê đã cho theo không gian tên được chỉ định của nó. Tác vụ này sử dụng tài nguyên triển khai Kubernetes.

Như đã đề cập trước đây, một tính năng chính của SaaS dành cho người bán lại nhạc cụ là một cơ sở mã duy nhất có thể hỗ trợ bất kỳ số lượng người thuê nào muốn mua và bán lại nhạc cụ. Logic ứng dụng cho mỗi đại lý bán lẻ thiết bị được trình bày trong SaaS bởi tài nguyên triển khai Kubernetes.

Việc triển khai kiểm soát một hoặc nhiều bản sao nhóm . Số lượng nhóm đang chạy trong một triển khai được xác định bởi thuộc replicastính trong tệp kê khai tài nguyên triển khai.

Do đó, bạn có thể thay đổi số lượng bản sao mà một triển khai hỗ trợ trong khi ứng dụng đang chạy. Ví dụ: một đại lý bán lại nhạc cụ có thể bắt đầu bằng cách chạy ba nhóm. Tuy nhiên, sau một thời gian, tải đối với người thuê đến mức cần nhiều nhóm hơn. Để tạo nhiều nhóm hơn trong triển khai, hãy tăng giá trị được gán cho thuộc replicastính trong tệp kê khai — ví dụ: từ ba lên năm. Sau đó, áp dụng lại tệp kê khai của triển khai cho cụm. Khi tải giảm, bạn có thể giảm số lượng nhóm trong triển khai bằng cách thay đổi replicascài đặt trong tệp kê khai và áp dụng lại tệp đã thay đổi vào cụm theo cách tương tự.

Nếu một nhóm chuyển sang chế độ ngoại tuyến, tài nguyên triển khai sẽ tạo ra một tài nguyên thay thế nếu có thể.

Tùy chỉnh triển khai

Trong kiến ​​trúc của chúng tôi, mỗi lần triển khai nên dành riêng cho một đại lý bán thiết bị duy nhất. Bạn tạo triển khai trong không gian tên của người bán lại công cụ đó và xác định các tham số mà người bán lại đó cần, chẳng hạn như URL nơi nó nhận đơn đặt hàng, thông qua các biến môi trường trong tệp kê khai Kubernetes.

Ví dụ: Bảng 2 cho thấy các bảng kê khai cấu hình việc triển khai Kubernetes cho Betty's Brass và Clyde's Clarinets. Sự khác biệt duy nhất là giá trị cho tên và nhạc cụ.

Bảng 2: Thao tác cấu hình các triển khai.

Betty's Brass

apiVersion: apps/v1
kind: Deployment
metadata:
  name: instrumentreseller
  namespace: bettysbrass
  labels:
    app: instrumentreseller
spec:
  replicas: 3
  selector:
    matchLabels:
      app: instrumentreseller
  template:
    metadata:
      labels:
        app: instrumentreseller
    spec:
      initContainers:
        - name: seeder
          image: quay.io/rhdevelopers/instrumentresellerseeder
          env:
            - name: RESELLER_DB_NAME
              value: "brass"
            - name: RESELLER_INSTRUMENT
              value: "brass"
            - name: SEEDER_COUNT
              value: "10"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
      containers:
        - name: instrumentreseller
          image: quay.io/rhdevelopers/instrumentreseller
          env:
            - name: RESELLER_NAME
              value: "Betty's Brass"
            - name: RESELLER_INSTRUMENT
              value: "brass"
            - name: RESELLER_DB_NAME
              value: "brass"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
          ports:
            - containerPort: 8088

Clyde's Clarinets

apiVersion: apps/v1
kind: Deployment
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
  labels:
    app: instrumentreseller
spec:
  replicas: 3
  selector:
    matchLabels:
      app: instrumentreseller
  template:
    metadata:
      labels:
        app: instrumentreseller
    spec:
      initContainers:
        - name: seeder
          image: quay.io/rhdevelopers/instrumentresellerseeder
          env:
            - name: RESELLER_DB_NAME
              value: "clarinets"
            - name: SEEDER_COUNT
              value: "10"
            - name: RESELLER_INSTRUMENT
              value: "clarinet"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
      containers:
        - name: instrumentreseller
          image: quay.io/rhdevelopers/instrumentreseller
          env:
            - name: RESELLER_NAME
              value: "Clyde's Clarinets"
            - name: RESELLER_INSTRUMENT
              value: "clarinet"
            - name: RESELLER_DB_NAME
              value: "clarinets"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
          ports:
            - containerPort: 8088

Một điểm chính cần hiểu về các ví dụ trước là cả hai người thuê đều đang sử dụng các hình ảnh vùng chứa giống nhau. Trong mọi đối tượng thuê, vùng chứa init sử dụng quay.io/rhdevelopers/instrumentresellerseeder hình ảnh và vùng chứa chính sử dụng quay.io/rhdevelopers/instrumentreseller hình ảnh. Hãy nhớ rằng, một nguyên tắc thiết yếu của việc thuê nhiều nhà trong nền tảng SaaS là ​​tất cả người thuê đều sử dụng cùng một cơ sở mã. Việc có nhiều người thuê sử dụng các hình ảnh vùng chứa giống nhau hỗ trợ nguyên tắc cơ bản này.

Mỗi đối tượng thuê trong nền tảng SaaS liên kết với cơ sở dữ liệu của riêng mình. Cơ sở dữ liệu đó có thể tồn tại trong cụm Kubernetes hoặc là một dịch vụ cơ sở dữ liệu bên ngoài được xác định bởi một URL. Thông thường, thông tin tên người dùng và mật khẩu cần thiết để truy cập cơ sở dữ liệu sẽ là một phần của URL.

Đưa thông tin tên người dùng và mật khẩu vào một cụm luôn là một công việc rủi ro. Phương pháp hay nhất để cung cấp thông tin tên người dùng / mật khẩu cho các nhóm trong một cụm Kubernetes là sử dụng tài nguyên Kubernetes được gọi là Bí mật . Chúng tôi sẽ xem cách ứng dụng của chúng tôi chuyển thông tin đăng nhập vào cơ sở dữ liệu ngay sau đây.

Hạt giống dữ liệu

Như đã đề cập ngắn gọn trước đó, các nhóm trong triển khai sử dụng các vùng chứa init ngoài các vùng chứa tiêu chuẩn. Vùng chứa init là vùng chứa chạy trước vùng chứa chính. Trong trường hợp của Instrument Reseller SaaS, init container thực hiện công việc triển khai một tính năng đặc biệt của mã trình diễn: data seeding.

Bởi vì chúng tôi không làm việc với các nhà bán lẻ thực trong bản demo, chúng tôi sử dụng vùng chứa init để tạo cơ sở dữ liệu của đối tượng thuê với dữ liệu ngẫu nhiên dành riêng cho loại công cụ được bán bởi người bán lại thiết bị. Mục đích của việc gieo dữ liệu trong bản demo là cung cấp một số dữ liệu ban đầu để xem khi ứng dụng được sử dụng lần đầu tiên. Betty's Brass sẽ được cung cấp dữ liệu về các nhạc cụ bằng đồng thau. Clyde's Clarinets sẽ được cung cấp dữ liệu về clarinet. Sidney's Saxophones sẽ được cung cấp dữ liệu dành riêng cho kèn saxophone.

Việc sử dụng mẫu gieo hạt dữ liệu trong vùng chứa để chuẩn bị trước dữ liệu cho một ứng dụng sẽ mở ra nguy cơ tạo hạt giống dư thừa. Nếu một người chỉ đơn giản chạy vùng chứa init trong mỗi bản sao nhóm, thì việc triển khai sẽ cố gắng truyền dữ liệu vào nguồn dữ liệu khi mỗi bản sao bắt đầu. Trừ khi thực hiện một biện pháp phòng ngừa, nếu không sẽ xảy ra việc truyền dữ liệu không chính đáng.

Do đó, data seeder được lập trình để đi ra ngoài nguồn dữ liệu và kiểm tra xem có tồn tại dữ liệu seed từ trước hay không. Nếu dữ liệu hạt giống đã có trong nguồn dữ liệu, trình tạo hạt giống sẽ thoát ra mà không cần thêm dữ liệu khác.

Cung cấp thông tin đăng nhập cơ sở dữ liệu thông qua Kubernetes Secrets

Bí mật là tài nguyên của Kubernetes để cung cấp thông tin nhạy cảm cho các tài nguyên khác một cách an toàn.

Bảng 3 cho thấy các cấu hình khai báo một Bí mật được đặt tên mongo-urltrong hai không gian tên khác nhau: một cho Betty's Brass và một cho Clyde's Clarinets.

Bảng 3: Các thao tác cấu hình Bí mật.

Betty's Brass

apiVersion: v1
kind: Secret
metadata:
  name: mongo-url
  namespace: bettysbrass
type: Opaque
stringData:
  url: <mongo-url-here>

Clyde's Clarinets

apiVersion: v1
kind: Secret
metadata:
  name: mongo-url
  namespace: clydesclarinets
type: Opaque
stringData:
  url: <mongo-url-here>

Lưu ý rằng mỗi Bí mật được gán cho không gian tên tương ứng của nó. Bí mật được đặt tên mongo-urlcho Betty's Brass được gán cho bettysbrasskhông gian tên. Bí mật có cùng mongo-urltên cho Clyde's Clarinets được gán cho clydesclarinetskhông gian tên. Mặc dù mỗi Bí mật có cùng tên, chúng vẫn khác biệt vì chúng được gán cho các không gian tên khác nhau. Sử dụng cùng một tên giữa các tài nguyên là một trong những lợi ích của việc sử dụng không gian tên.

Hiển thị logic ứng dụng bằng dịch vụ Kubernetes

Khi Bí mật được định cấu hình cho từng đối tượng thuê, bước tiếp theo là tạo dịch vụ Kubernetes để hiển thị logic ứng dụng cho mạng Kubernetes nội bộ trong nền tảng SaaS. Bảng 4 cho thấy các cấu hình cho dịch vụ Kubernetes trong Betty's Brass sử dụng bettysbrasskhông gian tên và cho Clarinets của Clyde sử dụng clydesclarinetskhông gian tên. Một lần nữa, việc chỉ định mỗi dịch vụ cho một không gian tên khác nhau sẽ giữ cho những người thuê nhà bị cô lập.

Bảng 4: Thao tác cấu hình các dịch vụ.

Betty's Brass

apiVersion: v1
kind: Service
metadata:
  name: instrumentreseller
  namespace: bettysbrass
spec:
  selector:
    app: instrumentreseller
  ports:
    - protocol: TCP
      port: 8088
      targetPort: 8088

Clyde's Clarinets

apiVersion: v1
kind: Service
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
spec:
  selector:
    app: instrumentreseller
  ports:
    - protocol: TCP
      port: 8088
      targetPort: 8088

Đưa đối tượng thuê ra bên ngoài cụm bằng cách sử dụng tuyến đường OpenShift

Bước cấu hình cuối cùng là tạo tài nguyên định tuyến OpenShift xuất bản tên miền để hiển thị đối tượng thuê bên ngoài cụm Kubernetes. Bảng kê khai trong Bảng 5 khai báo các tuyến OpenShift cho Betty's Brass và Clyde's Clarinets. Mỗi tệp kê khai sử dụng không gian tên của đối tượng thuê cũng như một máy chủ lưu trữ khác nhau.

Bảng 5: Các thao tác định cấu hình các tuyến OpenShift.

Betty's Brass

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: instrumentreseller
  namespace: bettysbrass
spec:
  host: bettysbrass.com
  port:
    targetPort: 8088
  to:
    kind: Service
    name: instrumentreseller

Clyde's Clarinets

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
spec:
  host: clydesclarinets.com
  port:
    targetPort: 8088
  to:
    kind: Service
    name: instrumentreseller

Tuyến biết dịch vụ nào cần liên kết thông qua tothuộc tính ở cuối mỗi tệp kê khai.

Khai báo một tập hợp các tệp kê khai cho không gian tên Kubernetes, triển khai, Bí mật, dịch vụ và tuyến đường là những bước đầu tiên để thiết lập và chạy một đối tượng thuê trong một cụm Kubernetes. Sau khi tệp kê khai được tạo, hãy thực thi lệnh sau để đưa từng đối tượng thuê chạy trong cụm Kubernetes, trong đó <manifest_file>tên của tệp kê khai cho đối tượng thuê đã cho:

$ kubectl apply -f <manifest_file>.yaml

Giả sử cấu hình phù hợp, bạn sẽ có một đối tượng thuê và chạy chỉ bằng một vài kubectllệnh. Tuy nhiên, như chúng ta, những người đã dành nhiều thời gian làm việc với Kubernetes đều hiểu rằng, từ "cấu hình phù hợp" có thể có nghĩa là hàng giờ nếu không phải là ngày lao động. Nói tóm lại, lên dây cót mọi thứ thật khó. Bạn phải cẩn thận đấy.

Vì vậy, để kết thúc bài viết này, chúng tôi sẽ đưa ra một quy trình triển khai để triển khai SaaS của chúng tôi có thể được tự động hóa dễ dàng.

Quy trình phát hành CI / CD

Việc triển khai người thuê vào một nền tảng SaaS đi kèm với các mức độ phức tạp khác nhau. Bạn có thể thực hiện triển khai thủ công trong đó bạn tạo các hình ảnh vùng chứa Linux cho logic ứng dụng của nền tảng SaaS và sau đó đẩy các hình ảnh đó ra một cơ quan đăng ký hình ảnh vùng chứa chẳng hạn như Quay.io.

Sau đó, khi các hình ảnh vùng chứa được yêu cầu có trong sổ đăng ký, hãy tạo tệp kê khai mà bạn sẽ sử dụng để nhận ra tài nguyên triển khai Kubernetes trong cụm Kubernetes mà nền tảng SaaS đang chạy. Các tệp kê khai này khai báo các hình ảnh vùng chứa ứng dụng sẽ được sử dụng.

Sau khi tạo tệp kê khai, hãy chạy kubectl applylệnh được hiển thị gần cuối phần trước để tạo tài nguyên Kubernetes được liên kết trong cụm.

Quá trình vừa được mô tả được thể hiện trong Hình 3.

Triển khai thủ công hỗ trợ nhiều người thuê, chạy lệnh áp dụng kubectl cho chúng tôi.

Hình 3: Triển khai thủ công hỗ trợ nhiều người thuê, chạy lệnh áp dụng kubectl cho chúng tôi.

Triển khai thủ công là một cách khả thi để làm việc với nền tảng SaaS cho nghiên cứu và thử nghiệm. Nhưng nó không thực tế đối với các bản phát hành sản xuất ngày nay, vốn yêu cầu tự động hóa quy trình.

Sử dụng tự động hóa đặc biệt thích hợp cho các tổ chức có một số nhóm hỗ trợ nền tảng SaaS. Dựa vào email và giao tiếp truyền miệng giữa các nhóm có thể gặp rủi ro. Tự động hóa giúp mang lại hình thức cho quá trình phát hành.

Trung tâm để phát hành tự động hóa là bộ điều khiển CI / CD như Jenkins hoặc OpenShift Pipelines . Bộ điều khiển CI / CD tự động hóa nhiều nếu không muốn nói là tất cả các tác vụ cần thiết để đưa các tạo tác của ứng dụng từ kho mã nguồn vào sản xuất.

Hình 4 cho thấy một ví dụ về quy trình CI / CD cập nhật nền tảng SaaS. Bộ điều khiển CI / CD thực hiện công việc đóng gói mã sẵn sàng để phát hành thành hình ảnh vùng chứa. Sau đó, nó đẩy hình ảnh đó vào sổ đăng ký vùng chứa và cập nhật nền tảng SaaS với phiên bản mới của hình ảnh.

Quy trình CI / CD tự động cho nền tảng SaaS nhiều đối tượng sử dụng bộ điều khiển CI / CD cho một số bước.

Hình 4: Quy trình CI / CD tự động cho nền tảng SaaS nhiều đối tượng sử dụng bộ điều khiển CI / CD cho một số bước.

Các bước được đánh số trong Hình 4 là:

  1. Nhà phát triển cập nhật mã và cam kết công việc cập nhật cho nhánh nhà phát triển trong kho mã nguồn.
  2. Nhóm đảm bảo chất lượng (Q / A) chuyển mã từ nhánh nhà phát triển sang nhánh Q / A và chạy các bài kiểm tra đơn vị. Nếu các bài kiểm tra vượt qua, Q / A sẽ thực hiện kiểm tra tích hợp. Sau khi thực thi thành công, Q / A thông báo cho nhóm quản lý phát hành rằng một phiên bản mã mới đã sẵn sàng để chuyển lên nhánh chính của kho mã nguồn.
  3. Quản lý phát hành hợp nhất mã vào nhánh chính.
  4. Quản lý bản phát hành cập nhật các tệp kê khai Kubernetes bằng thẻ phiên bản mới của hình ảnh vùng chứa được liên kết với bản phát hành dự định. Các tệp cập nhật được cam kết vào kho lưu trữ tệp kê khai.
  5. Sau khi hợp nhất thành công mã nguồn và tệp kê khai, bộ điều khiển CI / CD được thông báo thông qua tự động hóa rằng mã đã sẵn sàng để đóng gói thành hình ảnh vùng chứa và triển khai đến cơ quan đăng ký hình ảnh vùng chứa như Quay.io.
  6. Bộ điều khiển CI / CD lấy mã cập nhật từ kho mã nguồn và tạo hình ảnh vùng chứa được cập nhật từ Containerfile được lưu trữ trong kho cùng với mã nguồn ứng dụng.
  7. Bộ điều khiển CI / CD đẩy hình ảnh vùng chứa đã cập nhật vào kho lưu trữ hình ảnh vùng chứa.
  8. Bộ điều khiển CI / CD nhận các tệp kê khai được cập nhật cho những người thuê có liên quan từ kho lưu trữ tệp kê khai và chạy kubectl applylệnh đã thảo luận trước đó để cập nhật các nhóm đang chạy trong cụm Kubernetes với hình ảnh vùng chứa có phiên bản mới nhất của mã ứng dụng.

Hãy nhớ rằng các quy trình phát hành thường khác nhau giữa các tổ chức. Hiếm khi có một cách tiếp cận phù hợp với tất cả các bản phát hành tự động bằng cách sử dụng bộ điều khiển CI / CD. Ví dụ này là một trong nhiều khả năng.

Điều quan trọng cần hiểu là khi một quy trình CI / CD tự động được thực hiện, nó sẽ xử lý phần lớn công việc chi tiết của việc lấy mã từ một nhánh phát hành vào một cụm Kubernetes nhiều đối tượng trong quá trình sản xuất. Các tác vụ phát hành khác nhau, nhưng nhìn chung nhiều chi tiết được xử lý thông qua tự động hóa theo tập lệnh trong bộ điều khiển CI / CD. Nhân viên giải phóng không loanh quanh với các công việc thủ công trừ khi họ đang đối mặt với tình huống khẩn cấp quan trọng. Thay vào đó, các thay đổi trong quy trình CI / CD được thực hiện bằng cách thay đổi các tập lệnh tự động hóa.

Kubernetes hỗ trợ SaaS đa đối tượng có thể mở rộng

Như bài viết này đã trình bày, việc lưu trữ một nền tảng SaaS nhiều đối tượng trên Kubernetes có thể đơn giản. Miễn là cơ sở mã chung được người thuê nền tảng sử dụng là chung, việc triển khai bao gồm việc định cấu hình và triển khai không gian tên, Bí mật, triển khai, dịch vụ và tuyến đường. Tất cả các tài nguyên này ngoại trừ tuyến đường đều được tích hợp sẵn trong Kubernetes. Tài nguyên tuyến đường được cung cấp bởi OpenShift.

Logic ứng dụng chung cho tất cả người thuê được đóng gói thành hình ảnh vùng chứa được lưu trữ trong sổ đăng ký vùng chứa. Hình ảnh được tải xuống cụm theo thông tin cấu hình được đặt trong tệp kê khai của việc triển khai cho đối tượng thuê đã cho. Cuối cùng, các bản phát hành ở cấp độ sản xuất được tự động hóa bằng cách sử dụng bộ điều khiển CI / CD.

Hầu hết các nền tảng SaaS đều dành cho một nhóm trường hợp sử dụng cụ thể. Mỗi thứ đều có xu hướng đặc biệt. Do đó, một nền tảng sẽ có những phức tạp và ngoại lệ riêng cần được giải quyết. Tuy nhiên, việc triển khai một nền tảng SaaS bằng Kubernetes dễ dàng hơn nhiều so với việc xây dựng một nền tảng từ đầu. Kubernetes làm hầu hết nếu không phải là tất cả các danh sách nặng.

Bài viết này đề cập đến các khái niệm và kỹ thuật cơ bản để triển khai nền tảng SaaS nhiều đối tượng trong một cụm Kubernetes. Phần tiếp theo của loạt bài này sẽ giới thiệu chi tiết về ứng dụng trình diễn được sử dụng trong bài viết này. Bài viết đó sẽ mô tả cách lập trình logic chung được sử dụng bởi tất cả người thuê trong nền tảng SaaS trình diễn. Bài viết cũng sẽ mô tả cách khởi động và chạy dự án trình diễn như một nền tảng SaaS đa đối tượng được lưu trữ trong một cụm Kubernetes.

Liên kết: https://developers.redhat.com/articles/2022/08/12/implement-multitenant-saas-kubernetes#kubernetes_supports_scalable_multitenant_saas

#sass #kubernetes 

Cách Triển Khai SaaS Nhiều đối Tượng Trong Một Cụm Kubernetes
Hans  Marvin

Hans Marvin

1660371900

How to Implement A Multitenant SaaS in A Kubernetes Cluster

This article describes how to use standard Kubernetes resources—namespaces, deployments, and services—to create different tenants using a common code base. In addition to the standard Kubernetes resources, we use the route resource provided by Red Hat OpenShift to create a public URL that enables access to the internal Kubernetes service representing the particular tenant application instance.

The demonstration code runs on the Red Hat OpenShift Container Platform because its route resource provides an easy way to create a domain name that provides access to a tenant running within the Kubernetes cluster.

This article refers to demonstration code for implementing the Instrument Reseller SaaS platform. A subsequent article in this series will describe the code in the demonstration project in detail. For now, you can use the demonstration project as a supporting reference for this article.

Be advised that in order to get the full benefit from reading this article, you need to have an understanding of containers and Kubernetes, particularly around the purpose and use of Kubernetes pods, deployments, Secrets, and services. Also, you need to have experience working with the kubectl client for Kubernetes. In addition, you should be comfortable creating Kubernetes resources using manifest (a.k.a. configuration) files.

The following sections describe how to:

  • Use Kubernetes namespaces to isolate tenants in a SaaS platform.
  • Configure Kubernetes deployments to dedicate application logic to a specific tenant.
  • Bind a database to a particular tenant using a Kubernetes Secret.
  • Present a tenant's application logic to the internal network in the cluster using a Kubernetes service.
  • Expose the tenant outside of the cluster using an OpenShift route.
  • Deploy and update tenant application logic using a basic continuous integration/continuous deployment (CI/CD) process.

See more at: https://developers.redhat.com/articles/2022/08/12/implement-multitenant-saas-kubernetes#kubernetes_supports_scalable_multitenant_saas

#sass #kubernetes 

How to Implement A Multitenant SaaS in A Kubernetes Cluster
Thierry  Perret

Thierry Perret

1660364587

Comment Implémenter Un SaaS Mutualisé Dans Un Cluster Kubernetes

Cet article montre de manière concrète comment implémenter un SaaS multitenant dans un cluster Kubernetes .

L'exemple de l'article précédent a converti une application autonome fictive nommée Clyde's Clarinets en une plateforme SaaS nommée Instrument Resellers. Le but de Clyde's Clarinets était d'acquérir, de remettre à neuf et de revendre des clarinettes d'occasion. Clyde's Clarinets a évolué pour devenir la plate-forme SaaS de revendeurs d'instruments afin que toute entreprise puisse acquérir, remettre à neuf et revendre un type particulier d'instrument. Ainsi, Instrument Resellers a la capacité de prendre en charge des locataires tels que Betty's Brass et Sidney's Saxophones ainsi que Clyde's Clarinets. (Voir Figure 1.)

Une application web autonome a été transformée en plateforme SaaS.

Figure 1 : Une application Web autonome a été transformée en une plateforme SaaS.

Implémenter le SaaS sur Kubernetes

Cet article explique comment utiliser les ressources Kubernetes standard (espaces de noms, déploiements et services) pour créer différents locataires à l'aide d'une base de code commune. En plus des ressources Kubernetes standard, nous utilisons la ressource de route fournie par Red Hat OpenShift pour créer une URL publique qui permet d'accéder au service Kubernetes interne représentant l'instance d'application locataire particulière.

Le code de démonstration s'exécute sur Red Hat OpenShift Container Platform car sa ressource de route fournit un moyen simple de créer un nom de domaine qui donne accès à un locataire s'exécutant dans le cluster Kubernetes.

Cet article fait référence au code de démonstration pour la mise en œuvre de la plateforme Instrument Reseller SaaS. Un article ultérieur de cette série décrira en détail le code du projet de démonstration. Pour l'instant, vous pouvez utiliser le projet de démonstration comme référence pour cet article.

Sachez que pour tirer pleinement parti de la lecture de cet article, vous devez comprendre les conteneurs et Kubernetes, en particulier l'objectif et l'utilisation des pods , des déploiements , des secrets et des services Kubernetes . De plus, vous devez avoir une expérience de travail avec le client kubectl pour Kubernetes. En outre, vous devez être à l'aise pour créer des ressources Kubernetes à l'aide de fichiers manifestes (c'est-à-dire de configuration) .

Les sections suivantes décrivent comment :

  • Utilisez les espaces de noms Kubernetes pour isoler les locataires dans une plate-forme SaaS.
  • Configurez les déploiements Kubernetes pour dédier la logique d'application à un locataire spécifique.
  • Liez une base de données à un locataire particulier à l'aide d'un secret Kubernetes.
  • Présentez la logique d'application d'un locataire au réseau interne du cluster à l'aide d'un service Kubernetes.
  • Exposez le locataire en dehors du cluster à l'aide d'une route OpenShift.
  • Déployez et mettez à jour la logique d'application client à l'aide d'un processus de base d'intégration continue/déploiement continu (CI/CD) .

Le rôle des espaces de noms Kubernetes dans le SaaS

La prise en charge de plusieurs locataires dans un seul cluster est une fonctionnalité fondamentale de Kubernetes depuis sa version initiale. Sous Kubernetes, il est tout à fait possible pour de nombreux locataires de partager des instances d'une base de code commune tout en s'exécutant isolément les uns des autres.

Il existe plusieurs approches possibles de la multilocation dans une plateforme SaaS sous Kubernetes :

  • Intégrez l'isolation des locataires directement dans la logique d'une seule application.
  • Exécutez chaque locataire dans son propre cluster.
  • Exécutez chaque locataire dans son propre espace de noms Kubernetes.

La plate-forme Instrument Reseller SaaS adopte la troisième approche et utilise des espaces de noms pour prendre en charge plusieurs locataires dans un seul cluster Kubernetes. Cette section explique les détails du concept d'espace de noms.

Les espaces de noms, comme leur nom l'indique, créent une limite opérationnelle qui peut être imposée à d'autres ressources. Par exemple, vous pouvez créer un espace de noms nommé foo, puis créer d'autres ressources telles que des pods et des services sous cet espace de foonoms. Ces ressources ne connaissent que les autres ressources de l' espace de foonoms. Les ressources en dehors de cet espace de noms n'ont pas accès aux ressources à l'intérieur de l'espace de noms.

Dans un service mutualisé utilisant l'isolement d'espace de noms, chaque locataire du cluster Kubernetes est représenté par un espace de noms particulier. Les ressources de déploiement, de service et d'itinéraire pour le locataire particulier sont créées dans l'espace de noms de ce locataire. La figure 2 illustre comment les espaces de noms Kubernetes isolent les locataires dans la plate-forme SaaS des revendeurs d'instruments.

Chaque locataire a son propre espace de noms et URL, mais exécute la même application.

Figure 2 : Chaque locataire possède son propre espace de noms et son propre URL, mais exécute la même application.

Bien que trois locataires soient illustrés dans la figure 2, cet article montre des configurations uniquement pour Betty's Brass et Clyde's Clarinets, car deux locataires suffisent pour illustrer les concepts que vous devez connaître. Le tableau 1 montre les fichiers manifestes qui déclarent les espaces de noms Kubernetes pour ces locataires. Les deux manifestes sont identiques à l'exception des namepropriétés.

Tableau 1 : Manifestes déclarant des espaces de noms.

Brass de Betty

kind: Namespace
apiVersion: v1
metadata:
  name: bettysbrass
  labels:
    name: bettysbrass

Clarinettes de Clyde

kind: Namespace
apiVersion: v1
metadata:
  name: clydesclarinets
  labels:
    name: clydesclarinets

Pour créer chaque espace de noms dans le cluster Kubernetes, exécutez la commande suivante, où <tenant_namespace>est le nom de fichier du fichier manifeste propre au locataire :

$ kubectl apply -f <tenant_namespace>.yaml

Créer et configurer des locataires dans un SaaS à l'aide d'un déploiement Kubernetes

Une fois les espaces de noms créés, la tâche suivante consiste à implémenter la logique pour le locataire donné en fonction de son espace de noms attribué. Cette tâche utilise la ressource de déploiement Kubernetes.

Comme mentionné précédemment, une caractéristique clé du SaaS de revendeur d'instruments est qu'une seule base de code peut prendre en charge un nombre illimité de locataires qui souhaitent acquérir et revendre des instruments de musique. La logique d'application de chaque revendeur d'instruments est représentée dans le SaaS par une ressource de déploiement Kubernetes.

Un déploiement contrôle une ou plusieurs répliques de pod . Le nombre de pods exécutés dans un déploiement est déterminé par la replicaspropriété dans le fichier manifeste de la ressource de déploiement.

Par conséquent, vous pouvez modifier le nombre de répliques prises en charge par un déploiement pendant l'exécution de l'application. Par exemple, un revendeur d'instruments peut commencer par exécuter trois pods. Mais, après un certain temps, la charge sur le locataire est telle que davantage de pods sont nécessaires. Pour créer plus de pods dans le déploiement, augmentez la valeur attribuée à la replicaspropriété dans le fichier manifeste, de trois à cinq, par exemple. Réappliquez ensuite le fichier manifeste du déploiement au cluster. Lorsque les charges diminuent, vous pouvez réduire le nombre de pods dans le déploiement en modifiant le replicasparamètre dans le fichier manifeste et en réappliquant le fichier modifié au cluster de la même manière.

Si un pod est déconnecté, la ressource de déploiement créera un remplacement si possible.

Personnalisation des déploiements

Dans notre architecture, chaque déploiement doit être dédié à un seul revendeur d'instruments. Vous créez le déploiement dans l'espace de noms de ce revendeur d'instruments et définissez les paramètres requis par ce revendeur, tels que l'URL où il prend les commandes, via des variables d'environnement dans le manifeste Kubernetes.

Par exemple, le tableau 2 montre les manifestes qui configurent le déploiement de Kubernetes pour Betty's Brass et Clyde's Clarinets. Les seules différences sont les valeurs des noms et des instruments.

Tableau 2 : Manifestes configurant les déploiements.

Brass de Betty

apiVersion: apps/v1
kind: Deployment
metadata:
  name: instrumentreseller
  namespace: bettysbrass
  labels:
    app: instrumentreseller
spec:
  replicas: 3
  selector:
    matchLabels:
      app: instrumentreseller
  template:
    metadata:
      labels:
        app: instrumentreseller
    spec:
      initContainers:
        - name: seeder
          image: quay.io/rhdevelopers/instrumentresellerseeder
          env:
            - name: RESELLER_DB_NAME
              value: "brass"
            - name: RESELLER_INSTRUMENT
              value: "brass"
            - name: SEEDER_COUNT
              value: "10"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
      containers:
        - name: instrumentreseller
          image: quay.io/rhdevelopers/instrumentreseller
          env:
            - name: RESELLER_NAME
              value: "Betty's Brass"
            - name: RESELLER_INSTRUMENT
              value: "brass"
            - name: RESELLER_DB_NAME
              value: "brass"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
          ports:
            - containerPort: 8088

Clarinettes de Clyde

apiVersion: apps/v1
kind: Deployment
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
  labels:
    app: instrumentreseller
spec:
  replicas: 3
  selector:
    matchLabels:
      app: instrumentreseller
  template:
    metadata:
      labels:
        app: instrumentreseller
    spec:
      initContainers:
        - name: seeder
          image: quay.io/rhdevelopers/instrumentresellerseeder
          env:
            - name: RESELLER_DB_NAME
              value: "clarinets"
            - name: SEEDER_COUNT
              value: "10"
            - name: RESELLER_INSTRUMENT
              value: "clarinet"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
      containers:
        - name: instrumentreseller
          image: quay.io/rhdevelopers/instrumentreseller
          env:
            - name: RESELLER_NAME
              value: "Clyde's Clarinets"
            - name: RESELLER_INSTRUMENT
              value: "clarinet"
            - name: RESELLER_DB_NAME
              value: "clarinets"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
          ports:
            - containerPort: 8088

Un point clé à comprendre concernant les exemples précédents est que les deux locataires utilisent les mêmes images de conteneur. Dans chaque locataire, le conteneur init utilise l' quay.io/rhdevelopers/instrumentresellerseeder image et le conteneur principal utilise l' quay.io/rhdevelopers/instrumentreseller image. N'oubliez pas qu'un principe essentiel de la location multiple dans une plate-forme SaaS est que tous les locataires utilisent la même base de code. Le fait que plusieurs locataires utilisent les mêmes images de conteneur prend en charge ce principe de base.

Chaque locataire de la plate-forme SaaS se lie à sa propre base de données. Cette base de données peut exister dans le cluster Kubernetes ou être un service de base de données externe défini par une URL. Souvent, les informations de nom d'utilisateur et de mot de passe nécessaires pour accéder à la base de données feront partie de l'URL.

Mettre les informations de nom d'utilisateur et de mot de passe dans un cluster est toujours une entreprise risquée. Une bonne pratique pour mettre les informations de nom d'utilisateur/mot de passe à la disposition des pods dans un cluster Kubernetes consiste à utiliser une ressource Kubernetes appelée Secret . Nous verrons sous peu comment notre application transmet les informations d'identification à la base de données.

Amorçage des données

Comme brièvement mentionné précédemment, les pods du déploiement utilisent des conteneurs init en plus des conteneurs standard. Un conteneur init est un conteneur qui s'exécute avant le conteneur principal. Dans le cas de l'Instrument Reseller SaaS, le conteneur init effectue le travail d'implémentation d'une fonctionnalité spéciale du code de démonstration : l'amorçage des données.

Étant donné que nous ne travaillons pas avec de vrais détaillants dans la démo, nous utilisons le conteneur init pour ensemencer la base de données de l'instance du locataire avec des données aléatoires propres au type d'instrument vendu par le revendeur d'instruments. Le but de l'ensemencement des données dans la démo est de fournir des données initiales à afficher lorsque l'application est utilisée pour la première fois. Betty's Brass sera ensemencée avec des données sur les cuivres. Les clarinettes de Clyde seront ensemencées avec des données sur les clarinettes. Les saxophones de Sidney seront ensemencés avec des données spécifiques aux saxophones.

L'utilisation du modèle d'amorçage de données dans des conteneurs pour préremplir les données d'une application ouvre le risque d'amorçage redondant. Si l'on exécute simplement le conteneur init dans chaque réplica de pod, le déploiement tente d'amorcer les données dans la source de données au démarrage de chaque réplica. À moins qu'une précaution ne soit prise, un ensemencement de données injustifié se produira.

Par conséquent, le générateur de données est programmé pour se rendre à la source de données et vérifier si des données de départ préexistantes existent. Si des données de départ se trouvent déjà dans la source de données, le programme de départ se termine sans ajouter de données supplémentaires.

Fournir des identifiants de base de données via Kubernetes Secrets

Les secrets sont une ressource Kubernetes permettant de fournir des informations sensibles à d'autres ressources de manière sécurisée.

Le tableau 3 montre les configurations qui déclarent un secret nommé mongo-urldans deux espaces de noms différents : un pour Betty's Brass et l'autre pour Clyde's Clarinets.

Tableau 3 : Manifestes configurant les secrets.

Brass de Betty

apiVersion: v1
kind: Secret
metadata:
  name: mongo-url
  namespace: bettysbrass
type: Opaque
stringData:
  url: <mongo-url-here>

Clarinettes de Clyde

apiVersion: v1
kind: Secret
metadata:
  name: mongo-url
  namespace: clydesclarinets
type: Opaque
stringData:
  url: <mongo-url-here>

Notez que chaque secret est attribué à son espace de noms respectif. Le secret nommé mongo-urlpour Betty's Brass est attribué à l' espace de bettysbrassnoms. Le secret du même mongo-urlnom pour les clarinettes de Clyde est attribué à l' espace de clydesclarinetsnoms. Même si chaque secret porte le même nom, ils sont distincts car ils sont affectés à des espaces de noms différents. L'utilisation du même nom parmi les ressources est l'un des avantages de l'utilisation des espaces de noms.

Exposer la logique d'application à l'aide d'un service Kubernetes

Une fois le secret configuré pour chaque locataire, l'étape suivante consiste à créer le service Kubernetes qui expose la logique d'application au réseau Kubernetes interne au sein de la plate-forme SaaS. Le tableau 4 montre les configurations pour le service Kubernetes dans Betty's Brass à l'aide de l' espace de bettysbrassnoms et pour Clyde's Clarinets à l'aide de l' espace de clydesclarinetsnoms. Encore une fois, l'attribution de chaque service à un espace de noms différent maintient les locataires isolés.

Tableau 4 : Manifestes configurant les services.

Brass de Betty

apiVersion: v1
kind: Service
metadata:
  name: instrumentreseller
  namespace: bettysbrass
spec:
  selector:
    app: instrumentreseller
  ports:
    - protocol: TCP
      port: 8088
      targetPort: 8088

Clarinettes de Clyde

apiVersion: v1
kind: Service
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
spec:
  selector:
    app: instrumentreseller
  ports:
    - protocol: TCP
      port: 8088
      targetPort: 8088

Exposer le locataire en dehors du cluster à l'aide d'une route OpenShift

La dernière étape de configuration consiste à créer la ressource de route OpenShift qui publie un nom de domaine pour exposer le locataire en dehors du cluster Kubernetes. Les manifestes du tableau 5 déclarent les routes OpenShift pour Betty's Brass et Clyde's Clarinets. Chaque manifeste utilise l'espace de noms de son locataire ainsi qu'un hôte différent.

Tableau 5 : Manifestes configurant les routes OpenShift.

Brass de Betty

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: instrumentreseller
  namespace: bettysbrass
spec:
  host: bettysbrass.com
  port:
    targetPort: 8088
  to:
    kind: Service
    name: instrumentreseller

Clarinettes de Clyde

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
spec:
  host: clydesclarinets.com
  port:
    targetPort: 8088
  to:
    kind: Service
    name: instrumentreseller

La route sait à quel service se lier via l' toattribut au bas de chaque fichier manifeste.

La déclaration d'un ensemble de fichiers manifestes pour l'espace de noms Kubernetes, le déploiement, le secret, le service et l'itinéraire sont les premières étapes pour qu'un locataire soit opérationnel dans un cluster Kubernetes. Une fois les fichiers manifestes créés, exécutez la commande suivante pour que chacun des locataires s'exécute dans le cluster Kubernetes, où <manifest_file>est le nom du fichier manifeste pour le locataire donné :

$ kubectl apply -f <manifest_file>.yaml

En supposant une configuration correcte, vous aurez un locataire opérationnel en utilisant rien de plus que quelques kubectlcommandes. Cependant, comme ceux d'entre nous qui ont passé beaucoup de temps à travailler avec Kubernetes en sont venus à comprendre, les mots "configuration appropriée" peuvent signifier des heures, voire des jours de travail. En bref, tout câbler est difficile. Tu dois être prudent.

Donc, pour terminer cet article, nous allons concevoir un processus de déploiement pour notre déploiement SaaS qui peut être facilement automatisé.

Un processus de publication CI/CD

Le déploiement de locataires dans une plate-forme SaaS présente différents degrés de complexité. Vous pouvez effectuer un déploiement manuel dans lequel vous créez des images de conteneur Linux pour la logique d'application de la plate-forme SaaS, puis transférez ces images vers un registre d'images de conteneur tel que Quay.io .

Ensuite, une fois que les images de conteneur requises se trouvent dans le registre, créez des fichiers manifestes que vous utiliserez pour réaliser la ressource de déploiement Kubernetes dans le cluster Kubernetes dans lequel la plate-forme SaaS est en cours d'exécution. Ces fichiers manifestes déclarent les images de conteneur d'application qui seront utilisées.

Après avoir créé les fichiers manifestes, exécutez la kubectl applycommande indiquée vers la fin de la section précédente pour créer la ressource Kubernetes associée dans le cluster.

Le processus qui vient d'être décrit est illustré à la figure 3.

Le déploiement manuel prend en charge plusieurs locataires, exécutant une commande kubectl apply pour nous.

Figure 3 : Le déploiement manuel prend en charge plusieurs locataires, en exécutant une commande kubectl apply pour nous.

Le déploiement manuel est un moyen réalisable de travailler avec une plate-forme SaaS pour la recherche et l'expérimentation. Mais ce n'est pas réaliste pour les versions de production d'aujourd'hui, qui nécessitent l'automatisation du processus.

L'utilisation de l'automatisation est particulièrement appropriée pour les organisations qui ont un certain nombre d'équipes prenant en charge une plate-forme SaaS. Se fier aux e-mails et au bouche-à-oreille entre les équipes peut être risqué. L'automatisation permet de formaliser le processus de publication.

Au centre de l'automatisation des versions se trouve un contrôleur CI/CD tel que Jenkins ou OpenShift Pipelines . Le contrôleur CI/CD automatise de nombreuses, voire toutes, les tâches nécessaires pour obtenir les artefacts d'une application à partir d'un référentiel de code source en production.

La figure 4 montre un exemple de processus CI/CD qui met à jour une plateforme SaaS. Le contrôleur CI/CD effectue le travail de conditionnement du code prêt à être publié dans une image de conteneur. Ensuite, il pousse cette image vers un registre de conteneurs et met à jour la plate-forme SaaS avec la nouvelle version de l'image.

Un processus CI/CD automatisé pour une plate-forme SaaS mutualisée utilise un contrôleur CI/CD pour plusieurs étapes.

Figure 4 : Un processus CI/CD automatisé pour une plate-forme SaaS mutualisée utilise un contrôleur CI/CD pour plusieurs étapes.

Les étapes numérotées de la figure 4 sont :

  1. Le développeur met à jour le code et valide le travail mis à jour dans la branche de développement du référentiel de code source.
  2. L'équipe d'assurance qualité (Q/A) transmet le code de la branche de développement à la branche Q/A et exécute des tests unitaires. Si les tests réussissent, Q/A exécute les tests d'intégration. Une fois l'exécution réussie, Q/A informe l'équipe de gestion des versions qu'une nouvelle version du code est prête à être transmise à la branche principale du référentiel de code source.
  3. La gestion des versions fusionne le code dans la branche principale.
  4. La gestion des versions met à jour les fichiers manifestes Kubernetes avec la nouvelle balise de version de l'image de conteneur associée à la version prévue. Les fichiers mis à jour sont validés dans le référentiel de fichiers manifestes.
  5. Lors d'une fusion réussie du code source et des fichiers manifestes, le contrôleur CI/CD est averti via l'automatisation que le code est prêt à être empaqueté dans une image de conteneur et déployé dans un registre d'images de conteneur tel que Quay.io.
  6. Le contrôleur CI/CD obtient le code mis à jour à partir du référentiel de code source et crée une image de conteneur mise à jour à partir du fichier conteneur stocké dans le référentiel avec le code source de l'application.
  7. Le contrôleur CI/CD pousse l'image de conteneur mise à jour vers un référentiel d'images de conteneur.
  8. Le contrôleur CI/CD obtient les fichiers manifestes mis à jour pour les locataires concernés à partir du référentiel de fichiers manifestes et exécute la kubectl applycommande décrite précédemment pour mettre à jour les pods exécutés dans le cluster Kubernetes avec l'image de conteneur qui possède la dernière version du code d'application.

Gardez à l'esprit que les processus de publication varient généralement d'une organisation à l'autre. Il existe rarement une approche unique pour les versions automatisées à l'aide d'un contrôleur CI/CD. Cet exemple est l'une des nombreuses possibilités.

La chose importante à comprendre est que lorsqu'un processus CI/CD automatisé est en place, il gère une grande partie du travail détaillé d'obtention du code d'une branche de publication dans un cluster Kubernetes multitenant en production. Les tâches de publication varient, mais en général, de nombreux détails sont gérés via une automatisation scriptée dans le contrôleur CI/CD. Le personnel de libération ne s'occupe pas des tâches manuelles à moins qu'il ne soit confronté à une urgence critique. Au lieu de cela, les changements dans le processus CI/CD sont mis en œuvre en modifiant les scripts d'automatisation.

Kubernetes prend en charge le SaaS mutualisé évolutif

Comme cet article l'a montré, l'hébergement d'une plate-forme SaaS mutualisée sur Kubernetes peut être simple. Tant que la base de code commune utilisée par les locataires de la plate-forme est générique, la mise en œuvre implique la configuration et le déploiement de l'espace de noms, du secret, du déploiement, du service et de la route. Toutes ces ressources, à l'exception de la route, sont intégrées à Kubernetes. La ressource d'itinéraire est fournie par OpenShift.

La logique d'application commune à tous les locataires est encapsulée dans des images de conteneur qui sont stockées dans un registre de conteneurs. L'image est téléchargée sur le cluster en fonction des informations de configuration définies dans le fichier manifeste du déploiement pour le locataire donné. Enfin, les versions au niveau de la production sont automatisées à l'aide d'un contrôleur CI/CD.

La plupart des plates-formes SaaS sont destinées à un ensemble particulier de cas d'utilisation. Chacun a tendance à être spécial. Par conséquent, une plate-forme aura son propre ensemble de complexités et d'exceptions qui doivent être prises en compte. Pourtant, la mise en œuvre d'une plate-forme SaaS à l'aide de Kubernetes est beaucoup plus facile que d'en créer une à partir de zéro. Kubernetes fait la plupart sinon la totalité de la liste lourde.

Cet article a couvert les concepts et techniques fondamentaux pour implémenter une plate-forme SaaS mutualisée dans un cluster Kubernetes. Le prochain article de cette série examinera en détail l'application de démonstration utilisée dans cet article. Cet article décrira comment programmer la logique générique utilisée par tous les locataires dans la plateforme SaaS de démonstration. L'article décrira également comment rendre le projet de démonstration opérationnel en tant que plate-forme SaaS mutualisée hébergée dans un cluster Kubernetes.

Lien : https://developers.redhat.com/articles/2022/08/12/implement-multitenant-saas-kubernetes#kubernetes_supports_scalable_multitenant_saas

#sass #kubernetes 

Comment Implémenter Un SaaS Mutualisé Dans Un Cluster Kubernetes

Weather App: A Simple Weather App Developed with React

React Weather App

Weather App is a simple weather app developed in typescript using React, HTML and SASS. The app allows you to see the weather from your current location or another location around the globe using OpenWeather Api and Google Maps Api. Using One Call API the app displays the current weather, 24 hours and 6 days forecast. You can change the unit system from metric to imperial. The app is available in light and dark mode.

If you like this repository you can support me on

Buy Me A Coffee

Light mode

Dark mode

Libraries

Setup

Create a file called .env in the root of the React-WeatherApp project. Add the following code in the file.

REACT_APP_OPENWEATHER_API_BASEURL = "https://api.openweathermap.org/data/2.5/onecall"
REACT_APP_OPENWEATHER_API_KEY = "YOUR_OPENWEATHERAPI_KEY"
REACT_APP_GEOLOCATION_GEOCODE_BASEURL = "https://maps.googleapis.com/maps/api/geocode/json"
REACT_APP_GEOLOCATION_API_KEY = "YOUR_GOOGLEMAPSAPI_KEY"

The app is using One Call API from OpenWeather API. To start the project you need an account and OpenWeather API Key. You can signup and get the key from here.

The app is using Geocoding and Reverse Geocoding from Google Maps API. To start the project you need a google account and Google Maps API Key. You can get the key from here.

To use real data, change the flag useMockData to false from Container.tsx.

Resources

Illustrations are from Freepik

Other versions

Xamarin-WeatherApp - developed in Xamarin

DEMO with mock data


Author: gheorghedarle
Source code: https://github.com/gheorghedarle/React-WeatherApp

#react-native  #typescript #html #sass 

Weather App: A Simple Weather App Developed with React

Pokedex: Pokédex Built with React JS, PokéAPI, Sass and Webpack

Pokédex

Pokédex built with React and PokéAPI, infinite scrolling of pokemon cards implemented using Intersection Observer API. 
 

Project Summary

Development

Steps to run Pokédex in your local environment.

Clone the repository

git clone https://github.com/shanpriyan/pokedex.git

Go to the project directory

cd pokedex

Install the NPM packages

npm i

Start the development server

npm start

Development server will start at localhost:8080
 

Linting

This project is configured with ESLint for linting in .eslintrc.json. You can use npm run lint script to check for errors or warnings in the project. 
 

Formatting

This project uses Prettier for formatting. You can use npm run prettify script to format all files in the project.

Bundling

This project uses webpack for bundling.

  • Use npm run build script to generate a production build
  • Use npm run build:dev script to generate a development build.
  • Build will output to dist folder.

Babel

This project is configured with new runtime JSX transform. React doesn't need to be in scope while using JSX.

Demo

Live Demo - https://pokedex.shanpriyan.in/

View Demo


Author: shanpriyan
Source code: https://github.com/shanpriyan/pokedex
 

#javascript #react-native #sass 

Pokedex: Pokédex Built with React JS, PokéAPI, Sass and Webpack
Minh  Nguyet

Minh Nguyet

1659362160

Bảo Mật SaaS Trong Môi Trường Kubernetes

Bảo mật đặc biệt quan trọng đối với môi trường Phần mềm dưới dạng Dịch vụ (SaaS) , nơi nền tảng được sử dụng bởi nhiều người khác nhau, những người cần sự tin tưởng rằng dữ liệu của họ được lưu trữ an toàn và giữ kín với những người dùng không liên quan. Bài viết này tập trung vào các mối quan tâm về bảo mật đối với các vùng chứa khi triển khai SaaS của bạn đang chạy trong môi trường Kubernetes chẳng hạn như Red Hat OpenShift . Bài viết là bài thứ năm trong loạt bài có tên là danh sách kiểm tra kiến ​​trúc SaaS bao gồm các cân nhắc về phần mềm và triển khai cho các ứng dụng SaaS.

Kiểm soát bảo mật và thực hành cho SaaS

Trong môi trường doanh nghiệp hiện đại, bảo mật cần được xây dựng trong toàn bộ vòng đời của việc lập kế hoạch, phát triển, vận hành và bảo trì. Các biện pháp kiểm soát và thực hành an ninh tốt là rất quan trọng để đáp ứng các yêu cầu về tuân thủ và quy định cũng như đảm bảo rằng các giao dịch đáng tin cậy và có hiệu suất cao. Bảo mật trong SaaS có thể được chia thành năm lớp chính: phần cứng, hệ điều hành, vùng chứa, Kubernetes và mạng. Hình 1 cho thấy các lớp này và các biện pháp kiểm soát bảo mật giải quyết các mối đe dọa ở mỗi lớp.

Các lớp SaaS và các tính năng bảo mật của chúng trong Kubernetes và OpenShift.

Hình 1: Các lớp SaaS và các tính năng bảo mật của chúng trong Kubernetes và OpenShift.

Bảo mật cần được giải quyết ở mọi lớp vì bất kỳ lỗ hổng nào trong một lớp này đều có thể bị khai thác để xâm phạm các lớp khác. Đối với mỗi lớp, Kubernetes và OpenShift có các tính năng và kiểm soát bảo mật sẽ được đề cập trong bài viết này. Các bài viết trong tương lai sẽ đi vào chi tiết hơn về các chủ đề bảo mật SaaS cụ thể. Nếu có bất kỳ chủ đề SaaS nào mà bạn muốn xem một bài báo, hãy cho chúng tôi biết trong phần bình luận.

Bảo mật ở lớp phần cứng

Bảo mật môi trường SaaS thường bắt đầu với việc xác định nơi ứng dụng sẽ chạy và các mối quan tâm về bảo mật đối với môi trường đó. Môi trường an toàn bao gồm trung tâm dữ liệu thực tế cũng như bản thân phần cứng, bao gồm mã hóa đĩa, khởi động an toàn, mật khẩu cấp BIOS và việc sử dụng các mô-đun bảo mật phần cứng (HSM). Bí mật và quản lý danh tính sẽ được thảo luận ở phần sau của bài viết này.

Mặc dù rất nhiều người chú ý đến việc sử dụng mã hóa để bảo vệ dữ liệu đang truyền khi nó đi qua mạng, nhưng việc bảo vệ dữ liệu ở trạng thái nghỉ cũng rất quan trọng vì nó được lưu trữ trên các thiết bị lưu trữ vật lý trong trung tâm dữ liệu. Rủi ro đối với dữ liệu ở trạng thái nghỉ cao hơn nhiều trong các trung tâm dữ liệu nơi bạn thiếu quyền kiểm soát quyền truy cập vào cơ sở và nơi các nhà thầu bên thứ ba có thể được thuê. Sử dụng mã hóa đĩa để bảo mật dữ liệu ở trạng thái nghỉ bằng cách bảo vệ dữ liệu được lưu trữ trên máy chủ vật lý khỏi bị truy cập ngoài ý muốn.

HSM thường là một thiết bị vật lý lưu trữ an toàn các khóa kỹ thuật số thông qua mã hóa để bảo vệ dữ liệu nhạy cảm. HSM được sử dụng để quản lý và bảo vệ thông tin xác thực, khóa, chứng chỉ và bí mật bảo mật trong khi nghỉ và khi đang vận chuyển. HSM cung cấp mức độ bảo vệ cao hơn so với các phương pháp chỉ sử dụng phần mềm như kho bí mật.

Các HSM đám mây có sẵn từ các nhà cung cấp đám mây lớn để tăng cường khả năng bảo vệ trong môi trường đám mây. HSM được khuyến nghị để quản lý bí mật trong môi trường SaaS.

Bảo vệ quyền truy cập vào máy chủ bằng cách cho phép khởi động an toàn và sử dụng mật khẩu cấp BIOS. Khởi động an toàn là một tính năng bảo mật phần sụn của Giao diện phần mềm mở rộng hợp nhất (UEFI) đảm bảo rằng chỉ phần mềm bất biến và đã ký mới có thể chạy trong quá trình khởi động.

Để biết thêm thông tin, hãy xem:

Bảo mật hệ điều hành

Mọi cụm Kubernetes đều chạy trên một số hệ điều hành cơ bản (OS). Các tính năng bảo mật và tăng cường ở lớp OS giúp bảo vệ toàn bộ cụm, vì vậy điều quan trọng là phải bật và sử dụng các điều khiển cấp OS.

Khi nói đến việc tăng cường bảo mật ở cấp độ hệ điều hành, Red Hat OpenShift có hai lợi thế khác biệt. Đầu tiên, Linux được tăng cường bảo mật (SELinux) được tích hợp và kích hoạt ngay lập tức. Thứ hai, OpenShift chạy trên Red Hat Enterprise Linux CoreOS, một hình ảnh hệ điều hành duy nhất được điều chỉnh để sử dụng SaaS.

Linux tăng cường bảo mật

SELinux là một kiến ​​trúc bảo mật dành cho các hệ thống Linux cấp cho quản trị viên quyền kiểm soát chi tiết hơn đối với quyền truy cập vào tài nguyên hệ thống so với khả năng có sẵn với Linux mặc định. SELinux định nghĩa các điều khiển truy cập bắt buộc cho các ứng dụng, quy trình và tệp trên hệ thống. Trên nút Kubernetes, SELinux bổ sung một lớp bảo vệ quan trọng chống lại các lỗ hổng phá vỡ vùng chứa .

Do đó, một trong những biện pháp bảo mật hiệu quả nhất là kích hoạt và cấu hình SELinux, mà Red Hat đã đưa ra tiêu chuẩn trên tất cả các cụm OpenShift. Đây được coi là phương pháp hay nhất để sử dụng SELinux trong môi trường SaaS. Trong OpenShift, SELinux tăng cường bảo mật vùng chứa bằng cách đảm bảo tách vùng chứa thực sự và kiểm soát truy cập bắt buộc.

Để biết thêm thông tin, hãy xem:

Một hệ điều hành cứng cho vùng chứa: Red Hat Enterprise Linux CoreOS

Hệ điều hành của OpenShift, Red Hat Enterprise Linux CoreOS, dựa trên Red Hat Enterprise Linux và sử dụng cùng một nhân, mã và các quy trình phát triển nguồn mở. Phiên bản đặc biệt này đi kèm với một tập hợp con cụ thể của các gói Red Hat Enterprise Linux, được thiết kế để sử dụng trong các cụm OpenShift 4. Các tính năng chính giúp hệ điều hành này an toàn hơn là:

Dựa trên Red Hat Enterprise Linux: Hệ điều hành cơ bản chủ yếu là các thành phần Red Hat Enterprise Linux, có nghĩa là nó có cùng chất lượng, bảo mật, các biện pháp kiểm soát và hỗ trợ. Khi một bản sửa lỗi được đẩy lên Red Hat Enterprise Linux, bản sửa lỗi đó cũng được đẩy lên Red Hat Enterprise Linux CoreOS.

Tính bất biến được kiểm soát: Red Hat Enterprise Linux CoreOS được quản lý thông qua API OpenShift, dẫn đến việc quản lý hệ điều hành dễ dàng hơn. Quản lý chủ yếu được thực hiện hàng loạt cho tất cả các nút trong toàn bộ cụm OpenShift. Trạng thái mới nhất của hệ thống Red Hat Enterprise Linux CoreOS được lưu trữ trên cụm, giúp dễ dàng thêm các nút mới hoặc đẩy các bản cập nhật cho tất cả các nút. Với tính chất giao dịch và quản lý tập trung của HĐH, chỉ có thể sửa đổi một số cài đặt hệ thống trên bản cài đặt Red Hat Enterprise Linux CoreOS.

Các công cụ vùng chứa dòng lệnh: Red Hat Enterprise Linux CoreOS bao gồm các công cụ vùng chứa tương thích với đặc tả Open Container Initiative (OCI) để xây dựng, sao chép và quản lý hình ảnh vùng chứa. Nhiều tính năng quản trị thời gian chạy vùng chứa có sẵn thông qua Podman. Lệnh skopeo sao chép, xác thực và ký hình ảnh. Lệnh crictl cho phép bạn xem và khắc phục sự cố vùng chứa và nhóm.

Cập nhật giao dịch mạnh mẽ: Red Hat Enterprise Linux CoreOS cung cấp quy trình nâng cấp rpm-ostree , đảm bảo rằng quá trình nâng cấp diễn ra nguyên tử. Nếu có sự cố, hệ điều hành gốc có thể được khôi phục trong một lần khôi phục.

OpenShift xử lý các nâng cấp hệ điều hành thông qua Máy vận hành cấu hình máy (MCO), bao gồm nâng cấp hệ điều hành hoàn chỉnh thay vì các gói riêng lẻ như trong nâng cấp Yum truyền thống. OpenShift cũng cập nhật các nút thông qua bản cập nhật liên tục để giảm thiểu tác động của các bản cập nhật và duy trì dung lượng cụm. Trong quá trình cài đặt và nâng cấp, cây hệ thống tệp bất biến mới nhất được đọc từ hình ảnh vùng chứa, được ghi vào đĩa và được tải vào bộ nạp khởi động. Máy sẽ khởi động lại vào phiên bản hệ điều hành mới, đảm bảo cập nhật nguyên tử.

Bảo mật trong quá trình cài đặt cụm: Red Hat Enterprise Linux CoreOS giảm thiểu các quyết định bảo mật trong quá trình cài đặt. Hai tính năng bảo mật được coi là quyết định khởi động trước đầu tiên cho các hoạt động cụm: hỗ trợ mật mã FIPS và mã hóa toàn bộ đĩa (FDE). Sau khi cụm được khởi động, cụm có thể được định cấu hình thêm cho các thay đổi cấp nút khác.

Lớp chứa

Lớp vùng chứa trong Kubernetes và OpenShift cách ly các quy trình với nhau và với Hệ điều hành cơ bản. Thay vì thiết kế phần mềm truyền thống, nơi tất cả các thành phần được liên kết, triển khai cùng nhau và cuối cùng phụ thuộc vào nhau, các thùng chứa là độc lập, dẫn đến tác động nhỏ hơn. Nếu một thùng chứa bị hỏng, nó có thể dễ dàng được thay thế. Nếu một hình ảnh vùng chứa được phát hiện có lỗ hổng bảo mật, lỗ hổng đó sẽ được tách biệt với hình ảnh đó và chỉ yêu cầu cập nhật hình ảnh đó thay vì toàn bộ cụm.

Red Hat OpenShift có nhiều tính năng cải thiện bảo mật vùng chứa cho môi trường nhiều đối tượng.

Động cơ container

Công cụ vùng chứa cung cấp các công cụ để tạo hình ảnh vùng chứa và khởi động vùng chứa. Trong OpenShift, công cụ chứa mặc định là CRI-O , hỗ trợ các vùng chứa tuân theo OCI và libcontainerd. Công cụ container tập trung vào các tính năng cần thiết của Giao diện thời gian chạy container (CRI) của Kubernetes. Công cụ chứa tùy chỉnh này thu nhỏ bề mặt có sẵn cho một cuộc tấn công bảo mật, vì công cụ chứa không chứa các tính năng không cần thiết như sử dụng dòng lệnh trực tiếp hoặc các phương tiện điều phối.

Chúng tôi cũng đã căn chỉnh CRI nhiều hơn với Kubernetes: Các bản cập nhật cho CRI-O được thực hiện để hoạt động tốt hơn với bản phát hành Kubernetes hiện tại.

Bảo mật vùng chứa trong nhân Linux

Kernel cung cấp các tính năng để đảm bảo tính bảo mật của các thùng chứa và mọi thứ khác đang chạy trên HĐH. Trước hết, tất cả các vùng chứa được khởi chạy bên trong một không gian tên tạo ra một hộp cát riêng biệt tách biệt các vùng chứa, hệ thống tệp, quy trình và mạng.

Tính năng tiếp theo là các nhóm điều khiển (cgroups), chúng cô lập việc chia sẻ tài nguyên phần cứng giữa các vùng chứa và các nút của cụm OpenShift. Việc sử dụng cgroups ngăn chặn bất kỳ quá trình hoặc vùng chứa nào sử dụng hết các tài nguyên có sẵn trên một máy chủ lưu trữ.

Cuối cùng, như chúng ta đã thảo luận trước đó, Red Hat Enterprise Linux CoreOS kích hoạt SELinux, ngăn một vùng chứa phá vỡ sự cô lập của nó và do đó can thiệp gián tiếp vào các vùng chứa khác trên cùng một máy chủ.

Bảo mật cụm trên Kubernetes và Red Hat OpenShift

Cấp độ cụm kiểm soát cách Kubernetes triển khai máy chủ, quản lý tài nguyên được chia sẻ, kiểm soát thông tin liên lạc giữa các bộ điều khiển, quản lý mở rộng quy mô và kiểm soát quyền truy cập vào cụm. Một cụm OpenShift được tạo thành từ một mặt phẳng điều khiển, các nút công nhân và bất kỳ tài nguyên bổ sung nào cần thiết. Các phần phụ sau đây đề cập đến một số mối quan tâm về bảo mật đối với các khía cạnh khác nhau của cụm.

Điều khiển máy bay cách ly

Nó được coi là một phương pháp hay nhất để cô lập các nút mặt phẳng điều khiển của cụm khỏi các nút công nhân. Điều này thường được thực hiện bằng cách sử dụng phần cứng riêng biệt cho mặt phẳng điều khiển để giảm thiểu tác động của mọi cấu hình sai, sự cố quản lý tài nguyên hoặc lỗ hổng.

Quản lý danh tính

Mỗi cụm Kubernetes cần một số hình thức quản lý danh tính. Ngoài ra, Red Hat OpenShift đi kèm với nhà cung cấp OAuth mặc định , được sử dụng để xác thực dựa trên mã thông báo. Nhà cung cấp này có một kubeadmintài khoản người dùng duy nhất, bạn có thể sử dụng tài khoản này để định cấu hình nhà cung cấp danh tính thông qua tài nguyên tùy chỉnh (CR) . OpenShift hỗ trợ  các nhà cung cấp nhận dạng tiêu chuẩn OpenID Connect  và LDAP. Sau khi danh tính được xác định, hãy sử dụng kiểm soát truy cập dựa trên vai trò (RBAC) để xác định và áp dụng quyền.

Kiểm soát truy cập cụm

Trước khi người dùng tương tác với cụm, trước tiên họ phải xác thực thông qua máy chủ OAuth. Các kết nối nội bộ đến máy chủ API được xác thực bằng chứng chỉ X.509.

Ràng buộc bối cảnh bảo mật

Ràng buộc bối cảnh bảo mật (SCC) là một tính năng bảo mật của OpenShift giới hạn quyền truy cập tài nguyên của nhóm và các hành động được phép. SCC cho phép quản trị viên kiểm soát phần lớn cấu hình của nhóm, chẳng hạn như ngữ cảnh SELinux của một vùng chứa, liệu một nhóm có thể chạy các vùng chứa đặc quyền hay không và việc sử dụng các thư mục lưu trữ dưới dạng ổ đĩa. Trong OpenShift, SCC được bật theo mặc định và không thể tắt. SCC có thể cải thiện sự cô lập trong việc triển khai SaaS và giảm tác động của các lỗ hổng tiềm ẩn.

Pod SCC được xác định bởi nhóm mà người dùng thuộc về cũng như tài khoản dịch vụ, nếu được chỉ định. Theo mặc định, các nút công nhân và các nhóm đang chạy trên chúng sẽ nhận được loại SCC restricted. Loại SCC này ngăn các nhóm chạy dưới dạng đặc quyền và yêu cầu chúng chạy dưới một UID được chọn trong thời gian chạy từ một dải UID được phân bổ trước.

Bí mật

Trong triển khai SaaS, người thuê cần bảo mật dữ liệu nhạy cảm của họ trên cụm. Điều này được xử lý với các đối tượng Bí mật trên OpenShift. Đối tượng bí mật nắm giữ thông tin nhạy cảm như mật khẩu, tệp cấu hình ứng dụng khách OCP, thông tin đăng nhập của kho lưu trữ nguồn riêng tư, v.v. Cách sử dụng Đối tượng bí mật này sẽ tách nội dung nhạy cảm khỏi nhóm.

Khi cần nội dung nhạy cảm, nội dung đó có thể được gắn vào vùng chứa thông qua plugin khối lượng hoặc hệ thống có thể sử dụng các bí mật để thực hiện hành động thay mặt cho nhóm. Các thuộc tính chính của bí mật bao gồm:

  • Dữ liệu bí mật có thể được tạo bởi một thực thể, chẳng hạn như một công cụ cấu hình và được tham chiếu bởi một thực thể khác, chẳng hạn như một ứng dụng.
  • Khối lượng dữ liệu bí mật được hỗ trợ bởi các phương tiện lưu trữ tệp tạm thời (tmpfs) và không bao giờ dừng lại trên một nút.
  • Dữ liệu bí mật có thể được chia sẻ trong một không gian tên.
  • Dữ liệu bí mật có thể được mã hóa tùy ý .

Để biết thêm thông tin, hãy đọc Cung cấp dữ liệu nhạy cảm cho nhóm .

Red Hat Advanced Cluster Security cho Kubernetes

Ngoài các tính năng bảo mật tiêu chuẩn trong Red Hat OpenShift, Red Hat cung cấp các sản phẩm bổ sung để tăng cường bảo mật cho nền tảng. Một trong số đó là Red Hat Advanced Cluster Security cho Kubernetes (trước đây là StackRox). Red Hat Advanced Cluster Security dành cho Kubernetes bảo vệ các ứng dụng quan trọng của bạn trong các giai đoạn xây dựng, triển khai và thời gian chạy. Nó triển khai trong cơ sở hạ tầng của bạn và dễ dàng tích hợp với công cụ DevOps và quy trình làm việc. Sự tích hợp này giúp dễ dàng áp dụng các chính sách bảo mật và tuân thủ.

Red Hat Advanced Cluster Security bổ sung thêm tính năng bảo mật tích hợp của OpenShift bằng cách cải thiện các đối tượng bảo mật cốt lõi sau:

  • Cải thiện khả năng hiển thị của môi trường, để quản trị viên có thể dễ dàng phát hiện các vấn đề hơn khi chúng xảy ra.
  • Quản lý các lỗ hổng khi chúng đã được xác định bằng cách triển khai các bản sửa lỗi thông qua đường ống CI / CD tích hợp.
  • Đảm bảo tuân thủ các tiêu chuẩn ngành và các thông lệ tốt nhất.
  • Thêm phân đoạn mạng mạnh mẽ để hạn chế lưu lượng mạng chỉ cho những mục đích sử dụng cần thiết.
  • Xếp hạng dựa trên rủi ro của từng triển khai để xác định khả năng xảy ra rủi ro bảo mật, giúp đảm bảo rằng các triển khai có rủi ro cao nhất được khắc phục ngay lập tức trước tiên.
  • Xác định cấu hình sai và đánh giá quyền truy cập kiểm soát truy cập dựa trên vai trò (RBAC) cho người dùng thông qua quản lý cấu hình,  để đảm bảo rằng cấu hình đáp ứng các phương pháp hay nhất.
  • Phát hiện và phản hồi thời gian chạy để tự động xác định các hành động bất thường có thể cho thấy vi phạm bảo mật hoặc sử dụng sai môi trường.

Để tìm hiểu thêm, hãy xem Giới thiệu ngắn gọn về Bảo mật cụm nâng cao Red Hat cho Kubernetes .

Lớp mạng

Lớp mạng là lớp ngoài cùng của kiến ​​trúc bảo mật. Mạng là nơi xảy ra hầu hết các cuộc tấn công bảo mật CNTT do cấu hình sai và lỗ hổng bảo mật. Lập kế hoạch và cấu hình thích hợp các thành phần của lớp an ninh mạng đảm bảo rằng môi trường được an toàn. Kubernetes có các điều khiển mạng (SDN) do phần mềm xác định có thể cải thiện an ninh mạng trong việc triển khai SaaS. Red Hat OpenShift cung cấp các điều khiển bổ sung dựa trên những gì có sẵn trong Kubernetes.

Chính sách mạng

Chính sách mạng kiểm soát lưu lượng giữa các nhóm bằng cách xác định các quyền mà chúng cần để giao tiếp với các nhóm và điểm cuối mạng khác. OpenShift mở rộng các chính sách bằng cách nhóm các thành phần và quy tắc vào các bộ sưu tập một cách hợp lý để dễ dàng quản lý.

Điều đáng chú ý là các chính sách mạng có tính chất phụ gia. Do đó, khi bạn tạo nhiều chính sách trên một hoặc nhiều nhóm, sự kết hợp của tất cả các quy tắc được áp dụng bất kể thứ tự mà bạn liệt kê chúng. Hành vi nhóm kết quả phản ánh mọi quy tắc cho phép và từ chối đối với việc xâm nhập và đi ra.

Giao diện mạng vùng chứa

Trong một cụm Kubernetes, theo mặc định, các nhóm được gắn vào một mạng duy nhất và có một giao diện mạng vùng chứa (CNI). CNI quản lý kết nối mạng của các vùng chứa và loại bỏ tài nguyên khi vùng chứa bị xóa.

Kubernetes sử dụng các plugin SDN để triển khai CNI. Họ quản lý tài nguyên của giao diện mạng cho các nhóm mới. Các plugin CNI thiết lập cấu trúc mạng phù hợp cho giao tiếp từ nhóm đến nhóm và nhóm với bên ngoài và thực thi các chính sách mạng.

Các tính năng bảo mật mạng Openshift

OpenShift cung cấp các tính năng và thành phần bổ sung sau để bảo mật mạng cho việc triển khai gốc đám mây:

  • Hoạt động mạng: OpenShift bao gồm một tập hợp các nhà khai thác quản lý các thành phần mạng để thực thi các phương pháp hay nhất và giảm thiểu lỗi do con người gây ra.
  • Nhiều giao diện mạng: Kubernetes mặc định dành cho tất cả các nhóm sử dụng một mạng và một giao diện mạng chính, nhưng với OpenShift, bạn có thể định cấu hình các giao diện mạng bổ sung. Điều này cho phép tối ưu hóa mạng để cải thiện hiệu suất và tăng cường cách ly để cải thiện bảo mật.
  • Cải tiến bảo mật khi xâm nhập: OpenShift hiển thị cụm với các tài nguyên bên ngoài hoặc máy khách thông qua tài nguyên định tuyến . Các tuyến cung cấp các tính năng nâng cao không có trong bộ điều khiển Kubernetes Ingress tiêu chuẩn, bao gồm mã hóa lại TLS, chuyển qua TLS và phân chia lưu lượng để triển khai màu xanh lam.
  • Cải tiến bảo mật đầu ra: Trong khi quy tắc OpenShift mặc định cho phép tất cả lưu lượng truy cập rời khỏi cụm mà không có hạn chế, OpenShift có các công cụ để kiểm soát chi tiết và lọc lưu lượng ra ngoài. OpenShift cho phép bạn kiểm soát lưu lượng truy cập thông qua tường lửa đi ra , bộ định tuyến đầu ra và đi ra địa chỉ IP tĩnh .
  • Lưới dịch vụ: Red Hat OpenShift Service Mesh, dựa trên dự án Istio , thêm một lớp trong suốt vào các dịch vụ mạng ứng dụng hiện có đang chạy trong một cụm, cho phép quản lý và giám sát phức tạp mà không yêu cầu thay đổi dịch vụ. Lưới dịch vụ thực hiện điều này bằng cách triển khai proxy trợ giúp cùng với các dịch vụ liên quan để chặn và quản lý tất cả các giao tiếp mạng. Với Red Hat OpenShift Service Mesh, bạn có thể tạo một mạng với các dịch vụ sau: khám phá, cân bằng tải, xác thực dịch vụ-dịch vụ, khôi phục lỗi, chỉ số, giám sát, thử nghiệm A / B, phát hành canary, giới hạn tốc độ, kiểm soát truy cập, và xác thực end-to-end.

Để biết thêm thông tin, hãy xem Hướng dẫn bảo mật OpenShift của Red Hat .

Hợp tác với Red Hat để xây dựng SaaS của bạn

Bài viết này đề cập đến các biện pháp kiểm soát có thể được sử dụng để cải thiện tính bảo mật của việc triển khai SaaS của bạn ở cấp phần cứng, Hệ điều hành, vùng chứa, cụm Kubernetes và mạng. Các bài viết trong tương lai sẽ đi sâu hơn về các chủ đề bảo mật của SaaS.

Red Hat SaaS Foundations là một chương trình đối tác được thiết kế để xây dựng nền tảng SaaS cấp doanh nghiệp trên Red Hat OpenShift hoặc Red Hat Enterprise Linux và triển khai chúng trên nhiều đám mây và phi đám mây. Gửi email cho chúng tôi để tìm hiểu thêm.

Liên kết: https://developers.redhat.com/articles/2022/07/27/saas-security-kubernetes-enosystem-layered-approach#partner_with_red_hat_to_build_your_saas

#sass #kubernetes #redhat

Bảo Mật SaaS Trong Môi Trường Kubernetes

Многоуровневый подход к обеспечению безопасности SaaS среде Kubernetes

Безопасность особенно важна для сред « программное обеспечение как услуга» (SaaS) , где платформа используется многими разными людьми, которым нужна уверенность в том, что их данные хранятся в безопасности и защищены от посторонних пользователей. В этой статье основное внимание уделяется проблемам безопасности для контейнеров в развертывании SaaS, работающем в средах Kubernetes , таких как Red Hat OpenShift . Эта статья является пятой в серии контрольных списков по архитектуре SaaS , в которой рассматриваются вопросы программного обеспечения и развертывания приложений SaaS.

Средства контроля и практики безопасности для SaaS

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

Уровни SaaS и их функции безопасности в Kubernetes и OpenShift.

Рисунок 1: Уровни SaaS и их функции безопасности в Kubernetes и OpenShift.

Безопасность необходимо решать на каждом уровне, поскольку любая уязвимость на одном уровне может быть использована для компрометации других уровней. Для каждого уровня в Kubernetes и OpenShift есть элементы управления безопасностью и функции, которые будут рассмотрены в этой статье. В следующих статьях будут более подробно рассмотрены конкретные темы безопасности SaaS. Если есть какие-либо темы SaaS, по которым вы хотели бы увидеть статью, сообщите нам об этом в комментариях.

Безопасность на аппаратном уровне

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

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

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

Облачные HSM доступны у основных поставщиков облачных услуг для обеспечения повышенной защиты в облачных средах. HSM рекомендуется для управления секретами в средах SaaS.

Защитите доступ к серверу, включив безопасную загрузку и используя пароли уровня BIOS. Безопасная загрузка — это функция безопасности встроенного программного обеспечения Unified Extensible Firmware Interface (UEFI), которая гарантирует, что во время загрузки может запускаться только неизменное и подписанное программное обеспечение.

Для получения дополнительной информации, проверьте:

Безопасность операционной системы

Каждый кластер Kubernetes работает поверх некоторой базовой операционной системы (ОС). Функции безопасности и усиление на уровне ОС помогают защитить кластер в целом, поэтому важно включить и использовать элементы управления на уровне ОС.

Когда дело доходит до усиления безопасности на уровне ОС, Red Hat OpenShift имеет два явных преимущества. Во- первых, Linux с улучшенной безопасностью (SELinux) интегрирован и включен из коробки. Во-вторых, OpenShift работает на Red Hat Enterprise Linux CoreOS, уникальном образе ОС, настроенном для использования SaaS.

Linux с повышенной безопасностью

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

Таким образом, одной из наиболее эффективных мер безопасности является включение и настройка SELinux, который Red Hat сделал стандартным для всех кластеров OpenShift. Рекомендуется использовать SELinux в средах SaaS. В OpenShift SELinux повышает безопасность контейнеров, обеспечивая истинное разделение контейнеров и обязательный контроль доступа.

Для получения дополнительной информации см.:

Усиленная ОС для контейнеров: Red Hat Enterprise Linux CoreOS

Операционная система OpenShift, Red Hat Enterprise Linux CoreOS, основана на Red Hat Enterprise Linux и использует то же ядро, код и процессы разработки с открытым исходным кодом. Эта специальная версия поставляется с определенным подмножеством пакетов Red Hat Enterprise Linux, предназначенных для использования в кластерах OpenShift 4. Основные функции, которые делают эту операционную систему более безопасной:

На основе Red Hat Enterprise Linux: базовая ОС состоит в основном из компонентов Red Hat Enterprise Linux, что означает, что она имеет такое же качество, безопасность, меры контроля и поддержку. Когда исправление отправляется в Red Hat Enterprise Linux, то же самое исправление передается в Red Hat Enterprise Linux CoreOS.

Контролируемая неизменяемость: Red Hat Enterprise Linux CoreOS управляется через API OpenShift, что обеспечивает более ручное управление операционной системой. Управление в основном выполняется массово для всех узлов кластера OpenShift. Последнее состояние системы Red Hat Enterprise Linux CoreOS хранится в кластере, что упрощает добавление новых узлов или отправку обновлений на все узлы. Учитывая централизованное управление и транзакционный характер ОС, в установке Red Hat Enterprise Linux CoreOS можно изменить лишь несколько системных параметров.

Контейнерные инструменты командной строки: Red Hat Enterprise Linux CoreOS включает контейнерные инструменты, совместимые со спецификацией Open Container Initiative (OCI), для создания, копирования и управления образами контейнеров. Многие функции администрирования среды выполнения контейнеров доступны через Podman. Команда skopeo копирует, аутентифицирует и подписывает изображения. Команда crictl позволяет просматривать контейнеры и модули и устранять неполадки.

Надежные транзакционные обновления: Red Hat Enterprise Linux CoreOS предлагает процесс обновления rpm-ostree , который гарантирует атомарное обновление. Если что-то пойдет не так, исходную ОС можно будет восстановить за один откат.

OpenShift обрабатывает обновления ОС через оператора конфигурации машины (MCO), который включает в себя полное обновление ОС, а не отдельные пакеты, как в традиционных обновлениях Yum. OpenShift также обновляет узлы с помощью непрерывного обновления, чтобы смягчить влияние обновлений и сохранить емкость кластера. Во время установки и обновлений последнее неизменяемое дерево файловой системы считывается из образа контейнера, записывается на диск и загружается в загрузчик. Машина перезагрузится в новую версию ОС, гарантируя атомарное обновление.

Безопасность во время установки кластера: Red Hat Enterprise Linux CoreOS сводит к минимуму принятие решений о безопасности во время установки. Две функции безопасности считаются решениями перед первой загрузкой для операций кластера: поддержка криптографии FIPS и полного шифрования диска (FDE). После загрузки кластера его можно дополнительно настроить для других изменений на уровне узла.

Контейнерный слой

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

Red Hat OpenShift имеет множество функций, повышающих безопасность контейнеров для многопользовательских сред.

Контейнерный двигатель

Механизм контейнеров предоставляет инструменты для создания образов контейнеров и запуска контейнеров. В OpenShift контейнерным движком по умолчанию является CRI-O , который поддерживает контейнеры, соответствующие OCI и libcontainerd. Движок контейнера фокусируется на функциях, необходимых интерфейсу среды выполнения контейнеров (CRI) Kubernetes. Этот настраиваемый механизм контейнера сокращает поверхность, доступную для атаки на систему безопасности, поскольку механизм контейнера не содержит ненужных функций, таких как прямое использование командной строки или средства оркестровки.

Мы также больше согласовали CRI с Kubernetes: обновления CRI-O сделаны для лучшей работы с текущим выпуском Kubernetes.

Безопасность контейнеров в ядре Linux

Ядро предлагает функции для обеспечения безопасности контейнеров и всего остального, работающего в ОС. Во-первых, все контейнеры запускаются внутри пространства имен, которое создает изолированную песочницу, разделяющую контейнеры, файловые системы, процессы и сеть.

Следующей функцией являются контрольные группы (cgroups), которые изолируют совместное использование аппаратных ресурсов между контейнерами и узлами кластера OpenShift. Использование контрольных групп не позволяет какому-либо отдельному процессу или контейнеру использовать все доступные ресурсы на хосте.

Наконец, как мы обсуждали ранее, Red Hat Enterprise Linux CoreOS включает SELinux, который не позволяет контейнеру нарушать свою изоляцию и тем самым косвенно мешать другим контейнерам на том же хосте.

Кластерная безопасность в Kubernetes и Red Hat OpenShift

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

Изоляция плоскости управления

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

Управление идентификацией

Каждый кластер Kubernetes нуждается в той или иной форме управления идентификацией. По умолчанию Red Hat OpenShift поставляется с провайдером OAuth по умолчанию , который используется для аутентификации на основе токенов. У этого поставщика есть одна kubeadminучетная запись пользователя, которую можно использовать для настройки поставщика удостоверений с помощью пользовательского ресурса (CR) . OpenShift поддерживает  поставщиков удостоверений стандарта OpenID Connect  и LDAP. После определения удостоверений используйте управление доступом на основе ролей (RBAC) для определения и применения разрешений.

Контроль доступа к кластеру

Прежде чем пользователи взаимодействуют с кластером, они сначала должны пройти аутентификацию через сервер OAuth. Внутренние подключения к серверу API аутентифицируются с использованием сертификатов X.509.

Ограничения контекста безопасности

Ограничения контекста безопасности (SCC) — это функция безопасности OpenShift, которая ограничивает доступ к ресурсам модуля и допустимые действия. SCC позволяют администраторам контролировать большую часть конфигурации модуля, например контекст SELinux контейнера, может ли модуль запускать привилегированные контейнеры и использование каталогов узлов в качестве томов. В OpenShift SCC включены по умолчанию и не могут быть отключены. SCC могут улучшить изоляцию в развертываниях SaaS и уменьшить влияние потенциальных уязвимостей.

SCC пода определяются группой, к которой принадлежит пользователь, а также учетной записью службы, если она указана. По умолчанию рабочие узлы и работающие на них модули получают тип SCC restricted. Этот тип SCC не позволяет модулям работать как привилегированные и требует, чтобы они работали под UID, который выбирается во время выполнения из предварительно выделенного диапазона UID.

Секреты

В развертываниях SaaS арендаторам необходимо защитить свои конфиденциальные данные в кластере. Это обрабатывается секретными объектами в OpenShift. Секретные объекты содержат конфиденциальную информацию, такую ​​как пароли, файлы конфигурации клиента OCP, учетные данные частного исходного репозитория и т. д. Такой способ использования секретных объектов отделяет конфиденциальное содержимое от модулей.

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

  • Секретные данные могут создаваться одним объектом, например инструментом настройки, и использоваться другим объектом, например приложением.
  • Секретные тома данных поддерживаются временными хранилищами файлов (tmpfs) и никогда не остаются на узле.
  • Секретные данные могут совместно использоваться в пространстве имен.
  • Секретные данные могут быть дополнительно зашифрованы в состоянии покоя .

Для получения дополнительной информации прочитайте Предоставление конфиденциальных данных модулям .

Red Hat Advanced Cluster Security для Kubernetes

Помимо стандартных функций безопасности Red Hat OpenShift, Red Hat предлагает дополнительные продукты для повышения безопасности платформы. Одним из них является Red Hat Advanced Cluster Security для Kubernetes (ранее StackRox). Red Hat Advanced Cluster Security для Kubernetes защищает ваши жизненно важные приложения на этапах сборки, развертывания и выполнения. Он развертывается в вашей инфраструктуре и легко интегрируется с инструментами и рабочими процессами DevOps . Эта интеграция упрощает применение политик безопасности и соответствия требованиям.

Red Hat Advanced Cluster Security дополняет встроенную безопасность OpenShift, улучшая следующие основные элементы безопасности:

  • Улучшение видимости среды, чтобы администраторам было легче обнаруживать проблемы по мере их возникновения.
  • Управление уязвимостями после их обнаружения путем развертывания исправлений через интегрированный конвейер CI/CD .
  • Обеспечение соответствия отраслевым стандартам и лучшим практикам.
  • Добавление надежной сегментации сети для ограничения сетевого трафика только необходимыми пользователями.
  • Ранжирование каждого развертывания на основе рисков для определения вероятности угрозы безопасности, помогая гарантировать, что развертывания с самым высоким риском получат немедленное исправление в первую очередь.
  • Выявление неправильных конфигураций и оценка доступа к управлению доступом на основе ролей (RBAC) для пользователей с помощью управления конфигурацией,  чтобы убедиться, что конфигурация соответствует передовым практикам.
  • Обнаружение во время выполнения и реагирование для автоматического выявления ненормальных действий, которые могут указывать на нарушение безопасности или неправильное использование среды.

Чтобы узнать больше, см . Краткое введение в Red Hat Advanced Cluster Security для Kubernetes .

Сетевой уровень

Сетевой уровень — это самый внешний уровень архитектуры безопасности. Сеть — это место, где происходит большинство атак на ИТ-безопасность из-за неправильной конфигурации и уязвимостей. Надлежащее планирование и конфигурация компонентов уровня сетевой безопасности обеспечивают безопасность среды. Kubernetes имеет элементы управления программно-определяемой сетью (SDN), которые могут повысить сетевую безопасность в развертываниях SaaS. Red Hat OpenShift предоставляет дополнительные элементы управления, основанные на том, что доступно в Kubernetes.

Сетевая политика

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

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

Контейнерный сетевой интерфейс

В кластере Kubernetes по умолчанию модули подключены к одной сети и имеют единый сетевой интерфейс контейнера (CNI). CNI управляет сетевым подключением контейнеров и удаляет ресурсы при удалении контейнеров.

Kubernetes использует плагины SDN для реализации CNI. Они управляют ресурсами сетевых интерфейсов для новых модулей. Плагины CNI настраивают надлежащие сетевые конструкции для связи между модулями и модулями с внешними устройствами и применяют сетевые политики.

Функции сетевой безопасности Openshift

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

  • Сетевые операции: OpenShift включает в себя набор операторов, которые управляют сетевыми компонентами, чтобы обеспечить соблюдение лучших практик и минимизировать человеческие ошибки.
  • Несколько сетевых интерфейсов: по умолчанию в Kubernetes все модули используют одну сеть и один основной сетевой интерфейс, но с OpenShift вы можете настроить дополнительные сетевые интерфейсы. Это позволяет оптимизировать сеть для повышения производительности и усиливает изоляцию для повышения безопасности.
  • Усовершенствования безопасности входа: OpenShift предоставляет кластер внешним ресурсам или клиентам через ресурс маршрута . Маршруты предоставляют расширенные функции, которых нет в стандартном контроллере Kubernetes Ingress, включая повторное шифрование TLS, сквозную передачу TLS и разделение трафика для сине-зеленых развертываний.
  • Улучшения безопасности исходящего трафика: несмотря на то, что правило OpenShift по умолчанию позволяет всему исходящему трафику покидать кластер без ограничений, в OpenShift есть инструменты для детального контроля и фильтрации исходящего трафика. OpenShift позволяет контролировать исходящий трафик через исходящий брандмауэр , исходящие маршрутизаторы и исходящие статические IP-адреса .
  • Сервисная сетка: Red Hat OpenShift Service Mesh, основанная на проекте Istio , добавляет прозрачный уровень к существующим сетевым службам приложений, работающим в кластере, обеспечивая комплексное управление и мониторинг без необходимости внесения изменений в службы. Сервисная сетка делает это путем развертывания вспомогательного прокси-сервера вместе с соответствующими службами для перехвата и управления всеми сетевыми коммуникациями. С помощью Red Hat OpenShift Service Mesh вы можете создать сеть со следующими службами: обнаружение, балансировка нагрузки, межсервисная аутентификация, восстановление после отказа, метрики, мониторинг, A/B-тестирование, канареечные выпуски, ограничение скорости, контроль доступа, и сквозная аутентификация.

Для получения дополнительной информации см . Руководство по безопасности Red Hat OpenShift .

Станьте партнером Red Hat для создания своего SaaS

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

Red Hat SaaS Foundations — это партнерская программа, предназначенная для создания платформ SaaS корпоративного уровня на Red Hat OpenShift или Red Hat Enterprise Linux и развертывания их в нескольких облачных и необлачных средах. Напишите нам, чтобы узнать больше.

Ссылка: https://developers.redhat.com/articles/2022/07/27/saas-security-kubernetes-environments-layered-approach#partner_with_red_hat_to_build_your_saas

#sass #kubernetes #redhat

Многоуровневый подход к обеспечению безопасности SaaS среде Kubernetes
山田  千代

山田 千代

1659340380

在 Kubernetes 環境中保護 SaaS 的分層方法

安全性對於軟件即服務 (SaaS)環境尤其重要,在該環境中,許多不同的人都在使用該平台,他們需要確信他們的數據被安全地存儲並且對無關用戶保密。本文重點介紹在Red Hat OpenShift等Kubernetes環境中運行的 SaaS 部署中容器的安全問題。本文是稱為SaaS 架構清單的系列文章的第五篇,該清單涵蓋了 SaaS 應用程序的軟件和部署注意事項。

SaaS 的安全控制和實踐

在現代企業環境中,需要將安全性構建到規劃、開發、運營和維護的整個生命週期中。良好的安全控制和實踐對於滿足合規性和監管要求以及確保交易可靠和高性能至關重要。SaaS 中的安全性可以分為五個主要層:硬件、操作系統、容器、Kubernetes 和網絡。圖 1 顯示了這些層以及解決每一層威脅的安全控制。

SaaS 層及其在 Kubernetes 和 OpenShift 中的安全功能。

圖 1:Kubernetes 和 OpenShift 中的 SaaS 層及其安全功能。

需要在每一層解決安全問題,因為一層中的任何漏洞都可能被利用來破壞其他層。對於每一層,Kubernetes 和 OpenShift 都有本文將介紹的安全控制和功能。未來的文章將更詳細地介紹特定的 SaaS 安全主題。如果您想查看任何 SaaS 主題的文章,請在評論中告訴我們。

硬件層的安全性

保護 SaaS 環境的安全通常始於確定應用程序將在何處運行以及該環境的安全問題。安全環境包括實際的數據中心以及硬件本身,包括磁盤加密、安全啟動、BIOS 級密碼以及硬件安全模塊 (HSM) 的使用。本文稍後將討論秘密和身份管理。

雖然人們非常關注使用加密來保護通過網絡傳輸的數據,但保護靜態數據也很重要,因為它存儲在數據中心的物理存儲設備上。在您無法控制對設施的訪問以及可能僱用第三方承包商的數據中心,靜態數據的風險要高得多。使用磁盤加密保護存儲在物理服務器上的數據免受意外訪問,從而保護靜態數據。

HSM 通常是一種物理設備,它通過加密安全地存儲數字密鑰以保護敏感數據。HSM 用於在靜止和傳輸過程中管理和保護安全憑證、密鑰、證書和機密。HSM 提供了比僅軟件方法(例如機密保險庫)更高級別的保護。

雲 HSM 可從主要雲提供商處獲得,以在雲環境中提供增強的保護。建議使用 HSM 來管理 SaaS 環境中的機密。

通過啟用安全引導和使用 BIOS 級密碼保護對服務器的訪問。安全啟動是統一可擴展固件接口 (UEFI) 的固件安全功能,可確保在啟動期間只能運行不可變和簽名的軟件。

欲了解更多信息,請查看:

操作系統安全

每個 Kubernetes 集群都運行在一些底層操作系統 (OS) 之上。操作系統層的安全功能和強化有助於保護整個集群,因此啟用和使用操作系統級別的控制非常重要。

在操作系統級別的安全強化方面,紅帽 OpenShift 具有兩個明顯的優勢。首先,安全增強型 Linux (SELinux) 已集成並開箱即用。其次,OpenShift 在 Red Hat Enterprise Linux CoreOS 上運行,這是一種針對 SaaS 使用而調整的獨特操作系統映像。

安全性增強的 Linux

SELinux 是一種適用於Linux系統的安全架構,與默認 Linux 相比,它授予管理員對系統資源訪問權限的更細粒度的控制。SELinux 為系統上的應用程序、進程和文件定義了強制訪問控制。在 Kubernetes 節點上,SELinux 增加了一個重要的保護層來防止容器突破漏洞

因此,最有效的安全措施之一是啟用和配置 SELinux,Red Hat 已將其作為所有 OpenShift 集群的標準。在 SaaS 環境中使用 SELinux 被認為是最佳實踐。在 OpenShift 中,SELinux 通過確保真正的容器分離和強制訪問控制來增強容器安全性。

有關更多信息,請參閱:

用於容器的強化操作系統:Red Hat Enterprise Linux CoreOS

OpenShift 的操作系統 Red Hat Enterprise Linux CoreOS 基於 Red Hat Enterprise Linux 並使用相同的內核、代碼和開源開發流程。這個特殊版本附帶了特定的 Red Hat Enterprise Linux 軟件包子集,專為在 OpenShift 4 集群中使用而設計。使該操作系統更加安全的關鍵特性是:

基於 Red Hat Enterprise Linux:底層操作系統主要是 Red Hat Enterprise Linux 組件,這意味著它具有相同的質量、安全性、控制措施和支持。當一個修復被推送到 Red Hat Enterprise Linux 時,同樣的修復被推送到 Red Hat Enterprise Linux CoreOS。

受控不變性:Red Hat Enterprise Linux CoreOS 通過 OpenShift API 進行管理,從而實現了更多的操作系統管理。管理主要針對整個 OpenShift 集群中的所有節點批量執行。Red Hat Enterprise Linux CoreOS 系統的最新狀態存儲在集群上,便於添加新節點或向所有節點推送更新。鑑於操作系統的集中管理和事務性質,在 Red Hat Enterprise Linux CoreOS 安裝上只能修改少數係統設置。

命令行容器工具:紅帽企業 Linux CoreOS 包括與開放容器倡議(OCI) 規範兼容的容器工具,用於構建、複製和管理容器鏡像。Podman 提供了許多容器運行時管理功能。skopeo命令複製、驗證和簽署圖像。crictl命令可讓您查看容器和 Pod 並對其進行故障排除

強大的事務更新:紅帽企業 Linux CoreOS 提供rpm-ostree升級過程,確保升級以原子方式進行。如果出現問題,可以在一次回滾中恢復原始操作系統。

OpenShift 通過Machine Config Operator (MCO) 處理操作系統升級,其中包括完整的操作系統升級,而不是像傳統 Yum 升級中的單個軟件包。OpenShift 還通過滾動更新來更新節點,以減輕更新的影響並保持集群容量。在安裝和升級期間,從容器鏡像中讀取最新的不可變文件系統樹,寫入磁盤,然後加載到引導加載程序。機器將重新啟動到新的操作系統版本,保證原子更新。

集群安裝期間的安全性:紅帽企業 Linux CoreOS 最大限度地減少了安裝期間的安全決策。兩個安全特性被認為是集群操作的首次啟動決策:支持 FIPS 加密和全盤加密 (FDE)。集群啟動後,可以進一步配置集群以進行其他節點級別的更改。

容器層

Kubernetes 和 OpenShift 中的容器層將進程彼此以及與底層操作系統隔離開來。與傳統的軟件設計不同,所有組件都鏈接、部署在一起並最終相互依賴,容器是獨立的,因此影響更小。如果一個容器出現故障,可以輕鬆更換。如果發現容器鏡像存在安全漏洞,該漏洞將與該鏡像隔離,並且只需要更新該鏡像而不是整個集群。

紅帽 OpenShift 具有許多可提高多租戶環境容器安全性的功能。

容器引擎

容器引擎提供了用於創建容器鏡像和啟動容器的工具。在 OpenShift 中,默認的容器引擎是CRI-O,它支持符合 OCI 和 libcontainerd 的容器。容器引擎專注於 Kubernetes 的容器運行時接口(CRI) 所需的功能。這種定制的容器引擎縮小了可用於安全攻擊的表面,因為容器引擎不包含不需要的功能,例如直接命令行使用或編排設施。

我們還使 CRI 與 Kubernetes 更加一致:對 CRI-O 的更新可以更好地與當前的 Kubernetes 版本配合使用。

Linux 內核中的容器安全性

內核提供了確保容器和操作系統上運行的所有其他內容的安全性的功能。首先,所有容器都在一個命名空間內啟動,該命名空間創建了一個隔離容器、文件系統、進程和網絡的隔離沙箱。

下一個特性是控制組(cgroups),它隔離了 OpenShift 集群的容器和節點之間的硬件資源共享。cgroups 的使用可以防止任何單個進程或容器用盡主機上的所有可用資源。

最後,正如我們之前所討論的,Red Hat Enterprise Linux CoreOS 啟用了 SELinux,它可以防止容器打破其隔離,從而間接干擾同一主機上的其他容器。

Kubernetes 和 Red Hat OpenShift 上的集群安全性

集群級別控制 Kubernetes 如何部署主機、管理共享資源、控制容器間通信、管理擴展以及控制對集群的訪問。OpenShift 集群由控制平面、工作節點和所需的任何其他資源組成。以下小節介紹了集群不同方面的一些安全問題。

控制平面隔離

將集群的控制平面節點與工作節點隔離開來被認為是最佳實踐。這通常使用控制平面的單獨硬件來完成,以減輕任何錯誤配置、資源管理問題或漏洞的影響。

身份管理

每個 Kubernetes 集群都需要某種形式的身份管理。開箱即用,Red Hat OpenShift 帶有一個默認的OAuth提供程序,用於基於令牌的身份驗證。此提供者有一個kubeadmin用戶帳戶,您可以使用它通過自定義資源 (CR) 配置身份提供者。OpenShift 支持 OpenID Connect 和 LDAP 標準身份提供程序。定義身份後,使用基於角色的訪問控制 (RBAC) 來定義和應用權限。

集群訪問控制

在用戶與集群交互之前,他們首先必須通過 OAuth 服務器進行身份驗證。與 API 服務器的內部連接使用 X.509 證書進行身份驗證。

安全上下文約束

安全上下文約束(SCC) 是一種 OpenShift 安全功能,可限制 pod 的資源訪問和允許的操作。SCC 讓管理員可以控制 Pod 的大部分配置,例如容器的 SELinux 上下文、Pod 是否可以運行特權容器以及將主機目錄用作卷。在 OpenShift 中,SCC 默認啟用且無法禁用。SCC 可以提高 SaaS 部署中的隔離性並減少潛在漏洞的影響。

Pod SCC 由用戶所屬的組以及服務帳戶(如果指定)確定。默認情況下,工作節點和在其上運行的 pod 接收 SCC 類型的restricted. 此 SCC 類型可防止 pod 以特權身份運行,並要求它們在運行時從預先分配的 UID 範圍中選擇的 UID 下運行。

秘密

在 SaaS 部署中,租戶需要保護集群上的敏感數據。這由 OpenShift 上的 Secret 對象處理。Secret 對象保存敏感信息,例如密碼、OCP 客戶端配置文件、私有源存儲庫憑據等。使用 Secret 對象的這種方式將敏感內容與 pod 分離。

當需要敏感內容時,可以通過卷插件將其掛載到容器中,或者係統可以使用秘密來代表 pod 執行操作。機密的關鍵屬性包括:

  • 秘密數據可以由一個實體(例如配置工具)創建,並由另一個實體(例如應用程序)引用。
  • 秘密數據卷由臨時文件存儲設施 (tmpfs) 支持,並且永遠不會停留在節點上。
  • 秘密數據可以在命名空間內共享。
  • 秘密數據可以選擇在靜態加密

有關更多信息,請閱讀為 pod 提供敏感數據

紅帽 Kubernetes 高級集群安全

除了紅帽 OpenShift 中的標準安全功能外,紅帽還提供其他產品來增強平台的安全性。其中之一是Red Hat Advanced Cluster Security for Kubernetes(以前的 StackRox)。Red Hat Advanced Cluster Security for Kubernetes 可在構建、部署和運行時階段保護您的重要應用程序。它部署在您的基礎架構中,並輕鬆與DevOps工具和工作流集成。這種集成使應用安全和合規策略變得容易。

Red Hat Advanced Cluster Security 通過改進以下安全核心租戶來增加 OpenShift 的內置安全性:

  • 提高環境的可見性,因此管理員可以更輕鬆地在問題發生時檢測到問題。
  • 一旦通過集成的CI/CD管道部署修復程序來識別漏洞,就可以對其進行管理。
  • 確保符合行業標準和最佳實踐。
  • 添加強大的網絡分段以將網絡流量限制為僅用於必要的用途。
  • 對每個部署進行基於風險的排名,以確定安全風險的可能性,幫助確保風險最高的部署首先得到即時補救。
  • 通過配置管理 識別錯誤配置並評估用戶的基於角色的訪問控制 (RBAC) 訪問,以確保配置符合最佳實踐。
  • 運行時檢測和響應,以自動識別可能表明安全漏洞或環境濫用的異常操作。

要了解更多信息,請參閱Red Hat Advanced Cluster Security for Kubernetes 簡介

網絡層

網絡層是安全架構的最外層。由於配置錯誤和漏洞,網絡是大多數 IT 安全攻擊發生的地方。正確規劃和配置網絡安全層組件可確保環境安全。Kubernetes 具有軟件定義網絡 (SDN) 控件,可以提高 SaaS 部署中的網絡安全性。紅帽 OpenShift 提供了基於 Kubernetes 可用功能的額外控制。

網絡政策

網絡策略通過定義 Pod 與其他 Pod 和網絡端點通信所需的權限來控制 Pod 之間的流量。OpenShift 通過將組件和規則邏輯分組到集合中來擴展策略,以便於管理。

值得注意的是,網絡策略是相加的。因此,當您在一個或多個 Pod 上創建多個策略時,無論您列出它們的順序如何,都會應用所有規則的並集。生成的 pod 行為反映了入口和出口的每個允許和拒絕規則。

容器網絡接口

在 Kubernetes 集群中,默認情況下,Pod 連接到單個網絡並具有單個容器網絡接口 (CNI)。CNI 管理容器的網絡連接,並在容器被刪除時移除資源。

Kubernetes 使用 SDN 插件來實現 CNI。他們管理新 pod 的網絡接口資源。CNI 插件為 pod 到 pod 和 pod 到外部通信設置了適當的網絡結構,並強制執行網絡策略。

Openshift 網絡安全功能

OpenShift 提供以下附加功能和組件來保護雲原生部署的網絡:

  • 網絡運營:OpenShift 包含一組運營商,用於管理網絡組件以實施最佳實踐並減少人為錯誤。
  • 多個網絡接口:Kubernetes 默認讓所有 pod 使用一個網絡和一個主網絡接口,但使用 OpenShift,您可以配置額外的網絡接口。這允許網絡優化以提高性能並增強隔離以提高安全性。
  • 入口安全性增強:OpenShift 通過路由資源將集群暴露給外部資源或客戶端。路由提供標準 Kubernetes Ingress 控制器中沒有的高級功能,包括 TLS 重新加密、TLS 直通和用於藍綠部署的拆分流量。
  • 出口安全性增強:雖然默認 OpenShift 規則允許所有出口流量不受限制地離開集群,但 OpenShift 具有用於細粒度控制和過濾出站流量的工具。OpenShift 允許您通過出口防火牆出口路由器出口靜態 IP 地址控制出口流量。
  • 服務網格:紅帽 OpenShift 服務網格基於Istio項目,為集群中運行的現有應用網絡服務添加了透明層,無需更改服務即可實現複雜的管理和監控。服務網格通過在相關服務旁邊部署 sidecar 代理來攔截和管理所有網絡通信來實現這一點。使用 Red Hat OpenShift Service Mesh,您可以創建具有以下服務的網絡:發現、負載平衡、服務到服務身份驗證、故障恢復、指標、監控、A/B 測試、金絲雀發布、速率限制、訪問控制、和端到端的身份驗證。

有關更多信息,請參閱紅帽 OpenShift 安全指南

與紅帽合作構建您的 SaaS

本文介紹了可用於在硬件、操作系統、容器、Kubernetes 集群和網絡級別提高 SaaS 部署安全性的控件。未來的文章將更深入地探討 SaaS 安全主題。

Red Hat SaaS Foundations是一個合作夥伴計劃,旨在在 Red Hat OpenShift 或 Red Hat Enterprise Linux 上構建企業級 SaaS 平台,並將它們部署到多個雲和非雲足跡。給我們發電子郵件以了解更多信息。

鏈接:https ://developers.redhat.com/articles/2022/07/27/saas-security-kubernetes-environments-layered-approach#partner_with_red_hat_to_build_your_saas

#sass #kubernetes #redhat

在 Kubernetes 環境中保護 SaaS 的分層方法
Hans  Marvin

Hans Marvin

1659333000

A Layered Approach to Secure SaaS in A Kubernetes Environment

Security is especially critical for Software-as-a-Service (SaaS) environments, where the platform is used by many different people who need the confidence that their data is stored safely and kept private from unrelated users. This article focuses on security concerns for containers on your SaaS deployment running in Kubernetes environments such as Red Hat OpenShift. The article is the fifth in a series called the SaaS architecture checklist that covers the software and deployment considerations for SaaS applications.

In this guide, We will share A Layered Approach to Secure SaaS in A Kubernetes Environment

See more at: https://developers.redhat.com/articles/2022/07/27/saas-security-kubernetes-environments-layered-approach#

#sass #kubernetes #redhat

A Layered Approach to Secure SaaS in A Kubernetes Environment
Thierry  Perret

Thierry Perret

1659325624

Une Approche En Couches Pour Sécuriser Le SaaS Dans Un Env Kubernetes

La sécurité est particulièrement critique pour les environnements Software-as-a-Service (SaaS) , où la plate-forme est utilisée par de nombreuses personnes différentes qui ont besoin de la confiance que leurs données sont stockées en toute sécurité et gardées privées des utilisateurs indépendants. Cet article se concentre sur les problèmes de sécurité des conteneurs sur votre déploiement SaaS exécuté dans des environnements Kubernetes tels que Red Hat OpenShift . L'article est le cinquième d'une série appelée la liste de contrôle de l'architecture SaaS qui couvre les considérations logicielles et de déploiement pour les applications SaaS.

Contrôles et pratiques de sécurité pour le SaaS

Dans les environnements d'entreprise modernes, la sécurité doit être intégrée dans le cycle de vie complet de la planification, du développement, des opérations et de la maintenance. De bons contrôles et pratiques de sécurité sont essentiels pour répondre aux exigences de conformité et réglementaires et garantir que les transactions sont fiables et performantes. La sécurité dans le SaaS peut être décomposée en cinq couches principales : matériel, système d'exploitation, conteneurs, Kubernetes et réseau. La figure 1 montre ces couches et les contrôles de sécurité qui traitent les menaces à chaque couche.

Couches SaaS et leurs fonctions de sécurité dans Kubernetes et OpenShift.

Figure 1 : Couches SaaS et leurs fonctions de sécurité dans Kubernetes et OpenShift.

La sécurité doit être abordée à chaque couche car toute vulnérabilité dans une couche pourrait être exploitée pour compromettre d'autres couches. Pour chaque couche, Kubernetes et OpenShift ont des contrôles et des fonctionnalités de sécurité qui seront couverts dans cet article. Les prochains articles entreront plus en détail sur des sujets spécifiques de sécurité SaaS. S'il y a des sujets SaaS pour lesquels vous aimeriez voir un article, faites-le nous savoir dans les commentaires.

Sécurité au niveau matériel

La sécurisation d'un environnement SaaS commence souvent par l'identification de l'endroit où l'application va s'exécuter et des problèmes de sécurité pour cet environnement. Un environnement sécurisé comprend le centre de données proprement dit ainsi que le matériel lui-même, y compris le chiffrement de disque, le démarrage sécurisé, les mots de passe au niveau du BIOS et l'utilisation de modules de sécurité matériels (HSM). Les secrets et la gestion des identités sont abordés plus loin dans cet article.

Bien qu'une grande attention soit accordée à l'utilisation du chiffrement pour protéger les données en transit lorsqu'elles transitent sur le réseau, il est également essentiel de protéger les données au repos car elles sont stockées sur des périphériques de stockage physiques dans les centres de données. Les risques pour les données au repos sont beaucoup plus élevés dans les centres de données où vous n'avez aucun contrôle sur l'accès à l'installation et où des sous-traitants tiers peuvent être employés. Utilisez le chiffrement de disque pour sécuriser les données au repos en protégeant les données stockées sur le serveur physique contre tout accès involontaire.

Un HSM est généralement un appareil physique qui stocke en toute sécurité des clés numériques par cryptage pour protéger les données sensibles. Les HSM sont utilisés pour gérer et protéger les identifiants de sécurité, les clés, les certificats et les secrets au repos et en transit. Le HSM offre un niveau de protection accru par rapport aux approches uniquement logicielles telles qu'un coffre-fort de secrets.

Les HSM cloud sont disponibles auprès des principaux fournisseurs de cloud pour fournir une protection accrue dans les environnements cloud. Les HSM sont recommandés pour gérer les secrets dans les environnements SaaS.

Protégez l'accès au serveur en activant le démarrage sécurisé et en utilisant des mots de passe au niveau du BIOS. Le démarrage sécurisé est une fonction de sécurité du micrologiciel de l'interface UEFI (Unified Extensible Firmware Interface) qui garantit que seuls les logiciels immuables et signés peuvent être exécutés lors du démarrage.

Pour plus d'informations, consultez :

Sécurité du système d'exploitation

Chaque cluster Kubernetes s'exécute sur un système d'exploitation (OS) sous-jacent. Les fonctions de sécurité et le renforcement au niveau de la couche du système d'exploitation aident à protéger l'ensemble du cluster. Il est donc important d'activer et d'utiliser les contrôles au niveau du système d'exploitation.

En matière de renforcement de la sécurité au niveau du système d'exploitation, Red Hat OpenShift présente deux avantages distincts. Tout d'abord, Security-Enhanced Linux (SELinux) est intégré et prêt à l'emploi. Deuxièmement, OpenShift s'exécute sur Red Hat Enterprise Linux CoreOS, une image de système d'exploitation unique adaptée à une utilisation SaaS.

Linux à sécurité renforcée

SELinux est une architecture de sécurité pour les systèmes Linux qui accorde aux administrateurs un contrôle plus précis sur l'accès aux ressources système que celui disponible avec Linux par défaut. SELinux définit les contrôles d'accès obligatoires pour les applications, les processus et les fichiers sur un système. Sur un nœud Kubernetes, SELinux ajoute une importante couche de protection contre les vulnérabilités de rupture de conteneur .

Ainsi, l'une des mesures de sécurité les plus efficaces consiste à activer et à configurer SELinux, que Red Hat a rendu standard sur tous les clusters OpenShift. Il est considéré comme une bonne pratique d'utiliser SELinux dans des environnements SaaS. Dans OpenShift, SELinux améliore la sécurité des conteneurs en assurant une véritable séparation des conteneurs et un contrôle d'accès obligatoire.

Pour plus d'informations, consultez :

Un système d'exploitation renforcé pour les conteneurs : Red Hat Enterprise Linux CoreOS

Le système d'exploitation d'OpenShift, Red Hat Enterprise Linux CoreOS, est basé sur Red Hat Enterprise Linux et utilise le même noyau, code et processus de développement open source. Cette version spéciale est livrée avec un sous-ensemble spécifique de packages Red Hat Enterprise Linux, conçus pour être utilisés dans les clusters OpenShift 4. Les principales caractéristiques qui rendent ce système d'exploitation plus sûr sont :

Basé sur Red Hat Enterprise Linux : le système d'exploitation sous-jacent est principalement constitué de composants Red Hat Enterprise Linux, ce qui signifie qu'il offre la même qualité, la même sécurité, les mêmes mesures de contrôle et la même prise en charge. Lorsqu'un correctif est transmis à Red Hat Enterprise Linux, ce même correctif est transmis à Red Hat Enterprise Linux CoreOS.

Immuabilité contrôlée : Red Hat Enterprise Linux CoreOS est géré via les API OpenShift, ce qui conduit à une gestion plus autonome du système d'exploitation. La gestion est principalement effectuée en masse pour tous les nœuds du cluster OpenShift. Le dernier état du système Red Hat Enterprise Linux CoreOS est stocké sur le cluster, ce qui facilite l'ajout de nouveaux nœuds ou l'envoi de mises à jour à tous les nœuds. Compte tenu de la gestion centralisée et de la nature transactionnelle du système d'exploitation, seuls quelques paramètres système peuvent être modifiés sur une installation Red Hat Enterprise Linux CoreOS.

Outils de conteneur en ligne de commande : Red Hat Enterprise Linux CoreOS inclut des outils de conteneur compatibles avec la spécification Open Container Initiative (OCI) pour créer, copier et gérer des images de conteneur. De nombreuses fonctionnalités d'administration du runtime de conteneur sont disponibles via Podman. La commande skopeo copie, authentifie et signe les images. La commande crictl vous permet d'afficher et de dépanner les conteneurs et les pods.

Mises à jour transactionnelles robustes : Red Hat Enterprise Linux CoreOS propose le processus de mise à niveau rpm-ostree , qui garantit qu'une mise à niveau a lieu de manière atomique. En cas de problème, le système d'exploitation d'origine peut être restauré en une seule restauration.

OpenShift gère les mises à niveau du système d'exploitation via Machine Config Operator (MCO), qui comprend une mise à niveau complète du système d'exploitation au lieu de packages individuels comme dans les mises à niveau traditionnelles de Yum. OpenShift met également à jour les nœuds via une mise à jour progressive pour atténuer l'impact des mises à jour et maintenir la capacité du cluster. Lors de l'installation et des mises à niveau, la dernière arborescence immuable du système de fichiers est lue à partir d'une image de conteneur, écrite sur le disque et chargée dans le chargeur de démarrage. La machine redémarrera dans la nouvelle version du système d'exploitation, garantissant une mise à jour atomique.

Sécurité lors de l'installation du cluster : Red Hat Enterprise Linux CoreOS minimise les décisions de sécurité lors de l'installation. Deux fonctionnalités de sécurité sont considérées comme des décisions de pré-premier démarrage pour les opérations de cluster : la prise en charge de la cryptographie FIPS et le chiffrement intégral du disque (FDE). Une fois le cluster amorcé, le cluster peut en outre être configuré pour d'autres modifications au niveau du nœud.

Couche conteneur

La couche de conteneur dans Kubernetes et OpenShift isole les processus les uns des autres et du système d'exploitation sous-jacent. Au lieu de la conception logicielle traditionnelle, où tous les composants sont liés, déployés ensemble et finalement dépendants les uns des autres, les conteneurs sont indépendants, ce qui réduit les impacts. Si un conteneur tombe en panne, il peut facilement être remplacé. S'il s'avère qu'une image de conteneur présente une faille de sécurité, la faille est isolée de cette image et nécessite la mise à jour de cette image uniquement plutôt que de l'ensemble du cluster.

Red Hat OpenShift possède de nombreuses fonctionnalités qui améliorent la sécurité des conteneurs pour les environnements mutualisés.

Moteur de conteneur

Un moteur de conteneur fournit des outils pour créer des images de conteneur et démarrer des conteneurs. Dans OpenShift, le moteur de conteneur par défaut est CRI-O , qui prend en charge les conteneurs conformes à OCI et libcontainerd. Le moteur de conteneur se concentre sur les fonctionnalités requises par l' interface d'exécution de conteneur (CRI) de Kubernetes. Ce moteur de conteneur personnalisé réduit la surface disponible pour une attaque de sécurité, car le moteur de conteneur ne contient pas de fonctionnalités inutiles telles que l'utilisation directe de la ligne de commande ou les fonctions d'orchestration.

Nous avons également davantage aligné le CRI sur Kubernetes : les mises à jour de CRI-O sont conçues pour mieux fonctionner avec la version actuelle de Kubernetes.

Sécurité des conteneurs dans le noyau Linux

Le noyau offre des fonctionnalités pour assurer la sécurité des conteneurs et de tout ce qui s'exécute sur le système d'exploitation. Tout d'abord, tous les conteneurs sont lancés dans un espace de noms qui crée un bac à sable isolé séparant les conteneurs, les systèmes de fichiers, les processus et la mise en réseau.

La fonctionnalité suivante concerne les groupes de contrôle (cgroups), qui isolent le partage des ressources matérielles entre les conteneurs et les nœuds du cluster OpenShift. L'utilisation de cgroups empêche tout processus ou conteneur d'utiliser toutes les ressources disponibles sur un hôte.

Enfin, comme nous l'avons vu précédemment, Red Hat Enterprise Linux CoreOS active SELinux, qui empêche un conteneur de rompre son isolement et donc d'interférer indirectement avec d'autres conteneurs sur le même hôte.

Sécurité des clusters sur Kubernetes et Red Hat OpenShift

Le niveau du cluster contrôle la manière dont Kubernetes déploie les hôtes, gère les ressources partagées, contrôle les communications entre conteneurs, gère la mise à l'échelle et contrôle l'accès au cluster. Un cluster OpenShift est composé d'un plan de contrôle, de nœuds de travail et de toutes les ressources supplémentaires nécessaires. Les sous-sections suivantes couvrent certains des problèmes de sécurité pour les différents aspects du cluster.

Isolation du plan de contrôle

Il est considéré comme une bonne pratique d'isoler les nœuds du plan de contrôle du cluster des nœuds de travail. Cela se fait généralement à l'aide d'un matériel distinct pour le plan de contrôle afin d'atténuer l'impact de toute mauvaise configuration, problèmes de gestion des ressources ou vulnérabilités.

Gestion des identités

Chaque cluster Kubernetes a besoin d'une certaine forme de gestion des identités. Prêt à l'emploi, Red Hat OpenShift est livré avec un fournisseur OAuth par défaut , qui est utilisé pour l'authentification basée sur les jetons. Ce fournisseur dispose d'un kubeadmincompte utilisateur unique, que vous pouvez utiliser pour configurer un fournisseur d'identité via une ressource personnalisée (CR) . OpenShift prend en charge  OpenID Connect  et les fournisseurs d'identité standard LDAP. Une fois les identités définies, utilisez le contrôle d'accès basé sur les rôles (RBAC) pour définir et appliquer les autorisations.

Contrôle d'accès au cluster

Avant que les utilisateurs n'interagissent avec le cluster, ils doivent d'abord s'authentifier via le serveur OAuth. Les connexions internes au serveur API sont authentifiées à l'aide de certificats X.509.

Contraintes liées au contexte de sécurité

Les contraintes de contexte de sécurité (SCC) sont une fonctionnalité de sécurité OpenShift qui limite l'accès aux ressources d'un pod et les actions autorisées. Les SCC permettent aux administrateurs de contrôler une grande partie de la configuration du pod, comme le contexte SELinux d'un conteneur, si un pod peut exécuter des conteneurs privilégiés et l'utilisation des répertoires hôtes en tant que volumes. Dans OpenShift, les SCC sont activés par défaut et ne peuvent pas être désactivés. Les SCC peuvent améliorer l'isolement dans les déploiements SaaS et réduire l'impact des vulnérabilités potentielles.

Les SCC de pod sont déterminés par le groupe auquel l'utilisateur appartient ainsi que par le compte de service, s'il est spécifié. Par défaut, les nœuds de travail et les pods qui y sont exécutés reçoivent un type SCC de restricted. Ce type SCC empêche les pods de s'exécuter en tant que privilégiés et les oblige à s'exécuter sous un UID sélectionné au moment de l'exécution dans une plage préallouée d'UID.

secrets

Dans les déploiements SaaS, les locataires doivent sécuriser leurs données sensibles sur le cluster. Ceci est géré avec des objets secrets sur OpenShift. Les objets secrets contiennent des informations sensibles telles que les mots de passe, les fichiers de configuration du client OCP, les informations d'identification du référentiel source privé, etc. Cette façon d'utiliser les objets secrets dissocie le contenu sensible des pods.

Lorsque le contenu sensible est nécessaire, il peut être monté sur le conteneur via un plug-in de volume, ou le système peut utiliser les secrets pour effectuer l'action au nom du pod. Les principales propriétés des secrets incluent :

  • Les données secrètes peuvent être créées par une entité, telle qu'un outil de configuration, et référencées par une autre, telle qu'une application.
  • Les volumes de données secrets sont soutenus par des installations de stockage de fichiers temporaires (tmpfs) et ne s'arrêtent jamais sur un nœud.
  • Les données secrètes peuvent être partagées au sein d'un espace de noms.
  • Les données secrètes peuvent éventuellement être chiffrées au repos .

Pour plus d'informations, consultez Fournir des données sensibles aux pods .

Red Hat Advanced Cluster Security pour Kubernetes

En plus des fonctions de sécurité standard de Red Hat OpenShift, Red Hat propose des produits supplémentaires pour améliorer la sécurité de la plate-forme. L'un d'entre eux est Red Hat Advanced Cluster Security pour Kubernetes (anciennement StackRox). Red Hat Advanced Cluster Security for Kubernetes protège vos applications vitales tout au long des étapes de construction, de déploiement et d'exécution. Il se déploie dans votre infrastructure et s'intègre facilement aux outils et workflows DevOps . Cette intégration facilite l'application des politiques de sécurité et de conformité.

Red Hat Advanced Cluster Security ajoute à la sécurité intégrée d'OpenShift en améliorant les principaux tenants de la sécurité suivants :

  • Amélioration de la visibilité de l'environnement, afin que les administrateurs puissent détecter plus facilement les problèmes au fur et à mesure qu'ils surviennent.
  • Gérer les vulnérabilités une fois qu'elles ont été identifiées en déployant des correctifs via un pipeline CI/CD intégré.
  • Assurer le respect des normes et des meilleures pratiques de l'industrie.
  • Ajout d'une segmentation réseau robuste pour limiter le trafic réseau aux seules utilisations nécessaires.
  • Un classement basé sur les risques de chaque déploiement pour déterminer la probabilité d'un risque de sécurité, aidant à garantir que les déploiements les plus à risque obtiennent d'abord une correction immédiate.
  • Identifier les erreurs de configuration et évaluer l'accès au contrôle d'accès basé sur les rôles (RBAC) pour les utilisateurs via la gestion de la configuration,  afin de garantir que la configuration respecte les meilleures pratiques.
  • Détection et réponse à l'exécution pour identifier automatiquement les actions anormales qui pourraient indiquer une faille de sécurité ou une mauvaise utilisation de l'environnement.

Pour en savoir plus, consultez A Brief Introduction to Red Hat Advanced Cluster Security for Kubernetes .

Couche réseau

La couche réseau est la couche la plus externe d'une architecture de sécurité. Le réseau est l'endroit où se produisent la plupart des attaques de sécurité informatique, en raison d'une mauvaise configuration et de vulnérabilités. Une planification et une configuration appropriées des composants de la couche de sécurité du réseau garantissent la sécurité de l'environnement. Kubernetes dispose de contrôles de réseau défini par logiciel (SDN) qui peuvent améliorer la sécurité du réseau dans les déploiements SaaS. Red Hat OpenShift fournit des contrôles supplémentaires qui s'appuient sur ce qui est disponible dans Kubernetes.

Politique de réseau

Une politique réseau contrôle le trafic entre les pods en définissant les autorisations dont ils ont besoin pour communiquer avec d'autres pods et points de terminaison du réseau. OpenShift étend les stratégies en regroupant logiquement les composants et les règles dans des collections pour une gestion facile.

Il convient de noter que les politiques de réseau sont additives. Par conséquent, lorsque vous créez plusieurs stratégies sur un ou plusieurs pods, l'union de toutes les règles est appliquée quel que soit l'ordre dans lequel vous les répertoriez. Le comportement du pod résultant reflète chaque règle d'autorisation et de refus pour l'entrée et la sortie.

Interface réseau de conteneurs

Dans un cluster Kubernetes, par défaut, les pods sont attachés à un seul réseau et ont une seule interface réseau de conteneur (CNI). Le CNI gère la connectivité réseau des conteneurs et supprime les ressources lorsque les conteneurs sont supprimés.

Kubernetes utilise des plug-ins SDN pour implémenter le CNI. Ils gèrent les ressources des interfaces réseau pour les nouveaux pods. Les plugins CNI configurent des constructions de mise en réseau appropriées pour la communication pod à pod et pod à externe et appliquent les politiques de réseau.

Fonctionnalités de sécurité réseau Openshift

OpenShift offre les fonctionnalités et composants supplémentaires suivants pour sécuriser les réseaux pour les déploiements cloud natifs :

  • Opérations réseau : OpenShift comprend un ensemble d'opérateurs qui gèrent les composants réseau pour appliquer les meilleures pratiques et atténuer les erreurs humaines.
  • Plusieurs interfaces réseau : la valeur par défaut de Kubernetes est que tous les pods utilisent un seul réseau et une seule interface réseau principale, mais avec OpenShift, vous pouvez configurer des interfaces réseau supplémentaires. Cela permet l'optimisation du réseau pour améliorer les performances et améliore l'isolation pour améliorer la sécurité.
  • Améliorations de la sécurité d'entrée : OpenShift expose le cluster à des ressources externes ou à des clients via une ressource de route . Les routes fournissent des fonctionnalités avancées introuvables dans un contrôleur d'entrée Kubernetes standard, notamment le rechiffrement TLS, le relais TLS et le trafic fractionné pour les déploiements bleu-vert.
  • Améliorations de la sécurité de sortie : alors que la règle OpenShift par défaut autorise tout le trafic de sortie à quitter le cluster sans aucune restriction, OpenShift dispose d'outils pour un contrôle et un filtrage précis du trafic sortant. OpenShift vous permet de contrôler le trafic de sortie via un pare -feu de sortie , des routeurs de sortie et des adresses IP statiques de sortie .
  • Maillage de services : Red Hat OpenShift Service Mesh, basé sur le projet Istio , ajoute une couche transparente aux services de réseau d'applications existants exécutés dans un cluster, permettant une gestion et une surveillance complexes sans nécessiter de modifications des services. Pour ce faire, le maillage de services déploie un proxy side-car aux côtés des services concernés pour intercepter et gérer toutes les communications réseau. Avec Red Hat OpenShift Service Mesh, vous pouvez créer un réseau avec les services suivants : découverte, équilibrage de charge, authentification de service à service, récupération après défaillance, métriques, surveillance, tests A/B, versions Canary, limitation de débit, contrôle d'accès, et l'authentification de bout en bout.

Pour plus d'informations, consultez le Guide de sécurité Red Hat OpenShift .

Associez-vous à Red Hat pour créer votre SaaS

Cet article a couvert les contrôles qui peuvent être utilisés pour améliorer la sécurité de votre déploiement SaaS au niveau du matériel, du système d'exploitation, du conteneur, du cluster Kubernetes et du réseau. Les prochains articles approfondiront les sujets de sécurité SaaS.

Red Hat SaaS Foundations est un programme partenaire conçu pour créer des plateformes SaaS de niveau entreprise sur Red Hat OpenShift ou Red Hat Enterprise Linux, et les déployer sur plusieurs empreintes cloud et non cloud. Envoyez -nous un e-mail pour en savoir plus.

Lien : https://developers.redhat.com/articles/2022/07/27/saas-security-kubernetes-environments-layered-approach#partner_with_red_hat_to_build_your_saas

#sass #kubernetes #redhat

Une Approche En Couches Pour Sécuriser Le SaaS Dans Un Env Kubernetes

Comment Ajouter SCSS Ou SASS à SvelteKit

Bien que Svelte/SvelteKit prenne en charge d'autres préprocesseurs CSS, rien n'est intégré, nous devons donc installer manuellement les dépendances afin de les utiliser dans notre projet. Dans cet article de blog, nous allons passer en revue le moyen le plus simple d'y parvenir.

Pour les personnes qui découvrent Svelte ou SvelteKit, la syntaxe d'utilisation de SCSS ou SASS est simple, il suffit d'ajouter l'attribut lang="sass" à la balise de style.

// SASS

<style lang="sass">
	.page {
		width: 100%;
		max-width: var(--column-width);
		margin: var(--column-margin-top) auto 0 auto;
	}
</style>

// SCSS

<style lang="scss">
	.page {
		width: 100%;
		max-width: var(--column-width);
		margin: var(--column-margin-top) auto 0 auto;
	}
</style>

Cependant, si j'essaie de le faire dans un nouveau référentiel SvelteKit, je verrai le message d'erreur suivant.

sveltekit-erreur-pas-sass

Voici le message d'erreur complet :

Cannot find any of modules: sass,node-sass

Error: Cannot find module 'node-sass'
Require stack:
- /Users/hao/workspace/demo/node_modules/.pnpm/svelte-preprocess@4.10.5_svelte@3.46.6+typescript@4.6.3/node_modules/svelte-preprocess/dist/modules/utils.js
- /Users/hao/workspace/demo/node_modules/.pnpm/svelte-preprocess@4.10.5_svelte@3.46.6+typescript@4.6.3/node_modules/svelte-preprocess/dist/autoProcess.js
- /Users/hao/workspace/demo/node_modules/.pnpm/svelte-preprocess@4.10.5_svelte@3.46.6+typescript@4.6.3/node_modules/svelte-preprocess/dist/index.js

The file cannot be parsed because style requires a preprocessor that doesn't seem to be setup or failed during setup. Did you setup a `svelte.config.js`? If you use SCSS, it may be necessary to add the path to your NODE runtime to the setting `svelte.language-server.runtime`, or use `sass` instead of `node-sass`. 

See https://github.com/sveltejs/language-tools/tree/master/docs#using-with-preprocessors for more info.svelte(style)

La solution

Tout ce que nous avons à faire est d'ajouter du sass à nos dépendances de développement, puis SvelteKit le récupérera automatiquement.

Il existe quelques packages que nous pouvons utiliser pour y parvenir :

  • node-sass est celui qui est le plus référencé, mais comme il est obsolète , je vous recommande fortement d'éviter de l'utiliser.
  • dart-sass est une implémentation plus moderne de node-sass. Mais il a depuis été renommé en sass.
  • sass est celui que vous devriez utiliser !
// NPM

npm i -D sass

// Yarn

yarn add -D sass

// PNPM

pnpm add -D sass

Ensuite, vous devriez voir le message d'erreur ci-dessus disparaître.

erreur sass sveltekit corrigée

Si le message d'erreur ne disparaît pas, essayez de recharger votre éditeur. Si vous utilisez VS Code sur un Mac, vous pouvez le faire avec cmd + p puis recherchez Developer: reload window.

Remarque : vous devrez peut-être également redémarrer l'application SvelteKit pour que cela prenne effet.

Source : https://blog.hao.dev/how-to-add-scss-or-sass-to-sveltekit

#scss #sass #sveltekit 

Comment Ajouter SCSS Ou SASS à SvelteKit
曾 俊

曾 俊

1658766729

如何将 SCSS 或 SASS 添加到 SvelteKit

尽管 Svelte/SvelteKit 支持其他 CSS 预处理器,但没有内置任何东西,因此我们需要手动安装依赖项才能在我们的项目中使用它们。在这篇博文中,我们将介绍实现这一目标的最简单方法。

对于刚接触 Svelte 或 SvelteKit 的人来说,使用 SCSS 或 SASS 的语法很简单,只需在 style 标签中添加 lang="sass" 属性即可。

// SASS

<style lang="sass">
	.page {
		width: 100%;
		max-width: var(--column-width);
		margin: var(--column-margin-top) auto 0 auto;
	}
</style>

// SCSS

<style lang="scss">
	.page {
		width: 100%;
		max-width: var(--column-width);
		margin: var(--column-margin-top) auto 0 auto;
	}
</style>

但是,如果我尝试在新的 SvelteKit 存储库中执行此操作,我将看到以下错误消息。

sveltekit-error-no-sass

这是完整的错误消息:

Cannot find any of modules: sass,node-sass

Error: Cannot find module 'node-sass'
Require stack:
- /Users/hao/workspace/demo/node_modules/.pnpm/svelte-preprocess@4.10.5_svelte@3.46.6+typescript@4.6.3/node_modules/svelte-preprocess/dist/modules/utils.js
- /Users/hao/workspace/demo/node_modules/.pnpm/svelte-preprocess@4.10.5_svelte@3.46.6+typescript@4.6.3/node_modules/svelte-preprocess/dist/autoProcess.js
- /Users/hao/workspace/demo/node_modules/.pnpm/svelte-preprocess@4.10.5_svelte@3.46.6+typescript@4.6.3/node_modules/svelte-preprocess/dist/index.js

The file cannot be parsed because style requires a preprocessor that doesn't seem to be setup or failed during setup. Did you setup a `svelte.config.js`? If you use SCSS, it may be necessary to add the path to your NODE runtime to the setting `svelte.language-server.runtime`, or use `sass` instead of `node-sass`. 

See https://github.com/sveltejs/language-tools/tree/master/docs#using-with-preprocessors for more info.svelte(style)

解决方案

我们所要做的就是将 sass 添加到我们的开发依赖项中,然后 SvelteKit 会自动选择它。

我们可以使用一些包来实现这一点:

  • node-sass是被引用最多的一个,但由于它已被弃用,我强烈建议您避免使用它。
  • dart-sassnode-sass. 但后来改名为sass.
  • sass是你应该使用的!
// NPM

npm i -D sass

// Yarn

yarn add -D sass

// PNPM

pnpm add -D sass

然后你应该看到上面的错误信息消失了。

sass sveltekit 错误已修复

如果错误消息没有消失,请尝试重新加载您的编辑器。如果您在 Mac 上使用 VS Code,您可以使用 cmd + p 执行此操作,然后搜索 Developer: reload window。

注意:您可能还需要重新启动 SvelteKit 应用程序才能使其生效。

来源:https ://blog.hao.dev/how-to-add-scss-or-sass-to-sveltekit

#scss #sass #sveltekit 

如何将 SCSS 或 SASS 添加到 SvelteKit
Thai  Son

Thai Son

1658763060

Cách Thêm SCSS Hoặc SASS Vào SvelteKit

Mặc dù Svelte / SvelteKit hỗ trợ các bộ tiền xử lý CSS khác, nhưng không có gì tích hợp sẵn, vì vậy chúng tôi cần cài đặt thủ công các phần phụ thuộc để sử dụng chúng trong dự án của mình. Trong bài đăng trên blog này, chúng ta sẽ xem xét cách đơn giản nhất để đạt được điều này.

Đối với những người mới sử dụng Svelte hoặc SvelteKit, cú pháp sử dụng SCSS hoặc SASS rất đơn giản, chỉ cần thêm thuộc tính lang = "sass" vào thẻ style.

// SASS

<style lang="sass">
	.page {
		width: 100%;
		max-width: var(--column-width);
		margin: var(--column-margin-top) auto 0 auto;
	}
</style>

// SCSS

<style lang="scss">
	.page {
		width: 100%;
		max-width: var(--column-width);
		margin: var(--column-margin-top) auto 0 auto;
	}
</style>

Tuy nhiên, nếu tôi cố gắng thực hiện việc này trong kho lưu trữ SvelteKit mới, tôi sẽ thấy thông báo lỗi sau.

sveltekit-error-no-sass

Đây là thông báo lỗi đầy đủ:

Cannot find any of modules: sass,node-sass

Error: Cannot find module 'node-sass'
Require stack:
- /Users/hao/workspace/demo/node_modules/.pnpm/svelte-preprocess@4.10.5_svelte@3.46.6+typescript@4.6.3/node_modules/svelte-preprocess/dist/modules/utils.js
- /Users/hao/workspace/demo/node_modules/.pnpm/svelte-preprocess@4.10.5_svelte@3.46.6+typescript@4.6.3/node_modules/svelte-preprocess/dist/autoProcess.js
- /Users/hao/workspace/demo/node_modules/.pnpm/svelte-preprocess@4.10.5_svelte@3.46.6+typescript@4.6.3/node_modules/svelte-preprocess/dist/index.js

The file cannot be parsed because style requires a preprocessor that doesn't seem to be setup or failed during setup. Did you setup a `svelte.config.js`? If you use SCSS, it may be necessary to add the path to your NODE runtime to the setting `svelte.language-server.runtime`, or use `sass` instead of `node-sass`. 

See https://github.com/sveltejs/language-tools/tree/master/docs#using-with-preprocessors for more info.svelte(style)

Dung dịch

Tất cả những gì chúng ta phải làm là thêm sass vào các phụ thuộc nhà phát triển của mình, sau đó SvelteKit sẽ tự động nhận nó.

Có một số gói chúng tôi có thể sử dụng để đạt được điều này:

  • node-sass là cái được tham chiếu nhiều nhất, nhưng vì nó đã không còn được dùng nữa , tôi thực sự khuyên bạn nên tránh sử dụng cái này.
  • dart-sass là một triển khai hiện đại hơn của node-sass. Nhưng nó đã được đổi tên thành sass.
  • sass là một trong những bạn nên sử dụng!
// NPM

npm i -D sass

// Yarn

yarn add -D sass

// PNPM

pnpm add -D sass

Sau đó, bạn sẽ thấy thông báo lỗi trên biến mất.

lỗi sass sveltekit đã sửa

Nếu thông báo lỗi không biến mất, hãy thử tải lại trình chỉnh sửa của bạn. Nếu bạn sử dụng VS Code trên Mac, bạn có thể thực hiện việc này với cmd + p rồi tìm kiếm Developer: reload window.

Lưu ý: bạn cũng có thể cần phải khởi động lại ứng dụng SvelteKit để điều này có hiệu lực.

Nguồn: https://blog.hao.dev/how-to-add-scss-or-sass-to-sveltekit

#scss #sass #sveltekit 

Cách Thêm SCSS Hoặc SASS Vào SvelteKit