Як Workers VPC Services підключається до ваших регіональних приватних мереж з будь-якої точки світу

У квітні ми поділилися нашим баченням щодо a глобальна віртуальна приватна хмара на Cloudflareспосіб розблокувати ваші програми від регіонально обмежених хмар і локальних мереж, що дає змогу створювати справді міжхмарні програми.

Сьогодні ми оголошуємо про першу віху нашої ініціативи Workers VPC: послуги VPC. Служби VPC дозволяють підключатися до ваших API, контейнерів, віртуальних машин, безсерверних функцій, баз даних та інших служб у регіональних приватних мережах через Тунелі Cloudflare від вашого Робітники бігати в будь-якій точці світу.

Налаштувавши тунель у вашій бажаній мережі, ви можете зареєструвати кожну службу, яку бажаєте відкрити для Workers, налаштувавши її хост або IP-адресу. Після цього ви зможете отримати доступ до служби VPC, як і будь-якої іншої Службова прив'язка працівників — Мережа Cloudflare автоматично спрямовуватиметься до служби VPC через мережу Cloudflare, незалежно від того, де виконується ваш Worker:

export default {
  async fetch(request, env, ctx) {
    // Perform application logic in Workers here	

    // Call an external API running in a ECS in AWS when needed using the binding
    const response = await env.AWS_VPC_ECS_API.fetch("http://internal-host.com");

    // Additional application logic in Workers
    return new Response();
  },
};

Workers VPC тепер доступний для всіх, хто використовує Workers, без додаткових витрат протягом бета-версії, як і Cloudflare Tunnels. Спробуйте зараз. І читайте далі, щоб дізнатися більше про те, як це працює під капотом.

Ваші програми охоплюють кілька мереж, незалежно від того, чи є вони локальними чи зовнішніми хмарами. Але було важко підключитися від Workers до ваших API і баз даних, заблокованих за приватними мережами.

Ми маємо описані раніше як традиційні віртуальні приватні хмари та мережі закріплюють вас у традиційних хмарах. Незважаючи на те, що вони забезпечують ізоляцію робочого навантаження та безпеку, традиційні віртуальні приватні хмари ускладнюють створення між хмарами, доступ до власних програм і вибір правильної технології для вашого стеку.

Значною частиною прив’язки до хмари є невід’ємна складність створення безпечних, розподілених робочих навантажень. Піринг VPC вимагає від вас налаштування таблиць маршрутизації, груп безпеки та списків контролю доступу до мережі, оскільки він покладається на роботу в хмарах для забезпечення підключення. У багатьох організаціях це означає тижні обговорень і залучення багатьох команд для отримання схвалень. Ця прив’язаність також відображена в рішеннях, винайдених для вирішення цієї складності: кожен постачальник хмарних послуг має власну спеціальну версію «Приватного посилання» для полегшення з’єднання між мережами, ще більше обмежуючи вас цією хмарою та постачальниками, які її інтегрували.

З Workers VPC ми значно спрощуємо це. Ви налаштовуєте тунель Cloudflare один раз і маєте необхідні дозволи для доступу до вашої приватної мережі. Потім ви можете налаштувати Workers VPC Services із тунелем і ім’ям хоста (або IP-адресою та портом) служби, яку ви хочете надати Workers. Будь-який запит, зроблений до цієї служби VPC, використовуватиме цю конфігурацію для маршрутизації до зазначеної служби в мережі.

{
  "type": "http",
  "name": "vpc-service-name",
  "http_port": 80,
  "https_port": 443,
  "host": {
    "hostname": "internally-resolvable-hostname.com",
    "resolver_network": {
      "tunnel_id": "0191dce4-9ab4-7fce-b660-8e5dec5172da"
    }
  }
}

Це гарантує, що після представлення служби Workers VPC служба у вашій приватній мережі захищена так само, як інші прив’язки Cloudflare за допомогою моделі прив’язки Workers. Давайте розглянемо простий приклад зв’язування служби VPC:

{
  "name": "WORKER-NAME",
  "main": "./src/index.js",
  "vpc_services": [
    {
      "binding": "AWS_VPC2_ECS_API",
      "service_id": "5634563546"
    }
  ]
}

Як і інші прив’язки Worker, коли ви розгортаєте проект Worker, який намагається підключитися до служби VPC, дозволи на доступ перевіряються під час розгортання, щоб гарантувати, що Worker має доступ до відповідної служби. Після розгортання Worker може використовувати прив’язку служби VPC, щоб надсилати запити до цієї служби VPC — і лише до цієї служби в мережі.

Це важливо: замість того, щоб відкривати всю мережу для Worker, Worker може отримати доступ лише до певної служби VPC. Цей доступ перевіряється під час розгортання, щоб забезпечити більш чіткий і прозорий контроль доступу до послуг, ніж традиційні мережі та списки контролю доступу.

Це ключовий фактор у розробці прив’язок Workers: фактична безпека зі спрощеним керуванням і створення імунітету Workers до атак підробки запитів на стороні сервера (SSRF). Раніше ми глибоко вивчали модель обов’язкової безпекиі це стає набагато критичнішим під час доступу до ваших приватних мереж.

Примітно, що модель зв’язування також важлива, якщо розглядати, що таке Workers: сценарії, що працюють у глобальній мережі Cloudflare. На відміну від традиційних хмар, вони не є окремими машинами з IP-адресами і не існують у мережах. Прив’язки забезпечують безпечний доступ до інших ресурсів у вашому обліковому записі Cloudflare – і те саме стосується служб Workers VPC.

Отже, як служби VPC та їхні прив’язки направляють мережеві запити від Workers будь-де в глобальній мережі Cloudflare до регіональних мереж за допомогою тунелів? Давайте подивимося на життєвий цикл зразка HTTP-запиту, зробленого з виділеної служби VPC вибірка() запит представлений тут:

Все починається в коді Worker, де .fetch() функція потрібної служби VPC викликається стандартним JavaScript запит (як показано на кроці 1). Середа виконання Workers використовуватиме a Капітан Прото remote-procedure-call, щоб надіслати оригінальний HTTP-запит разом із додатковим контекстом, як це робиться для багатьох інших прив’язок Workers.

Працівник зв’язування системи обслуговування VPC отримує HTTP-запит разом із контекстом зв’язування, у цьому випадку це ідентифікатор служби VPC, що викликається. Binding Worker надсилатиме цю інформацію до служби Iris через підключення HTTP CONNECT, стандартний шаблон у прив’язках Cloudflare для розміщення логіки підключення до крайових служб Cloudflare у коді Worker, а не в самому середовищі виконання Workers (Крок 2).

Служба Iris є основною послугою для Workers VPC. Його відповідальність полягає в тому, щоб приймати запити на послугу VPC і направляти їх до мережі, у якій знаходиться ваша служба VPC. Це робиться шляхом інтеграції з Аполлонвнутрішня служба Cloudflare One. Apollo надає уніфікований інтерфейс, який усуває складність безпечного підключення до мереж і тунелів, на різних рівнях мережі.

Щоб інтегруватися з Apollo, Iris має виконати два завдання. Спочатку Iris розбере ідентифікатор служби VPC із метаданих і отримає інформацію про тунель, пов’язаний із ним, із нашого сховища конфігурацій. Це включає ідентифікатор тунелю та тип зі сховища конфігурації (Крок 3), що є інформацією, яка потрібна Iris для надсилання вихідних запитів до потрібного тунелю.

По-друге, Iris створить дейтаграми UDP, що містять запитання DNS для записів A та AAAA імені хоста служби VPC. Ці дейтаграми будуть надіслані спочатку через Apollo. Після завершення вирішення DNS оригінальний запит надсилається разом із дозволеною IP-адресою та портом (Крок 4). Це означає, що кроки з 4 по 7 виконуються послідовно двічі для першого запиту: один раз для вирішення DNS і другий раз для вихідного запиту HTTP. Подальші запити отримують користь від кешування Iris інформації про вирішення DNS, мінімізуючи затримку запиту.

На кроці 5 Apollo отримує метадані тунелю Cloudflare, до якого потрібно отримати доступ, а також UDP-дейтаграми розв’язання DNS або пакети TCP-запиту HTTP. Використовуючи ідентифікатор тунелю, він визначає, який центр обробки даних підключено до тунелю Cloudflare. Цей центр обробки даних знаходиться в регіоні поблизу тунелю Cloudflare, і тому Apollo направлятиме повідомлення DNS-розв’язання та вихідний запит до служби з’єднувача тунелю, що працює в цьому центрі обробки даних (Крок 5).

Служба Tunnel Connector відповідає за надання доступу до тунелю Cloudflare решті мережі Cloudflare. Він передаватиме запити вирішення DNS, а згодом і вихідний запит до тунелю через протокол QUIC (Крок 6).

Нарешті, Cloudflare Tunnel надішле запити про розв’язання DNS до розв’язувача DNS мережі, до якої він належить. Потім він надішле оригінальний HTTP-запит зі своєї власної IP-адреси на IP-адресу призначення та порт (Крок 7). Результати запиту потім передаються назад до початкового Worker, від центру обробки даних, найближчого до тунелю, аж до оригінального центру обробки даних Cloudflare, який виконує запит Worker.

Це відкриває цілу нову серію програм, які ви можете створювати на Cloudflare. Протягом багатьох років Workers досягали успіху на краю, але вони здебільшого залишалися поза межами вашої основної інфраструктури. Вони могли викликати лише загальнодоступні кінцеві точки, обмежуючи їхню здатність взаємодіяти з найбільш критичними частинами вашого стеку, такими як API приватних облікових записів або внутрішня база даних інвентаризації. Тепер, завдяки службам VPC, працівники можуть безпечно отримувати доступ до цих приватних API, баз даних і служб, докорінно змінюючи те, що можливо.

Це миттєво вмикає справжні міжхмарні програми, які охоплюють Cloudflare Workers і будь-яку іншу хмару, як-от AWS, GCP або Azure. Ми бачили, як багато клієнтів прийняли цей шаблон під час нашої приватної бета-версії, встановлюючи приватне з’єднання між їхніми зовнішніми хмарами та Cloudflare Workers. Ми навіть зробили це самі, підключивши наших робочих до служб Kubernetes у наших основних центрах обробки даних, щоб забезпечити роботу API рівня керування для багатьох наших служб. Тепер ви можете створювати таку саму потужну розподілену архітектуру, використовуючи Workers для глобального масштабу, зберігаючи при цьому інформаційні сервери в мережі, якій ви вже довіряєте.

Це також означає, що ви можете підключатися до своїх локальних мереж із Workers, дозволяючи модернізувати застарілі програми за допомогою продуктивності та нескінченного масштабу Workers. Ще більш цікавими є деякі випадки використання для робочих процесів розробників. Ми бачили, як розробники біжать cloudflared на своїх ноутбуках, щоб підключити розгорнутий Worker до локальної машини для налагодження в реальному часі. Повна гнучкість Cloudflare Tunnels тепер є програмованим примітивом, доступним безпосередньо з вашого Worker, що відкриває цілий світ можливостей.

Послуги VPC – це перша віха в масштабній ініціативі Workers VPC, але ми тільки починаємо. Наша мета — зробити підключення до будь-якої служби та будь-якої мережі в будь-якій точці світу безперебійною частиною роботи Workers. Ось над чим ми працюємо далі:

Глибша мережева інтеграція. Почати з Cloudflare Tunnels було свідомим вибором. Це надзвичайно доступне, гнучке та знайоме рішення, що робить його ідеальною основою для розвитку. Щоб надати більше можливостей для корпоративних мереж, ми додамо підтримку стандартних тунелів IPsec, Cloudflare Network Interconnect (CNI) і AWS Transit Gateway, надаючи вам і вашим командам більше можливостей вибору та потенційної оптимізації. Важливо те, що ці з’єднання також стануть справді двонаправленими, дозволяючи вашим приватним службам ініціювати з’єднання з ресурсами Cloudflare, наприклад надсилати події в черги або отримувати з R2.

Розширена підтримка протоколів і сервісів. Наступним кроком після HTTP є надання доступу до служб TCP. Спочатку це буде досягнуто шляхом інтеграції з Hyperdrive. Ми розвиваємо попередню підтримку Hyperdrive для приватних баз даних, щоб її було спрощено за допомогою конфігурації VPC Services, уникаючи необхідності додавати Cloudflare Access і керувати маркерами безпеки. Це створює більш нативний досвід разом із потужним пулом з’єднань Hyperdrive. Після цього ми додамо ширшу підтримку необроблених TCP-з’єднань, відкриваючи пряме підключення до таких служб, як кеш Redis і черги повідомлень з Workers ‘connect()’.

Сумісність екосистем. Ми хочемо, щоб підключення до приватної служби було таким же природним, як підключення до публічної. Для цього ми надамо унікальне автоматично згенероване ім’я хоста для кожної служби Workers VPC, подібне до Рядки підключення Hyperdrive. Це спростить використання Workers VPC з існуючими бібліотеками та бібліотеками об’єктно-реляційного відображення, які можуть потребувати імені хоста (наприклад, у глобальному 'fetch()' виклик або рядок підключення MongoDB). Ім’я хоста служби Workers VPC автоматично розпізнається та спрямовується до правильної служби VPC, так само, як “fetch()' робить команда.

Сьогодні ми раді запустити відкриту бета-версію Workers VPC Services. Ми витратили місяці на створення та тестування нашої першої віхи для доступу працівників до приватної мережі. І ми вдосконалили його на основі відгуків внутрішніх команд і клієнтів під час закритого бета-тестування.

Тепер ми з нетерпінням чекаємо можливості кожному створювати кросхмарні програми на Workers with Workers VPC, доступні безкоштовно під час відкритого бета-тестування. За допомогою Workers VPC ви можете наблизити свої програми в приватних мережах до регіону Земля, наблизити їх до своїх користувачів і зробити їх доступними для Workers у всьому світі.

Почніть користуватися Workers VPC Services безкоштовно зараз.