Общие вопросы | Яндекс.Облако — Документация
Для чего нужны облачные вычисления?
Яндекс.Облако предоставляет масштабируемые вычислительные мощности: вы можете быстро создавать и запускать виртуальные машины по мере необходимости и останавливать их, если нагрузка снизилась. Использование облачных ресурсов снижает ваши затраты на IT-инфраструктуру: вы платите только за те ресурсы, которые используете.
Управлять облачной инфраструктурой проще — вы можете сконцентрироваться на решении бизнес-задач вместо обслуживания серверов.
Что я могу делать с виртуальными машинами Яндекс.Облака?
- Использовать только те вычислительные мощности, которые необходимы для решения вашей задачи. Если для решения задачи вам необходимо дорогостоящее мощное оборудование, его необязательно покупать. Вы можете создать виртуальную машину в Яндекс.Облаке и использовать ее, когда это необходимо.
- Быстро масштабировать вычислительные мощности под ваши потребности. Вы можете запускать дополнительные виртуальные машины в периоды пиковых нагрузок и останавливать в периоды спада.
- Разворачивать на виртуальных машинах приложения, которые должны быть постоянно доступны. Вы можете не беспокоиться об обеспечении бесперебойной работы сервера, Яндекс.Облако сделает это за вас. Сосредоточьтесь на создании работающих программ.
- Настроить резервное копирование, чтобы было проще восстановить данные в случае потери.
- Создавать и распространять образы дисков виртуальной машины. С помощью образов можно быстро разворачивать ваше программное обеспечение на других виртуальных машинах.
- Автоматизировать управление виртуальными машинами с помощью API и скриптов в интерфейсе командной строки.
Подробнее о виртуальных машинах Яндекс.Облака читайте в разделе Виртуальные машины.
Чем виртуальные машины Яндекс.Облака отличаются от обычного хостинга?
Традиционный хостинг предлагает взять в аренду ресурсы заранее оговоренной производительности на фиксированное время. Виртуальные машины Яндекс.Облака позволяют работать с облачными ресурсами как со своим личным дата-центром. При этом вы получаете все преимущества отказоустойчивой инфраструктуры дата-центров Яндекса.
Когда меняются ваши требования к производительности, вы можете масштабировать свою облачную инфраструктуру. Таким образом, можно контролировать, сколько ресурсов вы используете в любой момент времени и сколько вы за них платите.
Также вы получаете полный контроль над статусом виртуальных машин. Вы можете запускать и останавливать виртуальные машины, когда вам это нужно. Вы можете настроить конфигурацию программного обеспечения ваших виртуальных машин и менять ее по мере необходимости. С помощью образов и снимков дисков вы можете легко переносить данные между виртуальными машинами.
Как начать работать с виртуальными машинами Яндекс.Облака?
Вы можете создать свою первую виртуальную машину по одному из сценариев, описанных в разделе Начало работы с Compute Cloud.
Как получить доступ на виртуальную машину?
Вы можете подключаться к виртуальной машине с другой виртуальной машины в той же облачной сети. Для подключения используйте внутренний IP-адрес или FQDN.
Если при создании виртуальной машине был присвоен публичный IP-адрес, то вы можете использовать его для подключения к виртуальной машине из Интернета.
IP-адреса, FQDN и другую информацию можно узнать в консоли управления, в блоке Сеть на странице виртуальной машины.
Подробнее читайте в разделе Сеть на виртуальной машине
Для подключения к виртуальным машинам Linux используйте SSH. К виртуальным машинам Windows подключайтесь по RDP.
Как быстро я могу изменить производительность моих информационных систем?
Вы можете изменить производительность вашей информационной системы одним из следующих способов:
- Заранее создайте виртуальные машины с нужными характеристиками и установленным программным обеспечением. В периоды пиковых нагрузок достаточно запустить эти виртуальные машины для увеличения производительности информационной системы. На время спада нагрузки вы можете остановить часть виртуальных машин, чтобы не оплачивать потребление лишних ресурсов.
- Если вам часто требуются новые виртуальные машины с одинаковой конфигурацией, вы можете сделать образ загрузочного диска и использовать
Вопросы и ответы про Compute Cloud | Яндекс.Облако
Общие вопросы
Для чего нужны облачные вычисления?
Яндекс.Облако предоставляет масштабируемые вычислительные мощности: вы можете быстро создавать и запускать виртуальные машины по мере необходимости и останавливать их, если нагрузка снизилась. Использование облачных ресурсов снижает ваши затраты на IT-инфраструктуру: вы платите только за те ресурсы, которые используете.
Управлять облачной инфраструктурой проще — вы можете сконцентрироваться на решении бизнес-задач вместо обслуживания серверов.
Что я могу делать с виртуальными машинами Яндекс.Облака?
- Использовать только те вычислительные мощности, которые необходимы для решения вашей задачи. Если для решения задачи вам необходимо дорогостоящее мощное оборудование, его необязательно покупать. Вы можете создать виртуальную машину в Яндекс.Облаке и использовать ее, когда это необходимо.
- Быстро масштабировать вычислительные мощности под ваши потребности. Вы можете запускать дополнительные виртуальные машины в периоды пиковых нагрузок и останавливать в периоды спада.
- Разворачивать на виртуальных машинах приложения, которые должны быть постоянно доступны. Вы можете не беспокоиться об обеспечении бесперебойной работы сервера, Яндекс.Облако сделает это за вас. Сосредоточьтесь на создании работающих программ.
- Настроить резервное копирование, чтобы было проще восстановить данные в случае потери.
- Создавать и распространять образы дисков виртуальной машины. С помощью образов можно быстро разворачивать ваше программное обеспечение на других виртуальных машинах.
- Автоматизировать управление виртуальными машинами с помощью API и скриптов в интерфейсе командной строки.
Подробнее о виртуальных машинах Яндекс.Облака читайте в разделе Виртуальные машины.
Чем виртуальные машины Яндекс.Облака отличаются от обычного хостинга?
Традиционный хостинг предлагает взять в аренду ресурсы заранее оговоренной производительности на фиксированное время. Виртуальные машины Яндекс.Облака позволяют работать с облачными ресурсами как со своим личным дата-центром. При этом вы получаете все преимущества отказоустойчивой инфраструктуры дата-центров Яндекса.
Когда меняются ваши требования к производительности, вы можете масштабировать свою облачную инфраструктуру. Таким образом, можно контролировать, сколько ресурсов вы используете в любой момент времени и сколько вы за них платите.
Также вы получаете полный контроль над статусом виртуальных машин. Вы можете запускать и останавливать виртуальные машины, когда вам это нужно. Вы можете настроить конфигурацию программного обеспечения ваших виртуальных машин и менять ее по мере необходимости. С помощью образов и снимков дисков вы можете легко переносить данные между виртуальными машинами.
Как начать работать с виртуальными машинами Яндекс.Облака?
Вы можете создать свою первую виртуальную машину по одному из сценариев, описанных в разделе Начало работы с Compute Cloud.
Как получить доступ на виртуальную машину?
Вы можете подключаться к виртуальной машине с другой виртуальной машины в той же облачной сети. Для подключения используйте внутренний IP-адрес или FQDN.
Если при создании виртуальной машине был присвоен публичный IP-адрес, то вы можете использовать его для подключения к виртуальной машине из Интернета.
IP-адреса, FQDN и другую информацию можно узнать в консоли управления, в блоке Сеть на странице виртуальной машины.
Подробнее читайте в разделе Сеть на виртуальной машине
Для подключения к виртуальным машинам Linux используйте SSH. К виртуальным машинам Windows подключайтесь по RDP.
Как быстро я могу изменить производительность моих информационных систем?
Вы можете изменить производительность вашей информационной системы одним из следующих способов:
- Заранее создайте виртуальные машины с нужными характеристиками и установленным программным обеспечением. В периоды пиковых нагрузок достаточно запустить эти виртуальные машины для увеличения производительности информационной системы. На время спада нагрузки вы можете остановить часть виртуальных машин, чтобы не оплачивать потребление лишних ресурсов.
- Если вам часто требуются новые виртуальные машины с одинаковой конфигурацией, вы можете сделать образ загрузочного диска и использовать его при создании виртуальных машин.
Какие операционные системы поддерживаются виртуальными машинами Яндекс.Облака?
Поддерживаются операционные системы на базе Linux и Windows.
Для популярных дистрибутивов этих систем доступны публичные образы загрузочного диска, протестированные в Яндекс.Облаке.
Соответствует ли сервис требованиям закона №152-ФЗ О персональных данных
?
Да. Вы можете ознакомиться с полным заключением по результатам аудита системы защиты.
Как обратиться в службу технической поддержки?
Вы можете обратиться в службу технической поддержки в разделе Поддержка
в консоли управления.
Виртуальные машины
Технические характеристики
Какую конфигурацию виртуальной машины (память, процессор) я могу использовать?
Когда вы создаете виртуальную машину, вы выбирате уровень производительности vCPU виртуальной машины. Уровень определяет необходимое количество и производительность ядер процессора (vCPU). Вы можете выбрать подходящее количество вычислительных ресурсов из расчета планируемой нагрузки.
Подробнее читайте в разделе Уровни производительности vCPU.
Как изменить объем памяти и количество ядер, выделенных виртуальной машине?
Подробнее читайте в разделе Изменить вычислительные ресурсы виртуальной машины.
Операции с виртуальными машинами
Могу ли я скопировать или склонировать существующую виртуальную машину?
Да, вы можете создать снимки дисков, подключенных к виртуальной машине и использовать их при создании новой виртуальной машины.
Могу ли я перенести виртуальную машину в другую зону доступности?
Непосредственно изменить зону доступности, в которой находится виртуальная машина, нельзя. Однако вы можете создать копию виртуальной машины в нужной зоне доступности.
Могу ли я перенести виртуальную машину в другой каталог?
Непосредственно изменить каталог, которому принадлежит виртуальная машина, нельзя. Однако вы можете создать копию виртуальной машины в нужном каталоге.
Если я нечаянно удалю свою виртуальную машину, можно ли ее восстановить?
Нет, удаление виртуальной машины — необратимая операция.
Чтобы не потерять данные при случайном удалении, вы можете настроить резервное копирование дисков с помощью снимков, или указать, что диски не должны автоматически удаляться при удалении виртуальной машины.
Диски и снимки
Сколько дискового пространства я могу использовать для виртуальной машины?
Ограничения на диски приведены в разделе Квоты и лимиты.
Могу ли я изменить размер диска?
Да, вы можете изменить размер диска через API Яндекс.Облака.
Что происходит с данными при удалении виртуальной машины?
При выборе диска для подключении к виртуальной машине можно указать, должен ли быть удален диск при удалении виртуальной машины. Это можно выбрать как при создании виртуальной машины, при изменении и при подключении нового диска к ней.
Если к виртуальной машине были подключены ранее созданные диски, то при удалении виртуальной машины они будут отключены. Данные на диске при этом сохраняются, в дальнейшем этот диск можно подключить к другой виртуальной машине.
Если вы хотите, чтобы диск был удален вместе с виртуальной машиной, это необходимо указать в одной из операций: при создании виртуальной машины, при изменении или при подключении диска к ней. Такие диски будут удалены при удалении виртуальной машины.
Нужно ли останавливать виртуальную машину, чтобы сделать снимки дисков? Нужно ли дожидаться завершения создания снимков дисков, прежде чем запускать виртуальную машину?
Останавливать виртуальную машину необязательно. Однако необходимо учитывать, что снимок содержит только те данные, которые записаны на диск в момент создания снимка. Вам необходимо самостоятельно позаботиться о целостности данных. О том, как создать снимок диска читайте в разделе Создать снимок диска.
Создание снимка выполняется асинхронно. Возобновить запись на диск можно сразу после команды создания снимка, не дожидаясь завершения создания снимка.
Аварийное восстановление
Что делать, если диски виртуальной машины работают со сбоями
Важно
Не пытайтесь перезагрузить ВМ самостоятельно. Это может привести к потере данных.
Если вы заметили, что обращение к одному или нескольким дискам вашей ВМ происходит с ошибками:
- Создайте новый диск и подключите его к виртуальной машине.
- Скопируйте важные данные с поврежденных дисков на новый диск. Не используйте при чтении файлов флаг O_DIRECT.
- После того, как все важные данные скопированы, отключите поврежденные диски от ВМ и удалите их.
- Если скопировать данные не удалось и диск важно сохранить, напишите нам. Мы сами выключим ВМ и проведем проверку целостности диска. Проверка может занять несколько дней.
Группы виртуальных машин
Что такое Instance Groups?
Instance Groups — это компонент, с помощью которого можно создавать, эксплуатировать и масштабировать группы однотипных виртуальных машин в инфраструктуре Yandex Compute Cloud.
С Instance Groups вы можете:
- создавать группы с необходимым количеством виртуальных машин и параметрами производительности;
- увеличивать вычислительные мощности по мере необходимости и уменьшать, если нагрузка снизилась.
Вы взаимодействуете с группой виртуальных машин как с единой сущностью в инфраструктуре Yandex Compute Cloud. Благодаря этому вы можете управлять внутренними настройками группы виртуальных машин в соответствии с требованиями вашего приложения.
Как рассчитывается стоимость использования групп виртуальных машин?
Создание группы виртуальных машин не тарифицируется.
Все остальные услуги Облака, например, создание виртуальных машин или выделение внешних IP-адресов, тарифицируются обычным образом.
Как не переплатить лишнего?
Чтобы выбрать подходящее вам количество виртуальных машин и платить минимальную стоимость:
- Оцените, сколько потребуется вычислительных ресурсов для вашего сервиса, и посмотрите примеры расчетов и правила тарификации для Yandex Compute Cloud.
- Старайтесь чаще следить за нагрузкой на сервис в разное время суток.
Лицензирование
Правила использования программного обеспечения Microsoft регламентируются условиями лицензионного соглашения с Microsoft, заключаемого при приобретении продуктов Microsoft. Ответственность за соблюдение условий лицензирования Microsoft несет пользователь. Ниже изложены рекомендации по лицензированию. Вы не обязаны полагаться на изложенные положения, они не имеют юридической силы. Если у вас есть вопросы по поводу лицензирования и прав на использование программного обеспечения Microsoft, проконсультируйтесь со своим юридическим отделом или торговым посредником Microsoft. Информация на этой странице соответствует текущим условиям использования продуктов Microsoft.
Какие отношения существуют между Microsoft и Яндекс.Облаком?
Яндекс.Облако имеет лицензию н
В этом разделе описано, как работать с Яндекс.Облаком изнутри виртуальной машины через API или CLI.
Для автоматизации работы с Яндекс.Облаком изнутри виртуальной машины рекомендуется использовать сервисные аккаунты. Это безопаснее — вам не надо сохранять свой OAuth-токен на виртуальной машине и вы можете ограничить права доступа для сервисного аккаунта.
Для сервисного аккаунта сделана упрощенная аутентификация через API и CLI изнутри виртуальной машины. Чтобы пройти аутентификацию:
- Если у вас еще нет сервисного аккаунта, создайте его и настройте права доступа для него.
- Привяжите сервисный аккаунт к виртуальной машине.
- Аутентифицируйтесь изнутри виртуальной машины.
Привяжите сервисный аккаунт
Привяжите сервисный аккаунт к существующей или к создаваемой виртуальной машине. Привязать можно только один сервисный аккаунт.
Чтобы привязать сервисный аккаунт к виртуальной машине, необходимо иметь разрешение на использование этого аккаунта. Это разрешение входит в роли iam.serviceAccounts.user, editor и выше.
К существующей виртуальной машине
Если у вас еще нет интерфейса командной строки Яндекс.Облака, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.
Обновите параметры виртуальной машины, указав сервисный аккаунт с помощью опции --service-account-name или --service-account-id:
yc compute instance update my-instance --service-account-name test
Воспользуйтесь методом update для ресурса Instance. В свойстве serviceAccountId укажите идентификатор сервисного аккаунта.
К создаваемой виртуальной машине
Консоль управления
CLI
API
В консоли можно привязать сервисный аккаунт из того же каталога, где создается виртуальная машина. Если сервисный аккаунт лежит в другом каталоге, воспользуйтесь CLI или API.
Чтобы привязать сервисный аккаунт, укажите его при создании виртуальной машины. Вы можете выбрать один из существующих сервисных аккаунтов или создать новый:
Если у вас еще нет интерфейса командной строки Яндекс.Облака, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.
Создайте виртуальную машину, указав сервисный аккаунт с помощью опции --service-account-name или --service-account-id:
yc compute instance create \
--name my-instance \
--network-interface subnet-name=default,nat-ip-version=ipv4 \
--ssh-key ~/.ssh/id_rsa.pub \
--service-account-name my-robot
Воспользуйтесь методом create для ресурса Instance. В свойстве serviceAccountId укажите идентификатор сервисного аккаунта.
Аутентификация изнутри виртуальной машины
Чтобы аутентифицироваться изнутри виртуальной машины от имени привязанного сервисного аккаунта:
Что такое VPC?
В наше время для разворачивания сервисов есть самые разные возможности. Уверен, кто-то до сих пор держит сервер под столом администратора, хотя, надеюсь, таких историй становится всё меньше.
Сейчас сервисы стараются уходить в публичные облака, и как раз тут они сталкиваются с VPC. VPC – это часть публичного облака, которая провязывает пользовательские, инфраструктурные, платформенные и прочие мощности воедино, где бы они ни находились, в нашем Облаке или за его пределами. При этом VPC позволяет не выставлять без необходимости эти мощности в интернет, они остаются в пределах вашей изолированной сети.
Как виртуальная сеть выглядит снаружи
Под VPC мы понимаем прежде всего оверлейную сеть и сетевые сервисы, такие как VPNaaS, NATaas, LBaas и т. д. И всё это работает поверх отказоустойчивой сетевой инфраструктуры, о которой уже была отличная статья здесь же, на Хабре.
Давайте посмотрим на виртуальную сеть и ее устройство повнимательнее.
Рассмотрим две зоны доступности. Мы предоставляем виртуальную сеть – то, что мы назвали VPC. Фактически она определяет пространство уникальности ваших «серых» адресов. В рамках каждой виртуальной сети вы полностью управляете пространством адресов, которые можете назначать вычислительным ресурсам.
Сеть глобальна. При этом она проецируется на каждую из зон доступности в виде сущности под названием Subnet. Для каждой Subnet вы назначаете некий CIDR размером 16 или меньше. В каждой зоне доступности может быть больше одной такой сущности, при этом между ними всегда есть прозрачный routing. Это значит, что все ваши ресурсы в пределах одной VPC могут «общаться» друг с другом, даже если они находятся в разных зонах доступности. «Общаться» без выхода в интернет, по нашим внутренним каналам, «думая», что находятся в пределах одной частной сети.
На схеме выше показана типичная ситуация: две VPC, которые где-то пересекаются по адресам. Обе могут принадлежать вам. Например, одна для разработки, другая – для тестирования. Могут быть просто разные пользователи – в данном случае это неважно. И в каждую VPC воткнуто по одной виртуальной машине.
Усугубим схему. Можно сделать так, чтобы одна виртуальная машина втыкалась сразу в несколько Subnet. И не просто так, а в разных виртуальных сетях.
При этом, если вам нужно выставить машины в интернет, это можно сделать через API или UI. Для этого необходимо настроить трансляцию NAT вашего «серого», внутреннего адреса, в «белый» – публичный. Выбрать «белый» адрес вы не можете, он назначается случайным образом из нашего пула адресов. Как только вы перестаёте пользоваться внешним IP, он возвращается в пул. Платите вы только за время использования «белого» адреса.
Также есть возможность выдать машине доступ в интернет с помощью NAT-инстанса. На инстанс можно зароутить трафик через статическую таблицу маршрутизации. Мы предусмотрели такой кейс, потому что он бывает нужен пользователям, и мы об этом знаем. Соответственно, в нашем каталоге образов лежит специально сконфигурированный NAT-образ.
Но даже когда есть готовый NAT-образ, настройка может быть сложной. Мы понимали, что для некоторых пользователей это не самый удобный вариант, поэтому в итоге сделали возможность включать NAT для нужной Subnet в один клик. Эта фича пока ещё в закрытом preview-доступе, где обкатывается с помощью участников сообщества.
Как виртуальная сеть устроена изнутри
Как взаимодействует с виртуальной сетью пользователь? Сеть смотрит наружу своим API. Пользователь приходит в API и работает с целевым состоянием. Через API пользователь видит, как всё должно быть устроено и настроено, при этом он видит статус, насколько действительное состояние отличается от желаемого. Это картина пользователя. А что происходит внутри?
Мы записываем желаемое состояние в Yandex Database и идем конфигурировать разные части нашей VPC. Оверлейная сеть в Яндекс.Облаке построена на основе избранных компонентов OpenContrail, который с недавнего времени носит название Tungsten Fabric. Сетевые сервисы реализованы на единой платформе CloudGate. В CloudGate мы тоже использовали некоторое количество open source компонентов: GoBGP – для обращения контрольной информации, а также VPP – для реализации программного роутера, работающего поверх DPDK для data path.
Tungsten Fabric общается с CloudGate через GoBGP. Рассказывает, что происходит в оверлейной сети. CloudGate, в свою очередь, связывает оверлейные сети друг с другом и с интернетом.
Теперь давайте посмотрим, как виртуальная сеть решает задачи масштабирования и доступности. Рассмотрим простой случай. Вот есть одна зона доступности и в ней созданы две VPC. Мы развернули один инстанс Tungsten Fabric, и он тянет в себе несколько десятков тысяч сетей. Сети связываются с CloudGate. CloudGate, как мы уже говорили, обеспечивает их связанность между собой и с интернетом.
Допустим, добавляется вторая зона доступности. Она должна выходить из строя совершенно независимо от первой. Поэтому во второй зоне доступности мы должны поставить отдельный инстанс Tungsten Fabric. Это будет отдельная система, которая занимается оверлеем и мало что знает о первой системе. А видимость, что наша виртуальная сеть глобальна, собственно, и создаёт наш VPC API. Это его задача.
VPC1 проецируется в зону доступности B, если в зоне доступности B есть ресурсы, которые втыкаются в VPC1. Если ресурсов из VPC2 в зоне доступности B нет, VPC2 в этой зоне мы не материализуем. В свою очередь, поскольку ресурсы из VPC3 существуют только в зоне B, VPC3 нет в зоне A. Всё просто и логично.
Давайте пойдём немного глубже и посмотрим, как устроен конкретный хост в Я.Облаке. Главное, что хочется отметить, – все хосты устроены одинаково. Мы делаем так, что только необходимый минимум сервисов крутится на «железе», все остальные работают на виртуальных машинах. Мы строим сервисы более высокого порядка на основе базовых инфраструктурных сервисов, а также используем Облако для решения некоторых инженерных задач, например, в рамках Continuous Integration.
Если мы посмотрим на конкретный хост, мы увидим, что в ОС хоста крутятся три компонента:
- Compute – часть, отвечающая за распределение вычислительных ресурсов на хосте.
- VRouter – часть Tungsten Fabric, которая организует оверлей, то есть туннелирует пакеты через андерлей (underlay).
- VDisk – это куски виртуализации хранилища.
Кроме этого в виртуальных машинах запущены сервисы: инфраструктурные сервисы Облака, платформенные сервисы и мощности заказчиков. Мощности заказчиков и платформенные сервисы всегда ходят в оверлей через VRouter.
Инфраструктурные сервисы могут втыкаться в оверлей, но в основном хотят работать именно в андерлее. В андерлей они втыкаются с помощью SR-IOV. Фактически мы режем карту на виртуальные сетевые карточки (виртуальные функции) и просовываем их в инфраструктурные виртуалки, чтобы не терять производительность. Например, тот самый CloudGate запущен в виде одной из таких инфраструктурных виртуальных машин.
Теперь, когда мы описали глобальные задачи виртуальной сети и устройство базовых компонентов облака, давайте посмотрим, как именно разные части виртуальной сети взаимодействуют друг с другом.
Мы выделяем в нашей системе три слоя:
- Config Plane – задает целевое состояние системы. Это то, что конфигурирует пользователь через API.
- Control Plane – обеспечивает заданную пользователем семантику, то есть доводит состояние Data Plane до того, что было описано пользователем в Config Plane.
- Data Plane – непосредственно обрабатывает пакеты пользователя.
Как я уже говорил выше, все начинается с того, что пользователь или внутренний платформенный сервис приходит в API и описывает определенное целевое состояние.
Это состояние сразу записывается в Yandex Database, возвращает через API ID асинхронной операции и запускает нашу внутреннюю машинерию, чтобы выдать состояние, которое хотел пользователь. Конфигурационные таски идут в SDN-контроллер и рассказывают Tungsten Fabric, что нужно сделать в оверлее. Например, они резервируют порты, виртуальные сети и тому подобное.
Config Plane в Tungsten Fabric отгружает в Control Plane требуемое состояние. Через него же Config Plane общается с хостами, рассказывая, что именно на них будет крутиться в скором времени.
Теперь посмотрим, как выглядит система на хостах. В виртуальной машине есть некий сетевой адаптер, воткнутый в VRouter. VRouter – это ядерный модуль Tungsten Fabric, который смотрит на пакеты. Если для некоторого пакета уже есть flow, модуль его обрабатывает. Если flow нет, модуль делает так называемый punting, то есть посылает пакет в юзермод-процесс. Процесс разбирает пакет и либо отвечает на него сам, как, например, на DHCP и DNS, либо говорит VRouter, что с ним делать. После этого VRouter может обрабатывать пакет.
Дальше трафик между виртуальными машинами в пределах одной виртуальной сети ходит прозрачно, он не направляется на CloudGate. Хосты, на которых развернуты виртуальные машины, общаются друг с другом напрямую. Туннелируют трафик и прокидывают его друг для друга через андерлей.
Control Plane общаются друг с другом между зонами доступности по BGP, как с другим роутером. Они рассказывают, какие машины где подняты, чтобы виртуальные машины в одной зоне могли напрямую взаимодействовать с другими виртуальными машинами.
А ещё Control Plane общается с CloudGate. Аналогично сообщает, где и какие виртуалки подняты, какие у них адреса. Это позволяет направлять на них внешний трафик и трафик от балансировщиков.
Трафик, который выходит из VPC, приходит на CloudGate, в data path, где быстро пережевывается VPP с нашими плагинами. Дальше трафик выстреливается либо в другие VPC, либо наружу, в пограничные маршрутизаторы, которые настраиваются через Control Plane самого CloudGate.
Планы на ближайшее будущее
Если обобщить все сказанное выше в нескольких предложениях, можно сказать, что VPC в Яндекс.Облаке решает две важные задачи:
- Обеспечивает изоляцию между разными клиентами.
- Объединяет ресурсы, инфраструктуру, платформенные сервисы, другие облака и on-premise в единую сеть.
А чтобы решать эти задачи хорошо, нужно обеспечивать масштабируемость и отказоустойчивость на уровне внутренней архитектуры, что VPC и делает.
Постепенно VPC обрастает функциями, мы реализуем новые возможности, стараемся улучшать что-то в плане удобства для пользователей. Некоторые идеи озвучиваются и попадают в лист приоритетов благодаря участниками нашего сообщества.
Сейчас у нас примерно такой список планов на ближайшее будущее:
- VPN как сервис.
- Private DNS инстансы – образы для быстрой настройки виртуальных машин с заранее сконфигурированным DNS-сервером.
- DNS как сервис.
- Внутренний балансировщик нагрузки.
- Добавление «белого» IP-адреса без пересоздания виртуальной машины.
Балансировщик и возможность переключать IP-адрес для уже созданной виртуалки оказались в этом перечне по запросу пользователей. Скажу честно, без явной обратной связи мы взялись бы за эти функции несколько позже. А так мы уже работаем над задачей про адреса.
Изначально «белый» IP-адрес можно было добавить только при создании машины. Если пользователь забывал это сделать, виртуальную машину приходилось пересоздавать. То же самое и при необходимости убрать внешний IP. Скоро можно будет включить и выключить публичный IP, не пересоздавая машину.
Не стесняйтесь высказывать свои идеи и поддерживать предложения других пользователей. Вы помогаете нам делать Облако лучше и быстрее получаете важные и полезные функции!
На этой странице можно узнать, как управлять доступом к ресурсам, и как IAM проверяет права доступа к ним.
Как проверяются права доступа?
Все операции в Яндекс.Облаке предварительно отправляются на проверку в IAM, например:
- Пользователь просит сервис Compute Cloud создать новый диск в каталоге
default
. - Сервис спрашивает IAM, можно ли этому пользователю создать диск в этом каталоге.
- IAM проверяет, что пользователь — участник облака с каталогом
default
и имеет необходимые разрешения для создания диска в этом каталоге. - Если какого-то из разрешений у пользователя нет, операция не будет выполнена, и Яндекс.Облако сообщит об ошибке.
Если все разрешения имеются, то IAM сообщает об этом сервису. - Сервис создает новый диск.
Как вы управляете доступом?
Управление доступом в Яндекс.Облаке построено на политике Role Based Access Control (RBAC). Чтобы предоставить доступ к ресурсу, вы указываете, кому и какие роли назначены на ресурс.
Чтобы назначить роль, вы выбираете ресурс, выбираете роль и описываете субъект, которому назначается роль. Таким образом вы привязываете права доступа к ресурсу.
Вы также можете назначить роль на родительский ресурс, от которого наследуются права доступа, например назначить роль на каталог или облако.
Важно
Изменение прав доступа обычно занимает до 5 секунд. Если после назначения роли все еще нет доступа, попробуйте выполнить операцию еще раз.
Например, вам разрешили создавать каталоги в облаке и вы уже создали один каталог, но не смогли создать второй. Это произошло потому, что еще не обновились права доступа на том сервере, где выполнялась вторая операция по созданию каталога. Попробуйте создать каталог еще раз.
Ресурсы, на которые можно назначать роли
Сейчас вы можете назначать роли на облако, каталог и другие ресурсы из списка.
Если вам необходимо предоставить доступ к ресурсу, которого нет в списке, например к виртуальной машине, назначьте роль на родительский ресурс, от которого наследуются права доступа. У виртуальных машин права доступа наследуются от каталога.
Роль
Назначать роли на ресурс могут пользователи с ролью администратора на этот ресурс, а также владельцы облака, которому принадлежит ресурс.
Каждая роль состоит из набора разрешений, описывающих допустимые операции с ресурсом. Пользователь может назначить роли только с теми разрешениями, которые имеются у него самого. Например, чтобы назначить роль владельца облака, пользователь должен сам обладать этой ролью, а роли администратора для этого недостаточно.
О том, какие есть роли и какие разрешения в них входят, читайте в разделе Роли.
Субъект, которому назначается роль
Роли назначаются субъектам. Есть четыре типа субъектов:
userAccount— аккаунт на Яндексе, добавленный в Яндекс.Облако.serviceAccount— сервисный аккаунт, созданный в Яндекс.Облаке.Сервисному аккаунту можно назначать роли только на ресурсы облака, которому принадлежит сервисный аккаунт.
federatedUser— аккаунт пользователя из федерации удостоверений, например из Active Directory.Федеративному пользователю можно назначать роли только на ресурсы облака, которому принадлежит федерация.
system— системная группа.
Привязка прав доступа
Роли на ресурс назначаются в виде списка связей роль-субъект. Такие связи называются — привязки прав доступа (access bindings). Вы можете добавлять и удалять эти связи, таким образом контролируя права доступа к ресурсу.
Одна привязка — одно назначение роли субъекту. Чтобы назначить пользователю несколько ролей на ресурс, задайте отдельную привязку для каждой из ролей.
Наследование прав доступа
Если у ресурса есть дочерние ресурсы, то все разрешения от родительского ресурса будут унаследованы дочерними ресурсами. Например, если вы назначите пользователю роль на каталог, в котором лежит виртуальная машина, то все разрешения этой роли будут действовать и для виртуальной машины.
Если на дочерний ресурс тоже назначены роли, то список разрешений на этот ресурс будет объединен со списком разрешений на родительский ресурс. Нельзя ограничить список разрешений, унаследованных от родительского ресурса.
Ограничения управления доступом в консоли управления
В консоли управления назначение ролей работает с ограничениями:
- Невозможно назначить роли системной группе.
- Пользователям с аккаунтом на Яндексе и федеративным аккаунтом можно назначать роли только на облако или каталог.
- Сервисному аккаунту можно назначить роль только на каталог, в котором он был создан.
- Вы не можете назначить роли сразу нескольким субъектам, как в API или CLI. В консоли управления вы сначала выбираете субъект (пользователя или сервисный аккаунт), а затем назначаете ему роли.
См. также
Вы можете найти подробную информацию об управлении доступом для конкретного сервиса Яндекс.Облака в разделе Управление доступом
в документации соответствующего сервиса.
Пошаговые инструкции и примеры:
Авторизация в Яндекс.Облаке | Яндекс.Облако
Когда пользователь выполняет операцию с ресурсом Яндекс.Облака, IAM проверяет, обладает ли пользователь необходимыми разрешениями для этой операции.
Разрешения пользователи получают вместе с ролями на ресурсы. Подробнее о том, как назначаются роли и проверяется список разрешений, читайте в разделе Как устроено управление доступом в Яндекс.Облаке.
Аутентификация в Яндекс.Облаке
Перед авторизацией, пользователь должен аутентифицироваться — войти под своим аккаунтом. Аутентификация происходит по-разному в зависимости от типа аккаунта и используемого интерфейса:
Аутентификация с аккаунтом на Яндексе
Консоль управления
CLI
API
Аутентификация происходит автоматически, когда вы входите в аккаунт Яндекса или Яндекс.Коннекта.
Чтобы выполнять операции в CLI, аутентифицируйтесь по инструкции. После этого аутентификация будет происходить автоматически.
Внимание
Если вы владелец облака и работаете через API со своего аккаунта, помните — владелец облака может выполнять любые операции с ресурсами в облаке.
Рекомендуем выполнять операции от имени сервисного аккаунта, которому вы можете назначить только необходимые для работы роли.
Чтобы выполнять операции в API:
Получите IAM-токен в обмен на OAuth-токен.
Полученный IAM-токен указывайте при обращении к ресурсам Яндекс.Облака через API. Передайте IAM-токен в заголовке
Authorizationв следующем формате:Authorization: Bearer <IAM-TOKEN>Время жизни IAM-токена — не больше 12 часов, но рекомендуется запрашивать его чаще, например каждый час.
Аутентификация сервисного аккаунта
Чтобы выполнять операции в CLI, аутентифицируйтесь по инструкции. После этого аутентификация будет происходить автоматически.
Есть 3 способа выполнять операции от имени сервисного аккаунта:
Аутентификация федеративного пользователя
Консоль управления
CLI
Чтобы войти в консоль управления, федеративный пользователь должен пройти по ссылке, в которой содержится идентификатор федерации:
https://console.cloud.yandex.ru/federations/<ID федерации>
То, как выглядит процесс аутентификации для федеративного пользователя — зависит от настроек сервера IdP. Подробнее читайте в разделе SAML-совместимые федерации удостоверений.
Чтобы выполнять операции в CLI, аутентифицируйтесь по инструкции.
После успешной аутентификации на сервере федерации в профиле сохранится IAM-токен. При каждой операции аутентификация будет происходить с помощью этого токена, пока не истечет время жизни токена. После этого CLI снова выведет сообщение о необходимости пройти аутентификацию в браузере.
См. также
Аккаунты в Яндекс.Облаке
Как начать работать с Yandex Object Storage | Яндекс.Облако
Сервис Yandex Object Storage — это универсальное масштабируемое решение для хранения данных. Оно подходит как для высоконагруженных сервисов, которым требуется надежный и быстрый доступ к данным, так и для проектов с невысокими требованиями к инфраструктуре хранения.
В терминах Object Storage файлы и папки — это объекты. Все объекты размещаются в бакетах. Структура хранения объектов в бакете плоская, но инструменты с графическим интерфейсом предлагают работать с Object Storage как с иерархической файловой системой.
API Object Storage частично совместим с API AWS S3 и вы можете использовать инструменты, предназначенные для работы с S3.
В этом разделе вы научитесь:
- Создавать бакеты, в которых вы будете хранить данные.
- Загружать файлы в бакеты.
- Получать ссылки скачивание на файла.
Перед началом работы
- Перейдите в консоль управления, затем войдите в Яндекс.Облако или зарегистрируйтесь, если вы еще не зарегистрированы.
- На странице биллинга убедитесь, что у вас подключен платежный аккаунт и он находится в статусе
ACTIVEилиTRIAL_ACTIVE. Если платежного аккаунта нет, создайте его. - На странице Управление доступом убедитесь, что у вас есть роль
editorили выше. Роль должна быть назначена на каталог, в котором вы будете работать, или на облако, которому принадлежит этот каталог.
Создание первого бакета
Чтобы создать первый бакет в Object Storage:
В консоли управления выберите каталог, в котором хотите создать бакет.
Нажмите кнопку Создать ресурс и выберите Бакет.
Введите имя бакета.
Имя бакета должно быть уникальным для всего Object Storage. Это имя используется как часть URL для доступа к данным и его будут видеть ваши пользователи.
При необходимости ограничьте максимальный размер бакета.
Чтобы загруженные файлы всегда были доступны извне Яндекс.Облака, выберите публичный тип доступа. Иначе для доступа к таким файлам необходимо будет создавать временную ссылку.
Выберите класс хранилища, который будет использоваться по умолчанию при загрузке объектов:
- Стандартное хранилище предназначено для активной работы с объектами.
- Холодное хранилище предназначено для длительного хранения объектов с редкими запросами на чтение.
Нажмите кнопку Создать бакет для завершения операции.
Загрузка файлов в бакет
Чтобы загрузить объект в бакет:
- В консоли управления выберите каталог.
- Выберите сервис Object Storage.
- Нажмите на имя необходимого бакета.
- Чтобы загрузить объекты в бакет, перетащите файлы на экран с бакетом или нажмите кнопку Загрузить.
Получение ссылки на скачивание файла
Чтобы получить ссылку на загруженный объект:
- В консоли управления выберите каталог.
- Выберите сервис Object Storage.
- Нажмите на имя необходимого бакета.
- Нажмите на имя объекта.
- Нажмите кнопку Получить ссылку.
- Если у вас бакет с ограниченным доступом:
- В открывшемся окне укажите Время жизни ссылки в часах или днях. Максимальное время жизни ссылки — 7 дней.
- Нажмите кнопку Получить ссылку.
- Скопируйте полученную ссылку.
Полученной ссылкой вы можете поделиться или использовать ее в своем сервисе для доступа к файлу.
Операции с бакетами и объектами вы можете выполнять не только в консоли управления Яндекс.Облака, но и с помощью других инструментов.
90000 How access management in Yandex.Cloud works | Yandex.Cloud 90001 90002 Here you can learn how to manage access to your resources and how IAM checks access rights for the resources. 90003 90004 How are access rights verified? 90005 90002 All operations in Yandex.Cloud are first sent for verification to IAM. For example: 90003 90008 90009 A user requests Yandex Compute Cloud to create a new disk in the 90010 default 90011 folder. 90012 90009 The service sends a request to IAM to check whether this user is allowed to create disks in this folder.90012 90009 IAM checks if the user is a member of the cloud with the 90010 default 90011 folder and has the necessary permissions to create a disk in this folder. 90012 90009 If the user does not have any of the permissions, the operation is not performed and Yandex.Cloud returns an error. 90020 If all the required permissions were granted, IAM reports this to the service. 90012 90009 The service creates a new disk. 90012 90024 90002 90026 90003 90004 How do I perform access management? 90005 90002 Access management in Yandex.Cloud leverages the Role Based Access Control (RBAC) policy. To grant users access to a resource, you specify which roles are assigned to them for that resource. 90003 90002 To assign a role, select a resource, choose a role, and describe the subject assigned to the role. This lets you bind access rights to the resource. 90003 90002 You can also assign a role to a parent resource that access rights are inherited from, such as a folder or cloud. 90003 90002 90037 Warning 90038 90003 90002 It usually takes 5 seconds or less to update access rights.If the role was assigned to you, but still you do not have access, try repeating the operation. 90003 90002 For example, you were given the right to create folders in the cloud and you were able to create one folder, but could not create another one. This is because the access rights have not yet been updated on the server where the second create folder operation was performed. Try creating the folder again. 90003 90044 Resources that roles can be assigned for 90045 90002 You can currently assign roles for a cloud, folder, and other resources from the list.90003 90002 If you need to grant access to a resource that is not on the list (such as a VM), assign the role to the parent resource it inherits permissions from. VM permissions are inherited from their folder. 90003 90044 Role 90045 90002 Resource roles can be assigned by users with the administrator role for the resource, as well as the owners of the cloud that the resource belongs to. 90003 90002 Each role consists of a set of permissions that describe operations that can be performed with the resource.A user can assign a role with only those permissions which are available to themselves. For example, only the user with the cloud owner role can assign this same role. The administrator role is not enough for this. 90003 90002 To find out what roles exist and the permissions they include, see Roles. 90003 90044 Subjects that roles are assigned to 90045 90002 Roles are assigned to subjects. There are four types of subjects: 90003 90062 90009 90002 90065 userAccount 90066: A Yandex account added to Yandex.Cloud. 90003 90012 90009 90002 90065 serviceAccount 90066: A service account created in Yandex.Cloud. 90003 90002 A service account can only be assigned roles for the resources of the cloud that the service account belongs to. 90003 90012 90009 90002 90065 federatedUser 90066: A user account from an identity federation, like Active Directory. 90003 90002 A federated user can only be assigned roles for the resources of the cloud that the federation belongs to. 90003 90012 90009 90002 90065 system 90066: A system group.90003 90012 90091 90044 Assign access rights 90045 90002 Roles to a resource are assigned as a list of 90095 role-subject 90096 bindings. They are called 90095 access bindings 90096. You can add or remove these bindings to control access rights to a resource. 90003 90002 90101 90003 90002 Each binding is a single assignment of a role to a subject. To assign a user multiple roles to a resource, set a separate binding for each role. 90003 90044 Inheritance of access rights 90045 90002 If a resource has child resources, all permissions from the parent resource will be inherited by the child resources.For example, if you assign a user a role for a folder where a VM instance resides, all permissions of this role will also apply to the instance. 90003 90002 If a child resource is also assigned some roles, a list of permissions for this resource will be combined with a list of permissions for its parent resource. You can not limit the list of permissions inherited from the parent resource. 90003 90044 Access control restrictions in the management console 90045 90002 Some restrictions apply to assigning roles in the management console: 90003 90062 90009 You can not assign roles to a system group.90012 90009 You can only assign cloud and folder roles to users with a Yandex account and federated account. 90012 90009 You can only assign a role for the folder where the service account was created. 90012 90009 You can not assign roles to multiple subjects at once, unlike in the API or CLI. In the management console, you should first select the subject (user or service account), and then assign roles to it. 90012 90091 90125 See also 90126 90002 For more information about managing access to a specific Yandex.Cloud service, see the 90010 Access management 90011 section in the documentation on that service. 90003 90002 Step-by-step instructions and examples: 90003 .90000 How to use Yandex.Cloud securely | Yandex.Cloud 90001 90002 This section provides recommendations for using IAM features to ensure the secure operation of Yandex.Cloud services. 90003 90004 Do not grant unnecessary access rights 90005 90002 For critical resources: 90003 90008 90009 90002 Assign the minimum required roles. For example, to allow the creation of virtual machines from images in Compute Cloud, assign the 90011 compute.images.user 90012 role instead of the 90011 editor 90012 role or higher.90003 90016 90009 90002 Try to assign service roles rather than primitive roles (90011 viewer 90012, 90011 editor 90012, 90011 admin 90012). Primitive roles apply to resources in any Yandex.Cloud service. 90003 90002 Use primitive roles if you do not have an applicable service role or if you want to grant a user total access. 90003 90016 90009 90002 Assign only the roles you need at the moment. Do not assign roles that might only be needed in the future. 90003 90016 90009 90002 Keep in mind that when you assign a role for a folder or cloud, the permissions under this role inherit all the nested resources.90003 90016 90009 90002 Only assign the administrator role or cloud owner role to the people responsible for managing resource access in your project. 90003 90002 Administrators can revoke one another’s access rights, while owners can revoke the owner role from one another. These roles also include all the permissions under the 90011 editor 90012 role — they let you create, edit, and delete resources. 90003 90016 90045 90004 Protect your Yandex account 90005 90008 90009 90002 To better safeguard your resources from unauthorized access, we recommend enabling two-factor authentication in Yandex.Passport. Use this method to secure your own account and ask every user you add to your cloud to enable two-factor authentication as well. 90003 90016 90009 90002 Keep your OAuth token a secret, since it can be used to get an IAM token and perform operations in the cloud on your behalf. 90003 90002 If someone might have discovered your OAuth token, invalidate it and issue a new one. 90003 90016 90009 90002 Avoid using your OAuth token for authentication if you can use an IAM token. OAuth tokens are valid for 1 year while IAM tokens are valid for 12 hours.If your token is compromised, the hacker has limited time to use it. 90003 90016 90045 90004 Use service accounts 90005 90002 Use service accounts to automate work with Yandex.Cloud. We recommend doing the following: 90003 90008 90009 90002 Control access to your service accounts. The 90011 editor 90012 role for a service account lets the user perform operations permitted under the service account. If the service account has the administrator role for the cloud, the user can use it to make themselves an administrator.90003 90016 90009 90002 Create separate service accounts for different tasks. This way you can only assign them the roles you actually need. You can revoke roles from a service account or delete it without affecting other service accounts. 90003 90016 90009 90002 Name your service accounts according to their intended purposes and permissions. 90003 90016 90009 90002 Keep your service account keys a secret — they can be used to perform operations on behalf of your service accounts.Do not keep the service account keys in the source code. 90003 90002 Periodically revoke old keys and issue new ones. Be sure to do this if you think someone discovered your secret key. 90003 90016 90009 90002 Do not use your keys for authentication if you can use IAM tokens. Keys have an unlimited lifetime, while IAM tokens are valid for 12 hours. 90003 90016 90009 90002 If you perform operations from inside a VM, link a service account to it. In this case, you do not need to store service account keys on the VM to enable authentication: the IAM token is available from a metadata service link.90003 90016 90045 .90000 Getting started with IAM | Yandex.Cloud 90001 90002 IAM lets you manage access to resources. 90003 90002 These instructions are intended for cloud owners and administrators. You will learn how to: 90003 90006 Before you start 90007 90008 90009 Log in to the management console. If you are not registered, go to the management console and follow the instructions. 90010 90009 On the billing page, make sure you linked a billing account and it has the 90012 ACTIVE 90013 or 90012 TRIAL_ACTIVE 90013 status.If you do not have a billing account, create one. 90010 90009 If you have no one to add to the cloud, you can create a new account on Yandex and grant access to the cloud to this account. 90010 90019 90006 Add a new user to the cloud 90007 90002 To grant a user access to resources, add the user to your cloud: 90003 90008 90009 90002 Open the Access management page for the selected cloud. If necessary, switch to another cloud. 90003 90010 90009 On the 90030 Users and roles 90031 page, click the 90030 Add user 90031 button in the upper-right corner.90010 90009 Enter the user’s Yandex email address. 90010 90009 Click 90030 Add 90031. 90010 90019 90002 When a new user is added to the cloud, they are automatically assigned the cloud member role: 90012 resource-manager.clouds.member 90013. This role is necessary for the user to access resources in the cloud. However, this role does not give you the right to perform any operations and is only used in combination with other roles, such as 90012 admin 90013, 90012 editor 90013, or 90012 viewer 90013.90003 90006 Assign roles to the user 90007 90002 To specify which operations the user can perform, assign relevant roles to the user. For example, allow them to manage resources in a certain folder: 90003 90008 90009 90002 Select the user to assign the role to, click 90059, and choose 90030 Configure roles 90031. 90003 90010 90009 Under 90030 Roles for the cloud 90031, click the 90067 icon. 90010 90009 Choose the 90012 viewer 90013 role. This role lets the user view resources in your cloud.90010 90009 Select a folder in 90030 Roles in folders 90031 and click 90030 Assign role 90031. 90010 90009 Choose the 90012 editor 90013 role. This role allows the user to create and manage resources in this folder. 90010 90009 Click 90030 Close 90031. 90010 90019 90006 Revoke assigned roles 90007 90002 If the user no longer needs the assigned roles, revoke them: 90003 90008 90009 90002 Open the page Access management. 90003 90010 90009 90002 Select the user to assign the role to, click 90059, and choose 90030 Configure roles 90031.90003 90010 90009 90002 Click the 90106 icon next to each role you want to revoke. 90003 90010 90009 90002 Click 90030 Close 90031. 90003 90002 If the user does not have any more roles for your cloud, this user disappears from the list. 90003 90010 90019 90002 90030 Tip 90031 90003 90002 If you want to revoke all roles at once, delete the user from your cloud. 90003 90006 What’s next 90007 .90000 Authorization in Yandex.Cloud | Yandex.Cloud 90001 90002 When a user does something with a resource in Yandex.Cloud, IAM checks whether the user has the necessary access rights to perform this operation. 90003 90002 Users get permissions along with resource roles. For more information about how roles are assigned and how the list of permissions is checked, see How access management in Yandex.Cloud works. 90003 90006 Authentication in Yandex.Cloud 90007 90002 Before authorization, a user must get authenticated, meaning they must log in under their account.Authentication is performed in different ways, depending on the type of account and the interface used: 90003 90010 Authentication using a Yandex account 90011 90002 Management console 90003 90002 CLI 90003 90002 API 90003 90002 Authentication is carried out automatically when you log in to your Yandex or Yandex.Connect account. 90003 90002 To perform operations in the CLI, authenticate following the instructions. After this, authentication will work automatically. 90003 90002 90023 Alert 90024 90003 90002 If you are the owner of the cloud and you use your own account to access the API, remember that the owner of the cloud can perform any operations with cloud resources.90003 90002 We recommend using a service account to work with the API. This way, you can assign only the roles that are necessary. 90003 90002 To perform operations in the API: 90003 90032 90033 90002 Get an IAM token in exchange for your OAuth token. 90003 90036 90033 90002 Specify the received IAM token when accessing Yandex.Cloud resources via the API. Pass the IAM token in the 90039 Authorization 90040 header in the following format: 90003 90042 90039 Authorization: Bearer
Ваш комментарий будет первым