Какие из перечисленных функций базовой подсистемы ввода-вывода можно делегировать водителям
Обновлено: 21.11.2024
Когда вы запускаете автоматизацию, по умолчанию автоматизация запускается в контексте пользователя AWS Identity and Access Management (IAM), который инициировал автоматизацию. Это означает, например, что если ваша учетная запись пользователя IAM имеет права администратора, то автоматизация запускается с правами администратора и полным доступом к ресурсам, настраиваемым автоматизацией. Из соображений безопасности мы рекомендуем запускать автоматизацию с помощью сервисной роли IAM (также называемой предполагаемой ролью), которая настроена с помощью управляемой политики AmazonSSMAutomationRole. Использование роли службы IAM для запуска автоматизации называется делегированным администрированием.
При использовании сервисной роли автоматизация может работать с ресурсами AWS, но пользователь, запустивший автоматизацию, имеет ограниченный доступ (или не имеет доступа) к этим ресурсам. Например, вы можете настроить роль службы и использовать ее с функцией автоматизации для перезапуска одного или нескольких экземпляров Amazon Elastic Compute Cloud (Amazon EC2). Автоматизация — это возможность AWS Systems Manager. Автоматизация перезапускает экземпляры, но роль службы не дает пользователю разрешения на доступ к этим экземплярам.
Вы можете указать роль службы во время выполнения при запуске автоматизации или создать настраиваемые модули Runbook и указать роль службы непосредственно в модуле Runbook. Если вы указываете роль службы либо во время выполнения, либо в модуле Runbook, служба запускается в контексте указанной роли службы. Если вы не укажете роль службы, система создаст временный сеанс в контексте пользователя и запустит автоматизацию.
Вы должны указать роль службы для автоматизации, которая, по вашему мнению, будет работать дольше 12 часов. Если вы запускаете длительную автоматизацию в контексте пользователя, срок действия временного сеанса пользователя истекает через 12 часов.
Делегированное администрирование обеспечивает повышенную безопасность и контроль над вашими ресурсами AWS. Это также обеспечивает расширенные возможности аудита, поскольку действия с вашими ресурсами выполняются центральной ролью службы, а не несколькими учетными записями IAM.
Чтобы правильно проиллюстрировать, как делегированное администрирование может работать в организации, в этом разделе описаны следующие задачи, как если бы эти задачи выполнялись тремя разными людьми в организации:
Создайте тестовую учетную запись пользователя IAM с именем AutomationRestrictedOperator (администратор).
Создайте роль службы IAM для автоматизации (администратор).
Создайте простой модуль Runbook (на основе существующего модуля Runbook), в котором указана роль службы (автор Runbook).
Запустите автоматизацию в качестве тестового пользователя (оператора с ограниченными правами).
В некоторых организациях все три задачи выполняет один и тот же человек, но определение разных ролей показывает, как делегированное администрирование позволяет повысить безопасность в сложных организациях.
В целях безопасности мы рекомендуем всегда использовать роль службы для запуска автоматизации, даже если вы являетесь администратором, выполняющим все эти задачи.
Процедуры в этом разделе связаны с темами в других руководствах по AWS или в других темах по Systems Manager. Мы рекомендуем открывать ссылки на другие темы в новой вкладке веб-браузера, чтобы не потерять свое место в этой теме.
Темы
Создайте тестовую учетную запись пользователя
В этом разделе описывается, как создать тестовую учетную запись пользователя IAM с ограниченными разрешениями. Набор разрешений позволяет пользователю запускать автоматизацию, но у пользователя нет доступа к ресурсам AWS, на которые нацелена автоматизация. Оператор также может просматривать результаты автоматизации. Вы начинаете с создания пользовательской политики разрешений IAM, а затем создаете учетную запись пользователя и назначаете ей разрешения.
Создайте тестового пользователя IAM
Создайте политику разрешений с именем OperatorRestrictedPermissions. Сведения о том, как создать новую политику разрешений IAM, см. в разделе Создание политики IAM (консоль) в Руководстве пользователя IAM. Создайте политику на вкладке JSON и укажите следующий набор разрешений.
Создайте новую учетную запись пользователя IAM с именем AutomationRestrictedOperator. Сведения о том, как создать нового пользователя IAM, см. в разделе Создание пользователей IAM (консоль) в Руководстве пользователя IAM. При появлении запроса выберите Прикрепить существующие политики напрямую и выберите только что созданную политику.
Запишите имя пользователя, пароль и ссылку для входа в консоль. Вы войдете в эту учетную запись позже в этом разделе.
Создание роли службы IAM для автоматизации
Следующая процедура связана с другими темами, которые помогут вам создать роль службы и настроить автоматизацию так, чтобы она доверяла этой роли.
Чтобы создать роль службы и разрешить автоматизации доверять ей
Создайте роль службы автоматизации. Дополнительные сведения см. в разделе Задача 1. Создание роли службы для автоматизации.
Обратите внимание на роль службы Amazon Resource Name (ARN).Вы укажете этот ARN в следующей процедуре.
Создание пользовательского модуля Runbook
В этом разделе описывается, как создать пользовательский модуль Runbook, который перезапускает экземпляры EC2. AWS предоставляет модуль Runbook для перезапуска инстансов под названием AWS-RestartEC2Instance. Следующая процедура копирует содержимое этого модуля Runbook, чтобы показать вам, как ввести роль службы в модуль Runbook при создании собственного. Указав роль службы непосредственно в модуле Runbook, пользователю не требуются разрешения iam:PassRole при использовании модуля Runbook. Без разрешений iam:PassRole пользователь не может использовать роль службы где-либо еще в AWS.
Чтобы создать пользовательский модуль Runbook
На панели навигации выберите Документы.
Если сначала открывается домашняя страница AWS Systems Manager, выберите значок меню ( ), чтобы открыть панель навигации, а затем выберите «Документы» в панели навигации.
Выберите Создать документ.
В поле Имя введите имя модуля Runbook, например Restart-EC2InstanceDemo.
В списке Тип документа выберите Документ автоматизации.
В разделе "Содержимое" выберите JSON, а затем вставьте следующее содержимое. Замените AssumeRoleARN на ARN роли службы, созданной в предыдущей процедуре.
Выберите Создать документ.
Запустите пользовательский модуль Runbook
Следующая процедура описывает, как запустить только что созданный модуль Runbook с использованием ограниченной роли оператора, которую вы создали ранее в этом разделе. Пользователь может запускать модуль Runbook, созданный ранее, поскольку разрешения его учетной записи IAM позволяют ему просматривать и запускать модуль Runbook. Однако пользователь не может войти в экземпляры, которые вы перезапустите с помощью этой автоматизации.
Выйдите из Консоли управления AWS, а затем войдите снова, используя ссылку для входа в Консоль тестовой учетной записи пользователя, которую вы скопировали ранее.
На панели навигации выберите Автоматизация.
Если сначала открывается домашняя страница AWS Systems Manager, выберите значок меню ( ), чтобы открыть панель навигации, а затем выберите «Автоматизация».
Выберите «Выполнить автоматизацию».
Выберите пользовательский модуль Runbook, созданный ранее в этом разделе.
В разделе "Сведения о документе" убедитесь, что для версии документа установлено значение 1 (по умолчанию).
Нажмите «Далее».
В разделе "Режим выполнения" выберите "Простое выполнение".
В разделе "Входные параметры" введите один или несколько идентификаторов экземпляров, которые вы хотите перезапустить, а затем выберите "Выполнить".
Сведения о выполнении описывают состояние автоматизации. Шаг 1 останавливает экземпляры. Шаг 2 запускает экземпляры.
Спасибо, что сообщили нам, что мы делаем хорошую работу!
Если у вас есть минутка, расскажите, что мы сделали правильно, чтобы мы могли сделать больше.
Спасибо, что сообщили нам, что эта страница нуждается в доработке. Сожалеем, что подвели вас.
Если у вас есть минутка, расскажите нам, как мы можем улучшить документацию.
Аппаратные ресурсы — это назначаемые адресуемые пути шины, которые позволяют периферийным устройствам и системным процессорам взаимодействовать друг с другом. Аппаратные ресурсы обычно включают адреса портов ввода-вывода, векторы прерываний и блоки адресов памяти, относящихся к шине.
Прежде чем система сможет обмениваться данными с экземпляром устройства, диспетчер PnP должен назначить аппаратные ресурсы экземпляру устройства, зная, какие ресурсы доступны и какие из них может использовать экземпляр устройства. Ресурсы назначаются каждому узлу устройства в дереве устройств (при условии, что представленному устройству нужны ресурсы и эти ресурсы доступны). Диспетчер PnP отслеживает аппаратные ресурсы с помощью списков, которые он связывает с узлами устройств. Он использует два типа списков:
Список требований к ресурсам
Устройства обычно предназначены для работы в пределах диапазонов назначенных ресурсов. Например, устройству может потребоваться только один вектор прерывания, но оно может использовать любой из диапазона векторов. Для каждого экземпляра устройства диспетчер PnP поддерживает список требований к ресурсам, в котором указаны все диапазоны аппаратных ресурсов, в которых может работать устройство. Название списка связано с тем, что PnP-менеджер должен выбирать ресурсы из этого списка при их назначении устройству.
Код режима ядра задает списки требований к ресурсам с помощью структур IO_RESOURCE_REQUIREMENTS_LIST (либо в качестве входных данных для системных процедур, либо в ответ на IRP). Код пользовательского режима задает списки требований к ресурсам, используя структуры диспетчера конфигурации PnP в качестве входных данных для функций диспетчера конфигурации PnP.
Список ресурсов
Когда диспетчер PnP назначает ресурсы устройству, он отслеживает эти назначения, создавая список назначенных ресурсов для каждого экземпляра устройства. Эти списки можно было бы назвать списками назначения ресурсов, но это имя обычно сокращается до списки ресурсов.Диспетчер PnP может изменять содержимое списка ресурсов по мере того, как устройства добавляются в систему или удаляются из нее, а ресурсы впоследствии перераспределяются. (Ресурсы также могут назначаться с помощью PnP BIOS. Кроме того, установочное программное обеспечение — с использованием INF-файлов или пользовательского ввода — может заставить диспетчер PnP назначать определенные ресурсы устройству.)
Код режима ядра задает списки ресурсов с помощью структур CM_RESOURCE_LIST (либо в качестве входных данных для системных процедур, либо в ответ на IRP). Код пользовательского режима задает списки ресурсов, используя структуры диспетчера конфигурации PnP в качестве входных данных для функций диспетчера конфигурации PnP.
Диспетчер PnP сохраняет списки требований к ресурсам и списки ресурсов в реестре, где их можно просмотреть с помощью Regedit.exe. Драйверы могут получить доступ к этим спискам косвенно через процедуры Plug and Play и второстепенные IRP Plug and Play. Приложения пользовательского режима могут использовать функции диспетчера конфигурации PnP. (Драйверы и приложения не должны напрямую обращаться к этим спискам с помощью функций реестра, поскольку формат хранения может измениться в будущих версиях.)
Логические конфигурации
Как списки требований к ресурсам, так и списки ресурсов содержат одну или несколько логических конфигураций. Каждая логическая конфигурация определяет либо диапазон допустимых ресурсов, либо набор определенных ресурсов для конкретного экземпляра устройства. Кроме того, каждая логическая конфигурация экземпляра устройства принадлежит к одному из типов логической конфигурации. Типы конфигурации перечислены ниже. Каждому экземпляру устройства может быть назначено несколько логических конфигураций одного или разных типов.
Типы логической конфигурации для списков требований к ресурсам
Базовая конфигурация
Список требований к ресурсам, определяющий диапазоны ресурсов, предоставляемые устройством Plug and Play. Драйвер должен возвращать этот список при получении IRP_MN_QUERY_RESOURCE_REQUIREMENTS IRP. (Базовая конфигурация устройства, не поддерживающего PnP, может быть описана в файле INF. В этом случае программа установки устройства считывает файл INF и вызывает функции диспетчера конфигурации PnP для создания списка требований.)
Отфильтрованная конфигурация
Список требований к ресурсам, который был предоставлен стеку драйверов, возможно изменен, а затем возвращен стеком драйверов в ответ на IRP_MN_FILTER_RESOURCE_REQUIREMENTS. Диспетчер PnP использует полученную отфильтрованную конфигурацию в качестве основы для распределения ресурсов.
Переопределить конфигурацию
Список требований к ресурсам, который переопределяет базовые конфигурации. Как правило, установщик устройства создает переопределяющую конфигурацию, если файл INF устройства содержит раздел INF DDInstall.LogConfigOverride. Конфигурация переопределения не удаляется, если ее устройство физически удаляется из системы.
Типы логической конфигурации для списков ресурсов
Конфигурация загрузки
Список ресурсов, определяющий ресурсы, назначенные экземпляру устройства при загрузке системы. (Для устройств PnP это конфигурация, предоставляемая BIOS; для устройств, не поддерживающих PnP, эти ресурсы могут быть выбраны перемычками на плате.) Драйвер должен возвращать этот список ресурсов, когда он получает IRP_MN_QUERY_RESOURCES. (Конфигурация загрузки может быть частично пустой, если BIOS не может определить все ресурсы, используемые устройством.) Диспетчер PnP может изменить этот список, если устройство удалено или перезапущено. Для не-PnP-устройств этот тип конфигурации можно использовать вместо принудительной конфигурации, и в этом случае он имеет более низкий приоритет конфигурации, чем эквивалентная принудительная конфигурация. Для каждого экземпляра устройства может существовать только одна загрузочная конфигурация.
Принудительная конфигурация
Список ресурсов, определяющий ресурсы, которые должен использовать экземпляр устройства. Принудительная конфигурация не позволяет диспетчеру PnP назначать экземпляру устройства другие ресурсы. Установщик устройства может создать принудительную конфигурацию на основе информации, содержащейся в INF-файле или полученной от пользователя. Принудительная конфигурация не удаляется, если ее устройство физически удалено из системы. Для каждого экземпляра устройства может существовать только одна принудительная конфигурация.
Выделенная конфигурация
Список ресурсов, определяющий ресурсы, которые в настоящее время используются экземпляром устройства. Для каждого экземпляра устройства может существовать только одна выделенная конфигурация.
Драйверы устройств отвечают за определение базовой конфигурации PnP-совместимого устройства, отфильтрованной конфигурации и конфигурации загрузки, а также за возврат этой информации в ответ на запросы IRP, отправляемые диспетчером PnP. (Дополнительную информацию см. в разделе Добавление устройства PnP в работающую систему.) Программное обеспечение для установки драйвера может создавать переопределяющие конфигурации, принудительные конфигурации и, для устройств, не поддерживающих PnP, загрузочные конфигурации. Диспетчер PnP поддерживает выделенную конфигурацию каждого экземпляра устройства.
Приоритет назначается каждой конфигурации при ее создании.Если диспетчер PnP обнаруживает, что экземпляру устройства назначено несколько логических конфигураций одного типа, он сначала пытается использовать ту, которая имеет наивысший приоритет. Если эта конфигурация приводит к конфликтам ресурсов, она пытается использовать конфигурацию со следующим более низким приоритетом. (Список приоритетов конфигурации см. в CM_Add_Empty_Log_Conf.)
В большинстве операционных систем есть способ отображения загрузки ЦП. В Windows это диспетчер задач.
Загрузка ЦП обычно представляет собой простой процент времени ЦП, затраченного на задачи, не связанные с бездействием. Но это небольшое упрощение. В любой современной операционной системе ЦП на самом деле проводит время в двух очень разных режимах:
В режиме ядра исполняемый код имеет полный и неограниченный доступ к базовому оборудованию. Он может выполнять любую инструкцию ЦП и ссылаться на любой адрес памяти. Режим ядра обычно зарезервирован для наиболее надежных функций операционной системы самого низкого уровня. Сбои в режиме ядра катастрофичны; они остановят весь ПК.
В пользовательском режиме исполняемый код не имеет возможности напрямую обращаться к оборудованию или эталонной памяти. Код, работающий в пользовательском режиме, должен делегировать системным API доступ к оборудованию или памяти. Благодаря защите, обеспечиваемой такой изоляцией, сбои в пользовательском режиме всегда можно восстановить. Большая часть кода, запущенного на вашем компьютере, будет выполняться в пользовательском режиме.
Можно включить отображение времени ядра в диспетчере задач, как показано на снимке экрана выше. Зеленая линия — это общее время процессора; красная линия — время ядра. Разрыв между ними – время пользователя.
Эти два режима не просто ярлыки. они применяются аппаратным обеспечением ЦП. Если код, выполняющийся в пользовательском режиме, пытается сделать что-то, выходящее за рамки его компетенции, например, получить доступ к привилегированной инструкции ЦП или изменить память, к которой у него нет доступа, возникает перехватываемое исключение. Вместо сбоя всей вашей системы происходит сбой только этого конкретного приложения. В этом ценность пользовательского режима.
Оборудование ЦП x86 фактически обеспечивает четыре кольца защиты: 0, 1, 2 и 3. Обычно используются только кольца 0 (ядро) и 3 (пользователь).
Если мы используем только два изолирующих кольца, немного неясно, куда должны идти драйверы устройств — код, который позволяет нам использовать наши видеокарты, клавиатуры, мыши, принтеры и т. д. Эти драйверы работают в режиме ядра для максимальной производительности или они работают в пользовательском режиме для максимальной стабильности? В Windows, по крайней мере, ответ это зависит. Драйверы устройств могут работать как в режиме пользователя, так и в режиме ядра. В наши дни большинство драйверов отодвинуты на сторону пользователя, за заметным исключением драйверов видеокарт, которым требуется производительность в режиме ядра. Но даже это меняется; в Windows Vista видеодрайверы разделены на разделы User и Kernel. Возможно, именно поэтому геймеры жалуются, что Vista в играх работает примерно на 10 процентов медленнее.
Точная граница между этими режимами до сих пор неясна. Какой код должен выполняться в пользовательском режиме? Какой код должен работать в режиме ядра? Или, может быть, мы просто переопределим этаж как подвал — рост виртуализации привел к созданию нового кольца ниже всех остальных, кольца -1, которое мы теперь знаем как аппаратную виртуализацию x86.
Пользовательский режим — это чистое общественное благо, но за него приходится платить. Переход между пользовательским режимом и режимом ядра стоит дорого. Действительно дорого. Вот почему, например, программное обеспечение, выдающее исключения, работает медленно. Исключения подразумевают переходы режима ядра. Конечно, сейчас у нас так много производительности, что нам редко приходится заботиться о производительности перехода, но когда вам нужна максимальная производительность, вы определенно начинаете заботиться об этом.
Вероятно, самый публичный пример перерисовки линии пользователя/ядра — это веб-серверы. IIS 6 от Microsoft переместил значительную часть своих основных функций в режим ядра, особенно после того, как конкретный веб-сервер с открытым исходным кодом использовал режим ядра, чтобы добиться огромной победы в отраслевых тестах. Если вы спросите меня, это была своего рода бессмысленная война, поскольку оптимизации ядра (в обоих лагерях) применимы только к статическому содержимому HTML. Но таков путь всех войн, эталонных или иных.
Строгое разделение кода ЦП между пользовательским и ядерным режимами совершенно прозрачно для большинства из нас, но в буквальном смысле это разница между компьютером, который постоянно выходит из строя, и компьютером, который все время катастрофически выходит из строя. Это то, что мы, программисты, пишущие особо аварийный код, любим называть прогрессом.Итак, от имени всех программистов во всем мире я хотел бы сказать спасибо пользовательскому режиму. Ты молодец!
Читайте также: