0: И я приглашаю на эту сцену.

1: Дедов антона Дедова, он расскажет нам про мультирегиональность. Поприветствуем

2: Яндекс клауд объявил, что в прошлом году мы открыли новый регион в Казахстане, и я расскажу, как мы команд. Это вообще большой проект, довольно сложный. В нём участвовало много команд.

3: Много людей, очень много потрачено усилий я расскажу что мы делали с точки зрения амма, как мы вложились с точки зрения архитектуры arm, что мы вообще делали меня зовут Антон, я архитектор безопасности.

4: В команде менеджмент яндекс клауд и работаю в яндексе и в яндекс клауде с 19 года.

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

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

7: Своё питание, изолированное, там, охлаждение инфраструктуры и так далее. И зачем вообще нужна региональность? Ну, в 1 очередь для того, чтобы если у облачного провайдера есть региональность, то

8: Потребители могут размещать нагрузки максимально близко к клиенты могут размещать свои нагрузки максимально близко к потребителю. Скажем, если у вас очень большой интернет-магазин, то вы можете отвечать своему клиенту из азии, из региона азии.

9: Европу из региона в европе и так далее. Это 1. 2. Региональность предоставляет новый масштаб для отказоустойчивости. То есть, если какая-то из зона, из зон доступности или даже группа зоны доступности полностью уходит в какой-нибудь молдан, ну по каким

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

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

12: Регионы состоят из 1 или нескольких зон доступности, но при этом не равняются зонам доступности. То есть регион такая широкая зона, географическая зона, которая состоит из нескольких зон доступности. Зона доступности содержит 1, 1.

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

14: Распределенности, то региональность регионы позволяют распределять географически очень широко, широко нагрузки, а внутри зоны это все равно ограничено каким-то регионом. Вот исторически яндекс клауд имеет уже

15: 3 зоны доступности тут нет подсказки, я забыл, где у нас в калужской.

16: Ну, короче, пардон, вот. И в 24 году мы запустили регион в Казахстане, в Караганде, состоящий из 1 зоны доступности, вот, как видно, сам.

17: Старта облака. Мы на самом деле думали уже про региональность. То есть у нас российский регион называется ru централ Ван. И последнее, что хотелось бы сказать в качестве введения, это что, облачный провайдер?

18: Собственно оперирует ресурсами следующий слайд и ресурсы могут быть

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

20: Машина косится с диском, который находится в той же зоне. Региональными ресурсами. У нас там являются, например, стороджи, сеть и так далее. Тех облачных провайдеров, которые есть мультирегиональность, могут быть ещё какие-то глобальные ресурсы. Ну тут

21: Уже вопрос, все зависит от того, какая архитектура конкретного облачного провайдера. Вот, собственно, когда мы подошли к этому всерьёз, к этому упражнению возник вопрос, а что же именно с точки зрения? А поскольку ям в яндекс клауде, ну вообще

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

23: Как работает авторизация, идентификация под должны ли подходить токены и cookie 1 региона к другому? Вот эти все вопросы, которые встали перед нами. И пока на эти вопросы мы не ответим. Мы, ну, не можем, собственно, стартовать проект как таковой, вот истории.

24: Мы много раз подходили к этому упражнению. 20. В 21 году мы думали, что, в принципе, мы можем запилить глобальный ам, который будет обслуживать все регионы к началу 22 года. Мы поняли, что на самом деле изолированные регионы могут быть хорошим. Дифферен

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

26: Данные так или иначе принадлежат америке, даже если их сервер хостится где-нибудь в европе или в другом месте. И тут мы могли бы сыграть им хорошую конкуренцию, говоря, что на самом деле данные ваши, да, и, ну, в 22 году была драматическая пауза.

27: В 23 году мы уже вернулись к проектам создания региона в Казахстане, но взяли за основу те принципы, которые, собственно, продумали в 22 году и создали, и как бы сформулировали эти критерии уже в качестве вариантов, которые хотели поддержать в нашем

28: Продукте. Так.

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

30: Ограничен 1 регионом.

31: Алло, мы должны. Дизайн должен позволять соответствовать комплаенсу и законодательству конкретных стран. Ну и при этом при всем мы должны клиенту предоставить продукт, кото

