23.07.2024 10:31
ManegSPb 0 6300 Источник

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

Привет, Хабр! Меня зовут Саша, я ведущий системный администратор в Selectel. В этой статье на примере гибридной инфраструктуры покажу, как развернуть защищенную приватную инсталляцию в облаке, а заодно разберу некоторые мифы. Добро пожаловать под кат!

Используйте навигацию, если не хотите читать текст полностью:

→ Приватные инсталляции Managed Kubernetes
→ Bare Metal Cloud
→ Построение гибридной архитектуры
→ Заключение

Приватные инсталляции Managed Kubernetes


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

Приватный хост


Это изоляция вычислений на уровне физического хоста. Запуск виртуальной машины или воркер-ноды (worker node) Kubernetes происходит на физическом сервере. Он становится приватным хостом, если целиком отдается одному пользователю.

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


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

Упрощенно это выглядит так: защищаемое приложение может создавать в оперативной памяти анклавы, данные в которых изолируются на физическом хосте. Их не могут прочитать другие приложения, запущенные на том же сервере (включая системные, модули ядра и гипервизор).


Приватный сегмент пула


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


Приватный пул


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




Bare Metal Cloud


Это выделенные серверы для высоконагруженных сервисов (интернет-магазинов, игр, SaaS-сервисов, ERP-систем), медиапроектов (сервисов потокового видео, аудио и обработки большого количества пользовательских данных в реальном времени) и проектов в сфере ML и Big Data. В Selectel такие серверы представлены в фиксированной и кастомной конфигурациях.

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

Построение гибридной архитектуры


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

Сейчас с помощью Terraform поднимем кластер Kubernetes вместе с приватным Kube API и облачным файрволом. Межсетевым экраном мы закроем кластер от доступа извне, а ходить в него будем через Jump Host, он же Bastion.

Bastion-хост — это хост в сети, который является шлюзом или прокси для всех остальных серверов. Такой хост доступен на внешнем адресе и общается с остальными серверами по приватной сети.

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

Манифест main


Здесь мы определяем, в первую очередь, переменные, чтобы достать их из Secrets.tfvars — файла с секретами, где хранят пароли и прочую чувствительную информацию. Файл выглядит следующим образом:

domain = "12345"
domain_password = "password"
project_password = "password"

Далее прописываем провайдера (Selectel) и ресурс — наш проект, в котором и будем разворачивать инфраструктуру. Создаем сервисного пользователя и объявляем переменные для провайдера OpenStack.

variable "domain" {
}
variable "domain_password" {
}
variable "project_password" {
}
provider "selectel" {
  domain_name = var.domain
  username    = "webinar"
  password    = var.domain_password
}
resource "selectel_vpc_project_v2" "project_1" {
  name = "webinar"
}
resource "selectel_iam_serviceuser_v1" "serviceuser_1" {
  name     = "project-name"
  password = var.project_password
  role {
    role_name  = "member"
    scope      = "project"
    project_id = selectel_vpc_project_v2.project_1.id
  }
}
provider "openstack" {
  auth_url    = "https://cloud.api.selcloud.ru/identity/v3"
  domain_name = var.domain
  tenant_id   = selectel_vpc_project_v2.project_1.id
  user_name   = selectel_iam_serviceuser_v1.serviceuser_1.name
  password    = selectel_iam_serviceuser_v1.serviceuser_1.password
  region      = "ru-9"
}

Инициализируем Terraform командой terraform init. Если все прошло успешно, идем в раздел Versions и описываем в нем необходимые нам провайдеры и версии для них.

terraform {
  required_providers {
    selectel = {
      source  = "selectel/selectel"
      version = "5.0.2"
    }
    openstack = {
      source  = "terraform-provider-openstack/openstack"
      version = "1.54.1"
    }
  }
}

Возвращаемся в main и запускаем его развертывание:

terraform apply -var-file=./secrets.tfvars

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

Когда проект будет готов, увидим в терминале ответ системы вида: «Apply Complete! Ressources: 2 added, 0 changed, 0 destroyed». Теперь идем в панель управления. Проект уже здесь, но пока он пустой. Создадим новый кластер, а заодно посмотрим, какие у нас еще манифесты припасены.


Панель управления с пустым проектом webinar.

Манифест network


Следующий шаг — создать сеть. Это также делается предыдущей командой. Посмотрим на манифест network:

resource "openstack_networking_network_v2" "network_1" {
  name           = "private-network"
  admin_state_up = "true"
}
resource "openstack_networking_subnet_v2" "subnet_1" {
  name            = "private-subnet"
  network_id      = openstack_networking_network_v2.network_1.id
  cidr            = "10.222.0.0/16"
  dns_nameservers = ["188.93.16.19", "188.93.17.19"]
  enable_dhcp     = false
}
data "openstack_networking_network_v2" "external_network_1" {
  depends_on = [openstack_networking_network_v2.network_1]
  external   = true
}
resource "openstack_networking_router_v2" "router_1" {
  name                = "router-terraform"
  external_network_id = data.openstack_networking_network_v2.external_network_1.id
}
resource "openstack_networking_router_interface_v2" "router_interface_1" {
  router_id = openstack_networking_router_v2.router_1.id
  subnet_id = openstack_networking_subnet_v2.subnet_1.id
}

network_1 — это приватная сеть, в которой мы будем создавать нашу инфраструктуру. В этой сети нам необходимо создать subnet. Здесь мы отмечаем:

  • cidr, в которой будет «жить» наш кластер Kubernetes и вся остальная инфраструктура;
  • dns_nameservers — публичные рекурсоры Selectel (можно использовать и свои приватные рекурсоры, если они отвечают запросам, которые нужны для кластера);
  • enable dhcp — здесь обязательно указываем значение false, потому что периодически могут возникать проблемы, связанные с работой кластера Kubernetes с включенным DHCP.

В data для external указываем значение true. Также не забываем указать ресурс router, через который будем выходить наружу, и добавить его интерфейс.

И теперь остается запустить развертывание нашего манифеста network. Когда все будет готово, увидим в терминале ответ системы вида «Apply Complete! Ressources: 4 added, 0 changed, 0 destroyed», что подтверждает добавление всех четырех ресурсов. Перейдем к следующим манифестам.

Манифест cloud-firewall


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

resource "openstack_fw_policy_v2" "firewall_policy_1" {
  name    = "ingress-firewall-policy"
  audited = true
  rules = [
    openstack_fw_rule_v2.rule_1.id,
    openstack_fw_rule_v2.rule_2.id,
    openstack_fw_rule_v2.rule_3.id,
    openstack_fw_rule_v2.rule_4.id,
    openstack_fw_rule_v2.rule_5.id,
    openstack_fw_rule_v2.rule_6.id,
  ]
}
resource "openstack_fw_rule_v2" "rule_1" {
  name              = "allow-udp-188.93.16.19-53"
  action            = "allow"
  protocol          = "udp"
  source_ip_address = "188.93.16.19"
  source_port       = "53"
}
resource "openstack_fw_rule_v2" "rule_2" {
  name              = "allow-udp-188.93.17.19-53"
  action            = "allow"
  protocol          = "udp"
  source_ip_address = "188.93.17.19"
  source_port       = "53"
}
resource "openstack_fw_rule_v2" "rule_3" {
  name              = "allow-udp-92.53.68.16-443"
  action            = "allow"
  protocol          = "tcp"
  source_ip_address = "92.53.68.16"
  source_port       = "443"
}
resource "openstack_fw_rule_v2" "rule_4" {
  name              = "allow-udp-85.119.149.24-443"
  action            = "allow"
  protocol          = "tcp"
  source_ip_address = "85.119.149.24"
  source_port       = "443"
}
resource "openstack_fw_rule_v2" "rule_5" {
  name              = "allow-occm-443"
  action            = "allow"
  protocol          = "tcp"
  source_ip_address = "95.213.160.182"
  source_port       = "443"
}
resource "openstack_fw_rule_v2" "rule_6" {
  name                   = "allow-to-cloud-server"
  action                 = "allow"
  protocol               = "any"
  destination_ip_address = openstack_networking_floatingip_v2.floatingip_1.fixed_ip
}
resource "openstack_fw_policy_v2" "firewall_policy_2" {
  name    = "egress-firewall-policy"
  audited = true
  rules = [
    openstack_fw_rule_v2.rule_01.id,
    openstack_fw_rule_v2.rule_02.id,
    openstack_fw_rule_v2.rule_03.id,
    openstack_fw_rule_v2.rule_04.id,
    openstack_fw_rule_v2.rule_05.id,
  ]
}
resource "openstack_fw_rule_v2" "rule_01" {
  name                   = "allow-udp-188.93.16.19-53"
  action                 = "allow"
  protocol               = "udp"
  destination_ip_address = "188.93.16.19"
  destination_port       = "53"
}
resource "openstack_fw_rule_v2" "rule_02" {
  name                   = "allow-udp-188.93.17.19-53"
  action                 = "allow"
  protocol               = "udp"
  destination_ip_address = "188.93.17.19"
  destination_port       = "53"
}
resource "openstack_fw_rule_v2" "rule_03" {
  name                   = "allow-udp-92.53.68.16-443"
  action                 = "allow"
  protocol               = "tcp"
  destination_ip_address = "92.53.68.16"
  destination_port       = "443"
}
resource "openstack_fw_rule_v2" "rule_04" {
  name                   = "allow-udp-85.119.149.24-443"
  action                 = "allow"
  protocol               = "tcp"
  destination_ip_address = "85.119.149.24"
  destination_port       = "443"
}
resource "openstack_fw_rule_v2" "rule_05" {
  name                   = "occm-443"
  action                 = "allow"
  protocol               = "tcp"
  destination_ip_address = "95.213.160.182"
  destination_port       = "443"
}
resource "openstack_fw_group_v2" "group_1" {
  name                       = "my-firewall"
  admin_state_up             = true
  ingress_firewall_policy_id = openstack_fw_policy_v2.firewall_policy_1.id
  egress_firewall_policy_id  = openstack_fw_policy_v2.firewall_policy_2.id
  ports = [
    openstack_networking_router_interface_v2.router_interface_1.port_id,
  ]
}

Первый ресурс — firewall_policy. Это набор из шести правил, которые разрешают подключения к разным IP-адресам и портам. Например, первое правило разрешает UDP на 53-й порт, то есть на IP-адреса, которые мы отмечали как рекурсоры. А шестое — «разрешает все» для нашего облачного сервера, который мы используем как Jump Host. Все правила после создания кластера можно будет посмотреть в панели управления.

Второй ресурс — firewall_policy_2. Здесь пять правил, которые дублируют все, что мы видели ранее. Первое правило — это один из RDNS, далее идет второй RDNS, репозиторий, mirror и наш OpenStack API.

В конце создаем еще один ресурс, в котором объединяем все наши правила и политики Ingress и Egress в одну группу. Назовем ее my-firewall и укажем порт роутера, который мы создали в манифесте ранее. Пишем yes, видим 21 ресурс для создания, запускаем.

Манифест cloud-server


resource "selectel_vpc_keypair_v2" "keypair_1" {
  name       = "keypair"
  public_key = file("~/.ssh/id_rsa.pub")
  user_id    = selectel_iam_serviceuser_v1.serviceuser_1.id
  regions    = ["ru-9"]
}
#TODO id_rsa
resource "openstack_compute_flavor_v2" "flavor_1" {
  name      = "custom-flavor"
  vcpus     = 2
  ram       = 2048
  disk      = 0
  is_public = false
  lifecycle {
    create_before_destroy = true
  }
}
resource "openstack_networking_port_v2" "port_1" {
  name       = "cloud-server-port"
  network_id = openstack_networking_network_v2.network_1.id
  fixed_ip {
    subnet_id = openstack_networking_subnet_v2.subnet_1.id
  }
}
data "openstack_images_image_v2" "image_1" {
  depends_on  = [selectel_vpc_project_v2.project_1]
  name        = "Ubuntu 22.04 LTS 64-bit"
  most_recent = true
  visibility  = "public"
}
resource "openstack_blockstorage_volume_v3" "volume_1" {
  name        = "cloud-server-boot-volume"
  size        = "5"
  image_id    = data.openstack_images_image_v2.image_1.id
  volume_type = "fast.ru-9a"
  lifecycle {
    ignore_changes = [image_id]
  }
}
#### Create server
resource "openstack_compute_instance_v2" "server_1" {
  name              = "cloud-server"
  flavor_id         = openstack_compute_flavor_v2.flavor_1.id
  key_pair          = selectel_vpc_keypair_v2.keypair_1.name
  availability_zone = "ru-9a"
  network {
    port = openstack_networking_port_v2.port_1.id
  }
  lifecycle {
    ignore_changes = [image_id]
  }
  block_device {
    uuid             = openstack_blockstorage_volume_v3.volume_1.id
    source_type      = "volume"
    destination_type = "volume"
    boot_index       = 0
  }
}
resource "openstack_networking_floatingip_v2" "floatingip_1" {
  pool = "external-network"
}
resource "openstack_networking_floatingip_associate_v2" "association_1" {
  port_id     = openstack_networking_port_v2.port_1.id
  floating_ip = openstack_networking_floatingip_v2.floatingip_1.address
}
output "public_ip_address" {
  value = openstack_networking_floatingip_v2.floatingip_1.address
}

Рассмотрим, что есть в этом манифесте.

  • keypair. Это ключ, который лежит локально на ноутбуке. Мы добавляем его в облако, чтобы пользоваться SSH-ключами, а не ходить на Jump Host по паролям.
  • flavor_1. Здесь описываем количество ресурсов, необходимых хосту.
  • port_1. Это сетевой порт для сервера, чтобы мы смогли подключить его к приватной сети и иметь доступ к ресурсам внутри нее.
  • Ubuntu 22.04 — образ ОС.
  • volume_1. Это загрузочный диск, который мы будем использовать для загрузки сервера.

Когда ресурсы описаны, создаем сервер, описываем созданный порт и block_device, добавляем floating-IP. Он нужен, чтобы попасть на Jump Host из публичной сети. Далее необходимо ассоциировать floating-IP с портом и вывести public_ip_address. К нему уже можно подключаться по SSH.

Манифест k8s-cluster


data "selectel_mks_kube_versions_v1" "versions" {
  project_id = selectel_vpc_project_v2.project_1.id
  region     = "ru-9"
}
resource "selectel_mks_cluster_v1" "cluster_1" {
  name                              = "terraform-k8s-cluster"
  project_id                        = selectel_vpc_project_v2.project_1.id
  region                            = "ru-9"
  kube_version                      = data.selectel_mks_kube_versions_v1.versions.latest_version
  network_id                        = openstack_networking_network_v2.network_1.id
  subnet_id                         = openstack_networking_subnet_v2.subnet_1.id
  maintenance_window_start          = "00:00:00"
  enable_patch_version_auto_upgrade = false
  private_kube_api                  = true
}
resource "selectel_mks_nodegroup_v1" "nodegroup_1" {
  depends_on        = [selectel_mks_cluster_v1.cluster_1]
  cluster_id        = selectel_mks_cluster_v1.cluster_1.id
  project_id        = selectel_mks_cluster_v1.cluster_1.project_id
  region            = selectel_mks_cluster_v1.cluster_1.region
  availability_zone = "ru-9a"
  nodes_count       = "1"
  cpus              = 2
  ram_mb            = 4096
  volume_gb         = 32
  volume_type       = "fast.ru-9a"
}
data "selectel_mks_kubeconfig_v1" "kubeconfig" {
  cluster_id = selectel_mks_cluster_v1.cluster_1.id
  project_id = selectel_mks_cluster_v1.cluster_1.project_id
  region     = selectel_mks_cluster_v1.cluster_1.region
}
output "kubeconfig" {
  value = data.selectel_mks_kubeconfig_v1.kubeconfig.raw_config
  sensitive = true
}

Здесь мы начинаем с того, что определяем Versions. Это нужно для управления переменной kube_versions. А уже с ее помощью мы можем создавать кластеры из доступных версий и обновлять этот кластер.

Переменная, ради которой мы здесь собрались, — private_kube_api. Для нее указываем значение true. Она заставит Managed Kubernetes создать кластер с приватным Kube API.

В nodegroup_1 указываем необходимые ресурсы и определяем, что диск — это быстрый диск в пуле ru-9a и одна нода. Далее создаем kubeconfig, чтобы мы могли не ходить в панель и скачивать ее прямо из консоли. В конце выводим kubeconfig в output. В конце пишем yes. Когда кластер будет создан, увидим в терминале ответ: «Apply Complete! Ressources: 2 added, 1 changed, 0 destroyed».

Просмотр кластера в панели управления


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


Если нужно изменить количество групп нод, возвращаемся в манифест k8s-cluster, копируем ресурс nodegroup, задаем ему новое имя и указываем нужные параметры. Допустим, изменим количество нод и CPU:

resource "selectel_mks_nodegroup_v1" "nodegroup_2" {
  depends_on        = [selectel_mks_cluster_v1.cluster_1]
  cluster_id        = selectel_mks_cluster_v1.cluster_1.id
  project_id        = selectel_mks_cluster_v1.cluster_1.project_id
  region            = selectel_mks_cluster_v1.cluster_1.region
  availability_zone = "ru-9a"
  nodes_count       = "2"
  cpus              = 4
  ram_mb            = 4096
  volume_gb         = 32
  volume_type       = "fast.ru-9a"
}

Когда все готово, снова выполняем Terraform Apply.

Тем временем в панели управления можно посмотреть настройки кластера, Kube API, ранее созданной подсети, его тип и количество мастер-нод. Видим, что у нас их три — если одна выйдет из строя, кластер продолжит работать.


Настройка в консоли


Сейчас нам необходим файл kubectl. Обычно скачать его можно командой:

-curl -LO "<a href="https://dl.k8s.io/release/$">https://dl.k8s.io/release/$</a>(curl -L -s https://dl.k8s.io/release.stable.txt)/bin/linux/amd64/kubectl"

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

Стоит заранее скачать файл и положить в соседнюю директорию. Так будет удобнее его доставать.

./artifact/kubectl @root46.148.228.149:./

Когда убедились, что файл kubectl скачан, выполняемchmod +x. Проверяем работоспособность нашего kubectl командой:

-curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release.stable.txt)/bin/linux/amd64/kubectl"

Для доступа в кластер необходим еще kubeconfig. В консоли вводим команду:

terraform output kubeconfig

После получения файла его можно переименовать, например, в kubeconf.conf:

terraform output kubeconfig > kubeconf.conf

Далее, чтобы скопировать сам kubeconfig, вводим команду:

scp ./kubeconf.conf root@46.148.228.149:./

Следующий шаг выполняем на сервере — экспортируем kubeconfig и выводим его:

export KUBECONFIG=~/kubeconf.conf


./kubectl get no

Далее видим вывод kubectl get node: все ноды и время их создания. Давайте посмотрим на системные поды:

./kubectl -n -kube-system get po

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

Заключение


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

Если вам удобнее ознакомиться с материалом в формате видео, то предлагаем посмотреть запись воркшопа:

Комментарии (0)