32: Которым он чувствует, что он пользуется 1 продуктом, а не входит просто в разные облака, в разных, в разных странах. Вот итого, что же, что же у нас получилось?

33: Во базовая модель такая, то есть регион каждый регион в яндекс клауде это независимая инсталляция яндекс клауд, там есть независимый ам токен токены cookie из 1 ама не подходят в другой, доступы хранятся в локальных базах неза.

34: Объект, субъекты, то есть пользователи и так далее. Глобальных ресурсов нет. И ресурсы строго региональные, зональные. Собственно, что же тут из общего, из единого продукта? То, что мы на самом деле представляем видимость или имитации?

35: Глобального ресурса в виде организации, то есть тенанта, в котором живут клиенты. И это в 1 очередь для ux наших клиентов и, во вторых, для безопасности. То есть организация это, это такой административный домен, через который, собственно, админ организации управляет основными политиками организации.

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

37: Что такое, как работает авторизация в яндекс клауд? Вот у нас есть некое дерево ресурсов, которые видят наши пользователи. То есть это корень этого дерева, это организация, в которой находятся ваши пользователи, ваши группы и ресурсы, которые находятся в облаках. При этом

38: У нас есть некоторый инвариант, который говорит о том, что организация это административный домен, то есть только пользователям, которые находятся в конкретной организации. Можно назначить доступ на ресурсы, которые находятся в этой организации, и доступы у нас иерархические, то есть

39: Если есть пользователь, пользователь в нашей организации, и мы выдадим роль 1, скажем, на какой-то, на облако 3, то все доступы, которые находятся в этой Роли, будут по иерархии доступны, ну, применимы ко всем ресурсам, которые находятся в облаке 3, и наоборот,

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

41: Видят, но это, это, собственно, это некий псевдо ресурс, в котором контейнер всех ресурсов, который все во всем облаке есть. То есть пользовательские ресурсы системные. Все есть. Соответственно, если выдать доступ наруто, означает, что этот доступ есть у субъекта, ну, вообще на все. Поэтому

42: Мы очень строго следим за этими доступами, скажем, там выдаём дежурным там саппорту, и там security следит, что эти доступы там очень, очень, очень гранулярные, нужны там для конкретного разбора конкретного кейса, вот, и что.

43: Что же мы делаем тут с точки зрения мультирегиона, с точки, да, ёлки, о, а кодовое слово следующий слайд мульти, мы, мы

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

45: Россия, соответственно, администратор настраивает организацию, создаёт там ресурсы пользователей, выдаёт доступы и так далее. Тут в какой-то момент бизнес, согласно бизнес требованиям, появляется необходимость создавать ресурсы в

46: Казахстан тогда администратор нажимает специальную кнопку, и в Казахстане создаётся некая теневая копия этой организации мы так внутри и называем шедоу организейшн, в которую копируются

47: Доступы, пользователи группы и доступы пользователей на уровне всей организации. Потом на эту теневую организацию мы накладываем специальные ограничения, которые означает, что

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

49: И так далее. Вот как это выглядит юикс, но вот, ну, сразу оговорюсь, что сейчас это за это technical preview, и в ui вы этого не увидите, надо как бы через саппорт запросить, но скоро это станет public привью. То есть

50: Вот тут видно, что у меня организация в России, а регион Казахстан не подключён. Если я нажму на Казахстан, мне скажут, вы хотите подключить Казахстан? Я скажу, конечно, конечно, хочу, конечно, хочу. Вот.

51: И он подключится, данные синхронизируются, и я теперь могу как администратор организации создавать облачные ресурсы как в России, так и в Казахстане. Вот теперь как бы самая, ну как бы, главная часть вот этого моего рассказа. А как это под капото?

52: Там работает и какие гарантии безопасности наш дизайн предоставляет нашим конечным клиентам. То есть вам и тем, кто будет пользоваться мультирегионом. На картинке расположены как бы 3 региона, регион 1, 2, 3. Это так удобнее как бы размышлять про, про гарантии.

53: Безопасности. В каждом регионе есть набор сервисных аккаунтов. Сервисные аккаунты. Такие роботные учетки. В данном случае это системные сервисные аккаунты, и темным цветом выделены сервисные аккаунты, которые представляют сам регион, скажем, в регионе 1 синеньким эт.

54: Это сервисный аккаунт региона 1, в регионе 2, 2 и так далее. И при этом в каждом же регионе есть сервисные аккаунты представителей соседних регионов. Вот эти и при настройке доверия между регионами происходит

55: Следующее, что каждый сервисный аккаунт 1 из регионов может имперсонировать свои сервисные аккаунты представителей соседних регионов по технологии ворот федерейшн, при этом сами сервисные

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

57: Организация в регионе 1 администратор нажал кнопку я хочу создавать ресурсы в регионе 2. Сервисный аккаунт р 1 имперсонирует свой сервисный аккаунт представитель в регионе 2 там создаёт эту, эту

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

59: Если по поводу попытаемся помоделировать угрозы, да, и при этом угроза будет максимально широкая, да, что если 1 из регионов полностью скомпрометирован, допустим, там какой-то мощный инсайдер, и при этом мы эту угрозу рассматриваем, не

60: Не в принципе против всей системы, а против конкретной организации. Ну, то есть, скажем, против какого-то банка, который существует в 2 регионах, да, то есть, если скомпрометирован регион 3, поскольку у, у сервисного аккаунта представителя

61: Региона 3. В регионе 1, региона 2. Нету, нет доступов собственно, к нашей, нашей, нашей организации. Из примера, то данная. Данный секьюрити инцидент не имеет никаких последствий для, для организации как таковой. То есть, если организация

62: Не представлен в регионе мажорный секьюрити. Инцидент этого региона на неё никак не влияет. Если скомпрометирован регион 2, то, конечно же, ресурсы, которые расположены, ресурсы организации, которые хостятся в регионе 2 потенциально под угрозой, но поскольку все администра

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

64: Мы скомпрометируем регион, в который является домашним для этой организации, то это гов, но, собственно, это, эта ситуация ничем не отличается от той ситуации, где у нас просто 1 регион, условно, условно, от текущего яндекс клауда. Вот.

65: Вот теперь чуть чуть поговорим про то, как выглядит аутентификация пользователей и вообще, как, как, как мы работаем с пользователями вот на данный момент в yandex cloud можно зайти 2 способами либо с помощью учетки яндекс id, либо с помощью

66: Федерации удостоверений, мы поддерживаем протоколы самл, ну, на самом деле мы поддерживаем опен айди, но пока ещё его не продуктировался для, для Конечных клиентов. Вот, и внутри мы, как бы, у нас есть такой сленг, мы как бы их назвали, что вот эти пользователи яндекс id

67: Не глобальный. В каком смысле, что я, как пользователь яндекса 1 могу создать несколько организаций и меня можно пригласить несколько организаций в яндекс клауд. То есть я как бы сам себе принадлежу. Я такой свободный гражданин, а пользователи федерации федерации настраиваются в организации.

68: Админом этой организации. Соответственно, они такие локальные, они локальные относительно этой организации. То есть они принадлежат, принадлежат этой организации. Вот, но независимо от того, как, по какой

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

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

71: Ну, у нас ещё есть вот там вся Ширап, который приватный апи, который позволяет держать единую сессию между всеми ними. Вот, но при этом, чем отличаются регионы, да, получается, что мы можем настроить регионы. Так что для тех пользователей

72: Которые хостятся в конкретном регионе, в конкретной организации. Этот регион может стать денти провайдером, а тот регион, в котором эти пользователи хотят хостить свои ресурсы, как в своей шедоу организации, станет сервис провайдером. То есть мы можем использоват

73: Нашу текущую технологию и connect и соединить произвольные количество регионов по стандартному протоколу соответственно.

74: Следующий оо регионы являются айдипи для своих локальных пользователей.

75: Ещё раз клик.

76: Ооо регион является сервис провайдером для локальных пользователей других регионов. И, но при этом есть исключения. Это пользователи яндекс id. Поскольку яндекс id являются такими глобальными пользователями, мы их не контролируем. Клик о, они

77: Входят в каждый регион независимо. То есть мы не знаем, Поли может в любой регион зайти независимо, а потом мы их как бы можем сшить.

78: Вот на старте мы выбрали схему, что у нас у каждого региона будет некоторый префикс ну, поскольку исторически у нас есть российский регион, он без префикса в Казахстане, у нас kz консоль, кейзет центр и так далее, и если мы сделаем

79: В регионы, там тоже тоже можем добавить, добавить префиксы. Вот.

80: Как происходит, собственно, логин пользователя? Пользователь приходит в ту консоль, в которой у него, он предполагает, что у него находятся ресурсы. Неважно, где у него находится организация, он приходит в ту консоль, в которой он хочет потрогать ресурсы. То есть он приходит, допустим, в консоль.

81: Р. 1 консоль по протоколу опен id connect, который является внутренним внутри региона мы проверяем, что, ну, собственно, этого пользователя идентифицируем, если у пользователя сессии нет, его спрашивают а как ты хочешь войти, как яндекс id или как федеративный пользователь?

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

83: Лежит организации, в которой основной регион находится, скажем, в другом р. 2, то в данном случае эта коммуникация уже происходит между р. 1, р. 2, по тому же протоколу н. 1, но р. 2 выступляет, выступает

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

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

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

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

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

89: Собственно, subject id при этом если это пользователь яндекс id, то мы выше пишем просто волшебное слово яндекс, и мы это знаем, что а в subject id впишем, ну собственно идентификатор пользователя в яндексе и в любом регионе мы просто его узнаем, а если это пользователи конкретного региона,

90: Федеративный, то мы выше пишем айдентики конкретного региона и, собственно, можем написать локальный идентификатор этого пользователя независимости и иметь разные идентификаторы этих пользователей в разных регионов, но при этом уметь иметь возможность их сшивать

91: Вот.

92: Сейчас я, собственно, до этого я рассказывал, как, как работает этот ux для администратора, то есть администратор настраивает пользователи группы, доступы в основном регионе, все, осталь в другие регионы, все это

93: Распространяется через организацию. А теперь как, собственно, какой, какой опыт для, для Конечных пользователей? Вот напомню, что организация такой, это глобальный ресурс. Облако, облако это региональный ресурс. Я, кстати, забыл про это сказать, что все ресурсы в облаке строго

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

95: Облаков в организации между регионами. И я могу увидеть список, список своих облаков во всех регионах. Вот в данном случае, вот, и как это как цвет называется циан, да, вот, вот, вот my set claude, это

96: Собственно, это облако, то есть организация у меня в России, а облако из Казахстана. И, как видите, console яндекс клау, это, собственно, консоль в России. И если я теперь кликну на, на моё казахстанское облако, если я клик,

97: Ну вот я бесшовно переключусь в Казахстан, консоль, яндекс, клауд, и при этом не, мне не надо будет вводить никакие криды, идентифицироваться. Все это должно произойти для меня бесшовно. Почему?

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

99: Как у ас клиента региона России, консолька, какао, клиента региона. Казахстан это разные аос клиенты, поскольку они подключены к разным авторизационным серверам. Соответственно, между ними никакого доверия быть не может. И, соответственно, если мы

100: Скажем, пользователя из консоли российской отправляем в Казахстан, в консоль Казахстана, то это уже нестандартный опенайди, коннект, нестандартный Аус, то есть в стандартном аусе пени коннект авторизационный танец начинает

101: Сам клиент да, но в openid connect стандарте есть специально отдельно раздел, который говорит можно как если очень хочется, логинить пользователя из внешней системы ну например это можно делать так нужно клиент должен поддерживать специальный инише.

102: Логин ури, у него должен быть обязательно обязательный параметр ишью. То есть, который говорит, в каком туда надо прописать, в каком, собственно, авторизационном сервере пользователя нужно авторизовать. Ну и можно ещё опционально сказать,

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

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

105: А какой регион инициировал попытку пользователя перейти между регионами? В какой регион мы пользователя пытаемся отправить, в какой Аус клиент и какого пользователя вот это примерно вот так вот выглядит. То есть пользователь видит, скажем, условно, список облаков в его организации.

106: 1 из облаков, скажем, он сейчас находится в консоли региона, 1 1 из облаков из региона, 2 пользователь кликает на это облако и под капотом, под капотом браузер.

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

108: Консоли другого региона. И это собственно и есть вот этот initiate логин ури который open иди коннект. Спецификация предлагает тот под капотом проверяет что это интент тикей. Интент предназначался ему как региону, ему

109: Как и у aos клиенту, чтоб все подписи верны, и в итоге он, собственно, авторизует пользователь против своего же собственного авторизационного сервера и передаёт специально наш закрытый параметр в arsi ну как закрытый параметр в oc login хинт, в котором

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

111: Всяких необходимости вывести криды окажется в другом консоли другого региона. Вот и того и того.

112: Он так забавно бжикает, но ничего не делает. Следующий оо итого, что мы сделали, сделали архитектуры независимые регионы с ограниченным доверием у нас.

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

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

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

116: Опасности, которую мы сами себе и поставили в цель, вот что осталось.

117: Следующий слайд оо за кадром. У нас на самом деле есть дизайн как как можно на контролплейне дружить? Наши же сервисы разных регионов. У нас есть дизайн как все это засунуть в 1

118: Соль, ещё много, много интересных деталей, если будет интересно и на кусочек того, что я рассказал, мы подали патент, он сейчас находится на рассмотрении. Вот. И теперь, наверное, уже, ну, это просто картинка для Фана из внутренней документации.

119: Спасибо, Антон.

120: Давайте вот, ребят, дайте микрофон, пожалуйста.

121: Вот нет, вот сзади был в подтяжках вас 1.

122: Здравствуйте. Ага. Меня зовут Андрей. Сбер. Спасибо за доклад. У меня 2 вопроса. 1. У вас все дата центры по карте сосредоточены практически в 1 месте. Вы

123: Не думали все-таки чуть чуть их раскидать по России, там, не знаю, куда-нибудь в сторону камчатки, а то есть, грубо говоря, Москва, ну, потому что они все рядом с Москвой, Казахстан и как

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

125: Регион это, по сути, независимое облако, да, которое можно подружить регионы друг между другом, но в целом оно абсолютно независимо, да, и условно, если ты разворачиваешь базу данных в каком-то регионе и указываешь какое-то количество реплик, то эти реплики

126: Находится в этом регионе. Соответственно, зоны доступности в рамках 1 региона. Они физически не могут быть растянуты на большую, так сказать, физическую территорию из за того, что большинство распределённых систем имеет требования

127: Собственно, колейности на передачу данных. Поэтому, если говорить про там вообще абстрактно, там какие-то зоны доступности в рамках там одних регионов, на это есть свои ограничения. Вот, надеюсь, ответил. Вот если речь идёт про то, что плани

128: Ли там какие-то именно отдельные регионы. Вот. Но это немножко аутосо нашего доклада. Предлагаю сфокусироваться на скорее технологиях. Спасибо. И 2 вопрос у вас есть возможность

129: Миграция из региона в регион я так понял, возможность сделать как бы shadow тень своего, а есть возможность именно перенести я создал организацию в России, решил, что хочу переехать в Казахстан и просто её 1 кноп.

130: Мигрировать туда. Ну или нужно перезаводить все. Угу. Если говорить про конкретно, про миграции данных, такой задачи нет. А передай, пожалуйста, вот сосед твой.

131: Про миграцию конкретной организации. Ну, там проще просто создать новую организацию и внутри региона переносить облака между организациями у нас это практически бесплатно. Да, пожалуйста, можно потом ты. Ага. А потом там ещё

132: Спасибо за доклад, да, ещё спасибо за классную фичу с юаем. Ага. Потому что, находясь в консоли российской и в консоли казахстанской, сразу видно, что это облачка из Казахстана. Там на скриншоте у вас было, ну, между вкладками не запута.

133: То есть все точно это очень удобно. Мы вот не дождались такой фичи, когда вот это вот можно объединить, создать шедоу, вот эту организацию. У нас организация в Казахстане, организация здесь нет ли у вас, вот я видел, там что-то Проскочило.

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

135: Конкретный кейс, просто проще его обсудить. Спасибо конкретно. Возможно, вам нужно заехать на эту технологию, и тогда будет вот как на том красивом скриншоте. Там ещё был вопрос, и потом сюда вот. А, ответили, да, да, я просто коллеги.

136: Привет, Максим. Селектел. Вы построили классный, классное юай решение для веба, да, где у вас там консоли классно переключаются. А что по поводу кли клиентов и терраформ крупных клиентов? Как они?

137: Ну, придётся страдать. Условно, терраформа, придётся указывать, ну, собственно, конкретный ипоит конкретного региона для того, чтобы там разворачивать ресурсы. Понимаю, это был трейдов, который вы, да, ну, собственно, это трейдов, да, это трейдов.

138: Ну, давай добавим все-таки, что мы прорабатывали этот аспект не то чтобы мы его оставляли за кадром. Именно как могла бы выглядеть кли, когда ты пишешь там ac, ресурс, менеджер какой-то cloud криейт и указываешь там параметры облака, да, как сделать так, чтобы оно создалось, допустим, в целевом регионе, но аудентификация взялась из 1 и с точки

139: Аутентификации в cli, там можно попробовать сделать так. Ну, есть конфиги у кли, да, это профайлы так называемые, чтобы аутентификация бралась, как здесь была из main региона, но ты в cli просто явно говорил там target регион, там, кз, и тогда бы получалось примерно как здесь.

140: Можно было бы прокрутиться там условно через браузер, имея активную сессию ру централе, по факту получить токен в Казахстане и создать ресурс в Казахстане. То есть поправляй меня, Антон, в этом плане единственное, что добавляется так или иначе.

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

142: Чуть сложнее, потому что если вы терраформ катаете из 1 региона в другой, тогда, очевидно, вам нужна примерно схема, как нарисовано на картинке, нужна имперсонация сервисного аккаунта региона. 1 регион, 2. Через федерацию удостоверения, например, ну, я, я услышал вопрос чуть по другому, что есть ли центральная точ,

143: Ну, то есть, можно ли в 1 терраформ, файле описать ресурсы в разных регионах? Ну, то есть, как бы, в данный момент нет, ну, придётся 2 делать 2 профайла, подключённых к разным регионам, собственно, в разные регионы. Н, ну, катать, да.

144: Вот это, собственно, это действительно трейдо. Можно срезать угол на общей идентификации, но иметь терраформ придётся иметь 2 разных провайдера. Окей, понял. Спасибо. Ага. Вот, передай, пожалуйста, вперёд.

145: Спасибо за доклад. Большую часть уже ответили. Вопрос про вот эту теневую организацию, которая создаётся и в ней, я так понимаю, можно эти ресурсы, которые именно к этому региону относятся, создать, там, что

146: Произойдёт, если такие же ресурсы будет задавать в основной, вот в источнике правды создадим те же самые ресурсы. То есть возможно ли такое и если это источник правды, а там уже есть

147: Такие ресурсы, они перетрутся или это просто невозможно формально? Ага, хорошо, хороший вопрос. Смотри, организация это, собственно, теннант в тенанте у тебя есть пользователи и

148: И, а вот то, что мы называем облаками, ну, у нас исторически в яндекс клауде называется облако. Облако, это, собственно, контейнер ресурсов. Ну, в google клауде это, скажем, проект, соответственно, проект или облако ты создаёшь в конкретном регионе, и они, в принципе, не могут пересечься. То есть ты

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

150: Друг с другом не конфликтуют. И про кросс авторизацию, то, что показывали флоу, пользователь должен сам указать, что он из другого региона. То есть нет какой-то проверки. Допустим, я логинюсь в Казахстане.

151: Он меня там не находит и пошёл проверить в головном. Да, отличный вопрос для пользователей яндекс id. Ты сможешь залогиниться в любом регионе, независимо от того, есть там у тебя организация или нет. Если

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

153: Именно информацию про федеративные, про федерации синхронизируем между регионами. Это как бы не сенсативная информация. Мы в момент Логина поймём, что на самом деле ты, как пользователь, принадлежишь федерации в другом регионе, тебя там отпра,

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

155: Да, вот, да, спасибо за доклад. Меня Игорь зовут МТС. Слушай, я только сейчас тебя узнал, я меняюсь. Да. Вот, да, спасибо. На самом деле почти все вопросы.

156: Ответили, которые были. Меня просто вот мучает вопрос, почему кз без центра? Вот.

157: Ох.

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

159: Вот, товарищ, я забыл, как зовут, извини, из Сбера, спрашивал, что как раз, когда на старте облака задумывались, что ru center это как раз тот регион, который вот здесь центральный, и когда, может быть, когда-нибудь мы на камчатке, у нас будет ру.

160: Ну, там фарист, да, фарист, да, неважно, да, вот, да. Ну, соответственно, в Казахстане, наверное, как бы, такая ситуация не предвидится. То есть, он сам по себе не очень большой, поэтому там все в этом смысле. Хорошо. Спасибо.

161: Большая, да?

162: Не а, ну давай, давай, давай, да.

163: Данила, восход. Спасибо большое за доклад. Вот предыдущий коллега спраши, ну, задавал вопрос по поводу авторизации в разных регионах. А вот что, если будут одни и те же пользователи в России, в Казахстане, и вот

164: Как определить, кто из них главный, если вот вы говорили, что происходит синхронизация при авторизации через яндекс id. Угу. А вот как определить, кто главный, тогда как избежать сплитбрейна этого, как вы его обходите? Как избежать? Что ещё раз, ну, кто, кто главный?

165: Как избежать сплитбрейна? То есть, ну вот я главный или я главный. Как, как это решить при условии, что 2 пользователя одинаковые в 2 зонах. Ага. Ну, спасибо. Да, спасибо за вопрос. 2 пользователя одинаковых 2 регионах.

166: Могут быть только в том случае, если это пользователь яндекс id, если это пользователь яндекс id. Следовательно, это и есть один и тот же пользователь, соответственно, какие бы он не имел доступы и там, и там ему, собственно, это легитимные доступы этого пользователя. Ага, да.

167: Да, спасибо за доклад. Меня зовут Алексей. Такой вопрос тоже к неймингу. Там было ru center. А. Б и д. Да, где ц. Читайте анонсы. Да, был ц.

168: Star д проект по большой миграции из ц в д и не только в д. Давайте последний вопрос и будем призы переходить к следующему докладу. Остальные вопросы.

169: Здравствуйте, меня зовут малади, агентство правовой информации воробьёвы горы. Мне интересно, условно есть организация, у неё мастер регион, это Казахстан, 2 регион, это Москва. И вы

170: Сказали, что условно создаётся пользователь весь контроль прав ролей. Пользователь происходит в 1 регионе мастере.

171: А что произойдёт, если уборщица там кабель дёрнет, Казахстан отрубился. Можно ли создавать новых пользователей, контролировать права? Все также? Или надо ждать, пока мастер регион встанет? Отличный вопрос. Спасибо большое.

172: Да, поправка, доступы синхронизируем мы доступы на уровне организации. То есть, если, если кто-то админ там едет всей организации, мы вот эти доступы синхронизируем при этом на уровне

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

174: Выдернул кабель там, ну тут надо разбирать уже конкретно режимы отказа, да, если выдернул кабель, вот по которому идёт эта синхронизация, это внутренний внутренний канал между яндексом, то пока доступы есть

175: Да, пользователь может ими пользоваться, но единственное, что их какие-то вот эти на уровне организации отозвать не удастся, да, но при этом все будет работать или там новые нельзя будет создать, если радикально 1 из регионов упал, что даже интернета нет. Ну,

176: Понятно, что пользователь, наверное, не сможет аутентифицироваться в своём домашнем регионе, если, собственно, домашний, если

177: Ну, скажем, поль, домашний регион, если у него находится, там, наверное, все хорошо, да, но он, допустим, потенциально не может получить доступ к соседнему региону, если, если там железный занавес упал, как это было в Казахстане, да, несколько лет назад, ну, это, это, это понятная угроза, но она, скажем,

178: Наверное, предсказуемо есть сервисные аккаунты, и можно создать сервисный аккаунт в конкретном регионе, дать ему какие-то break glass, правила доступы и сохранить ключи от сервисного аккаунта это как бы легитимный способ.

179: И хранить беллас. Ещё мы думали иметь возможность создавать федерации именно для Брек ласса в других регионах. Ну, как бы, но такая есть идея, но пока мы не реализовали, ну, как идея, в принципе, условно, такая федерация, которая создаёт пользователь только в теневой част,

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

181: Что это прям жизненный вопрос мне понравился. Вот последний вопрос, потому что

182: А сколько можно? Давай 3, потому что в этот раз это хорошо. 3.

183: Ну, давайте ещё господину в потяжка.

184: Спасибо большое, Антон. Спасибо. Поаплодируем ещё раз антону.