Авторизация rbac возвращает сообщение доступ запрещен для пользователя

Обновлено: 11.05.2024

Авторизация - это процесс проверки того, что у пользователя достаточно разрешения на выполнение каких-либо действий. Yii предоставляет два метода авторизации: Фильтр управления доступом (ACF) и Контроль доступа на основе ролей (RBAC).

Фильтр контроля доступа

Фильтр контроля доступа (ACF) - это простой метод авторизации, реализованный в виде yii\filters\AccessControl , который лучше всего использовать для приложений, которым требуется только простой контроль доступа. Как видно из его названия, ACF - это фильтр действий, который можно использовать в контроллере или модуле. Пока пользователь запрашивает выполнение действия, ACF проверит список правил доступа, чтобы определить, разрешен ли пользователю доступ к запрошенному действию.

В приведенном ниже коде показано, как использовать ACF в контроллере site:

В коде выше ACF привязан к контроллеру site как к поведению. Это типичный способ использования фильтра действий. Опция only указывает, что ACF следует применять только к действиям login, logout и signup. Все остальные действия в контроллере site не подлежат контролю доступа. Опция rules содержит правила доступа, которые выглядят следующим образом:

ACF выполняет проверку авторизации, просматривая правила доступа по одному сверху донизу, пока не найдет правило, соответствующее текущему контексту выполнения. Значение allow правила сопоставления затем будет использоваться для определения того, разрешен пользователь или нет. Если ни одно из правил не соответствует, это значит, что пользователь НЕ авторизован, и ACF прекратит выполнение дальнейших действий.

Когда ACF определяет, что пользователь не авторизован для доступа к текущему действию, по умолчанию он принимает следующую меру:

Вы можете настроить это поведение, настроив свойство yii\filters\AccessControl::$denyCallback следующим образом:

Правила доступа поддерживают множество опций. Ниже приведено краткое описание поддерживаемых параметров. Вы также можете расширить yii\filters\AccessRule, чтобы создать свои собственные классы правил доступа.

Ниже приведен пример, показывающий, как использовать параметр matchCallback, который позволяет вам писать произвольную логику проверки доступа:

Управление доступом на основе ролей (RBAC)

Управление доступом на основе ролей (RBAC) обеспечивает простой, но мощный централизованный контроль доступа. Yii реализует общий иерархический RBAC, следуя модели NIST RBAC. Он обеспечивает функциональность RBAC с помощью компонента приложения authManager. Использование RBAC включает в себя две части работы. Первая часть - это создание данных авторизации RBAC, а вторая часть - использование данных авторизации для выполнения проверки доступа в тех местах, где это необходимо. Чтобы облегчить наше описание, мы сначала представим некоторые базовые концепции RBAC.

Базовые концепты

Обе роли и разрешения могут быть организованы в иерархии. В частности, роль может состоять из других ролей или разрешений; И разрешение может состоять из других разрешений. Yii реализует иерархию частичного порядка, которая включает более специальную иерархию дерева. Хотя роль может содержать разрешение, это не так.

Настройка RBAC

Прежде чем мы начнем определять данные авторизации и выполнить проверку доступа, нам необходимо настроить компонент приложения authManager. Yii предоставляет два типа менеджеров авторизации: yii\rbac\PhpManager и yii\rbac\DbManager . Первый использует файл сценария PHP для хранения данных авторизации, а второй хранит данные авторизации в базе данных. Вы можете использовать первый, если ваше приложение не требует очень динамической роли и управления разрешениями.

Использование PhpManager

В следующем коде показано, как настроить authManager в конфигурации приложения с помощью класса yii\rbac\PhpManager :

Теперь к authManager можно получить доступ через \Yii::$app->authManager .

По умолчанию yii\rbac\PhpManager сохраняет данные RBAC в файлах в каталоге @app/rbac . Убедитесь, что каталог и все файлы в нем доступны для записи процессом веб-сервера, если иерархия разрешений должна быть изменена онлайн.

Использование DbManager

В следующем коде показано, как настроить authManager в конфигурации приложения с помощью класса yii\rbac\DbManager :

DbManager использует четыре таблицы базы данных для хранения своих данных:

Прежде чем вы сможете продолжить, вам нужно создать эти таблицы в базе данных. Для этого вы можете использовать миграцию, хранящуюся в @yii/rbac/migrations :

Теперь к authManager можно получить доступ через \Yii::$app->authManager .

Данные авторизации здания

Данные авторизации здания сводятся к следующим задачам:

• Определение ролей и разрешений;
• Установление отношений между ролями и разрешениями;
• Определение правил;
• Сопоставление правил с ролями и разрешениями;
• Назначение ролей пользователям.

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

Если ваша иерархия разрешений вообще не изменяется, и у вас есть фиксированное число пользователей, вы можете создать консольную команду, которая будет инициализировать данные авторизации один раз через API, предлагаемые authManager:

Для приложений, которым требуется сложное управление доступом с динамически обновляемыми данными авторизации, возможно, потребуется разработать специальные пользовательские интерфейсы (например, панель администратора) с использованием API, предлагаемых authManager.

Использование правил

Вышеуказанное правило проверяет, создан ли post в $user . Мы создадим специальное разрешение updateOwnPost в команде, которую мы использовали ранее:

Проверка доступа

Когда данные авторизации готовы, проверка доступа так же просто, как вызов метода yii\rbac\ManagerInterface::checkAccess() . Поскольку большая часть проверки доступа относится к текущему пользователю, для удобства Yii предоставляет метод ярлыка yii\web\User::can() , который можно использовать следующим образом:

Внутри вашего контроллера есть несколько способов реализации авторизации. Если вам нужны подробные разрешения, разделяющие доступ к добавлению и удалению, вам нужно проверить доступ для каждого действия. Вы можете использовать указанное выше условие в каждом методе действия или использовать yii\filters\AccessControl :

Если все операции CRUD управляются совместно, рекомендуется использовать одно разрешение, например managePost , и проверить его в yii\web\Controller::beforeAction() .

Использование ролей по умолчанию

Роль по умолчанию - это роль, которая неявно назначается всем пользователям. Вызов yii\rbac\ManagerInterface::assign() не требуется, и данные авторизации не содержат информацию о назначении.

Роль по умолчанию обычно связана с правилом, которое определяет, относится ли роль к проверяемому пользователю.

Роли по умолчанию часто используются в приложениях, у которых уже есть своего рода назначение ролей. Например, приложение может иметь столбец "groups" в своей таблице пользователей, чтобы представлять группу привилегий, к которой принадлежит каждый пользователь. Если каждая группа привилегий может быть сопоставлена ​​роли RBAC, вы можете использовать функцию роли по умолчанию, чтобы автоматически назначить каждого пользователя роли RBAC. Давайте использовать пример, чтобы показать, как это можно сделать.

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

Затем настройте authManager, указав две роли в yii\rbac\BaseManager::$defaultRoles :

Теперь, если вы выполняете проверку доступа, обе роли admin и author будут проверены, оценив связанные с ними правила. Если правило возвращает true, это означает, что роль применима к текущему пользователю. На основе реализации вышеприведенного правила это означает, что если значение group пользователя равно 1, роль admin будет применяться к пользователю; И если значение group равно 2, будет применена роль author.

С помощью файла манифеста я успешно развернул kubeflow в своем кластере. Вот что я сделал.

Вот проверка шагов 3 и 4. Проверьте, включен ли RBAC и добавлен envoyfilter для kubeflow-userid.

После того, как я закончил развертывание. Я выполнил ниже функциональное тестирование:

• Я могу войти в свою учетную запись google с помощью google oauth
• Мне удалось создать свой собственный профиль / пространство имен
• Мне удалось создать ноутбук-сервер
• Однако я НЕ могу подключиться к серверу ноутбука.

RBAC расследование проблемы

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

С учетом того, что конфигурация envoy, которая использовалась для проверки авторизации RBAC authz, взята из этой конфигурации. И он распространяется микшером в sidecar. Журнал и код приводят меня к конфигу rbac.istio.io для servicerolebinding.

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

Я обнаружил, что есть istio-galley validatingAdmissionConfiguration (блок кода ниже), который отслеживает эти ресурсы istio rbac.

Я ломаю голову над этой проблемой istio более 2 недель. Я уверен, что есть множество людей, которые валят то же самое, пытаясь расстрелять istio на k8s. Любые предложения приветствуются! Вот как я понимаю проблему, поправьте меня, если я ошибаюсь:

• Свидетельство журнала показало, что правила rbac не разрешают мне доступ к ресурсу.
• Мне нужно обновить правила rbac
• правила распространяются микшером в контейнер envoy в соответствии с ServiceRoleBinding
• Поэтому мне нужно вместо этого обновить ServiceRoleBinding
• Я не могу обновить ServiceRoleBinding, потому что либо веб-перехватчик проверки допуска, либо микшер istio не позволяют мне это сделать

Я столкнулся с проблемами ниже, где

Я не могу обновить ServiceRoleBinding даже после удаления проверяющего веб-перехватчика

Я попытался удалить этот проверяющий веб-перехватчик, чтобы обновить привязку сервера. Ресурс возобновляется сразу после того, как я сохраню правку. Проверяющий веб-перехватчик фактически создается автоматически из карты конфигурации, поэтому мне пришлось обновить его, чтобы обновить веб-перехватчик.

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

Я не могу найти ни одного соответствующего журнала, который указывает, что ресурс rbac.istio.io защищен / проверяется какой-либо службой в пространстве имен istio-system.

Как получить журнал СМЕСИТЕЛЯ

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

Самое главное Как отладить контейнер посланника

Мне нужно отладить приложение посланника, чтобы понять, почему оно возвращает false для функции разрешения. Если мы не можем легко отладить его. Есть ли документ, который позволяет мне обновить код, чтобы добавить больше журнала и создать новое изображение в GCR, чтобы я мог выполнить еще один запуск и на основе журнала посмотреть, что происходит за сценой.

Прим. перев.: Продолжая недавно затронутую нами тему безопасности Kubernetes в целом и RBAC — в частности, публикуем перевод этого материала от французского консультанта из международной компании Big Data-компании Adaltas. Автор в деталях показывает, как создавать пользователей, наделять их правами и в дальнейшем обслуживать.

Настройка и запуск кластера Kubernetes – это только начало: ведь его необходимо еще и эксплуатировать. Чтобы обезопасить доступ к кластеру, нужно задать идентификационные данные пользователей и грамотно управлять настройками аутентификации и авторизации.

(Иллюстрация взята из блога CNCF — прим. перев.)

Эта статья посвящена тому, как создавать пользователей, используя клиентские сертификаты X.509, и как управлять авторизацией с помощью базовых API-объектов RBAC в Kubernetes. Мы также поговорим о некоторых открытых проектах, упрощающих администрирование кластера: rakkess, kubectl-who-can, rbac-lookup и RBAC Manager.

Предварительные условия и допущения

Прежде всего необходимо сделать несколько допущений:

• Вы хотя бы примерно представляете, как работает Kubernetes.
• У вас имеется работающий кластер Kubernetes или Minikube.
• У вас установлена CLI-утилита kubectl.
• У вас установлен пакет OpenSSL.

В нашем кластере 4 узла: один мастер и 3 рабочих. Мастер также будет использоваться в качестве пограничного узла для взаимодействия с кластером.

API-объекты RBAC

Управление доступом на основе ролей (RBAC) — это метод регулирования доступа к компьютерам и сетевым ресурсам, опирающийся на роли отдельных пользователей в компании. RBAC можно использовать со всеми ресурсами Kubernetes, которые поддерживают CRUD (Create, Read, Update, Delete). Примеры таких ресурсов:

• пространства имен;
• Pod'ы;
• Deployment'ы;
• постоянные тома (PersistentVolumes);
• ConfigMap'ы.

• create (создание);
• get (получение);
• delete (удаление);
• list (просмотр списка);
• update (обновление).

• Role и ClusterRole . Это просто наборы правил, представляющие набор разрешений. Role может использоваться только для предоставления доступа к ресурсам внутри пространств имен. ClusterRole может предоставлять те же разрешения, что и Role , а также давать доступ к ресурсам, доступных в пределах всего кластера, и так называемым нересурсным endpoint'ам (вроде /healthz — прим. перев.).
• Subjects . Subject (субъект) — это сущность, которая будет выполнять операции в кластере. Ей могут являться пользователи, сервисы или даже группы.
• RoleBinding и ClusterRoleBinding . Как следует из названия, это просто привязка субъекта к Role или ClusterRole.

• view : доступ только для чтения, исключает секреты;
• edit : перечисленное выше + возможность редактировать большинство ресурсов, исключает роли и привязки ролей;
• admin : перечисленное выше + возможность управлять ролями и привязками ролей на уровне пространств имен;
• cluster-admin : все возможные привилегии.

Пример использования

Мы создадим два пространства имен: my-project-dev и my-project-prod , — а также двух пользователей: jean и sarah — с различными ролями в этих пространствах имен:

• my-project-dev:
  
  • jean: edit
  • jean: view
  • sarah: edit

  Создание и аутентификация пользователей с помощью клиентских сертификатов X.509

  Как правило, имеется два типа пользователей: учетные записи служб (service accounts), управляемые Kubernetes, и обычные пользователи. Мы сфокусируемся на последних. Вот как они описываются в официальной документации:

  Предполагается, что обычными пользователями управляет внешняя, независимая служба. В ее роли может выступать администратор, распределяющий закрытые ключи, хранилище пользователей вроде Keystone или Google Accounts, или даже файл со списком имен пользователей и паролей. В связи с этим в Kubernetes нет объектов, представляющих обычных пользователей. Обычных пользователей нельзя добавить в кластер через вызов API.

  Существует несколько способов управления обычными пользователями:

  • Базовая аутентификация (basic auth):
    • передача конфигурации API-серверу со следующим (или похожим) содержимым: password, username, uid, group;
    • создание секретного ключа пользователя и запроса на подпись сертификата;
    • заверение его в центре сертификации (Kubernetes CA) для получения сертификата пользователя;
    • OpenID Connect;
    • слой аутентификации поверх OAuth 2.0;
    • веб-хуки (webhooks).
    Создайте пользователя на мастере, а затем перейдите в его домашнюю директорию для выполнения остальных шагов:

    
    Теперь нужно скопировать приведенный выше конфиг в каталог .kube :

    Теперь у нас есть пользователи, и можно переходить к созданию двух пространств имен:

    
    Поскольку мы пока не определили авторизацию пользователей, у них не должно быть доступа к ресурсам кластера:

    Создание Role и ClusterRole

    
    Чтобы их создать, выполните команду:

    Привязка Role или ClusterRole к пользователям

    Теперь привяжем ClusterRole по умолчанию ( edit и view ) к нашим пользователям следующим образом:

    • jean :
      • edit — в пространстве имен my-project-dev ;
      • view — в пространстве имен my-project-prod ;
      • edit — в пространстве имен my-project-prod .

      
      Мы разрешаем jean просматривать ( view ) my-project-prod и редактировать ( edit ) my-project-dev . То же самое необходимо сделать с авторизациями для sarah . Для их активации выполните команду:

      
      В данном случае была использована kubectl apply вместо kubectl create . Разница между ними в том, что create создает объект и больше ничего не делает, а apply — не только создает объект (в случае, если его не существует), но и обновляет при необходимости.

      Давайте проверим, получили ли наши пользователи нужные разрешения.

      • Пользователь: sarah ( edit в my-project-prod )
        • my-project-prod
          • может выводить список pod'ов (1);
          • может создавать deployment'ы (2).
          • не может выводить список pod'ов (4);
          • не может создавать deployment'ы (5).
          • Пользователь: jean ( view в my-project-prod и edit в my-project-dev )
            • my-project-prod
              • может выводить список pod'ов (1);
              • может выводить список deployment'ов (2);
              • не может удалять deployment'ы (3).
              • может выводить список pod'ов (4);
              • может создавать deployment'ы (5);
              • может выводить список deployment'ов (6);
              • может удалять deployment'ы (7).

              Управление пользователями и их авторизацией

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

              Нам необходимы ответы на все эти вопросы, чтобы обеспечить безопасность кластера. Команда kubectl auth can-i позволяет выяснить, может ли пользователь выполнить определенное действие:

              Это практически все, что можно сделать с помощью встроенного инструментария. Именно поэтому представлю и некоторые Open Source-проекты, позволяющие расширить возможности, предлагаемые командой kubectl auth can-i. Прежде чем представить их, установим зависимости: Go и Krew.

              Установка Go

              Go — язык программирования с открытым исходным кодом, позволяющий создавать простое, надежное и эффективное программное обеспечение. Он был разработан компанией Google под вдохновением от Си и Pascal, на основе оригинальной концепции Robert Griesemer, Rob Pike и Ken Thompson.

              Установка Krew

              Krew — это инструмент, упрощающий использование плагинов kubectl. Krew помогает находить нужные плагины, устанавливать и управлять ими. По функциям он напоминает такие инструменты, как apt, dnf или brew. Krew совместим только с kubectl версии 1.12 и выше.

              rakkess

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

              
              Документацию по проекту можно найти в репозитории на GitHub. Вот пример его работы:

              
              
              

              kubect-who-can

              
              Документация — в GitHub-репозитории. Пример работы:

              rbac-lookup

              
              Документация — в GitHub-репозитории. Вот пример работы:

              RBAC Manager

              Как очевидно следует из названия этого проекта, он является менеджером RBAC. Он упрощает множество необходимых манипуляций. Пожалуй, самым важным является создание RoleBinding'ов. Ранее мы видели, что при создании различных ролей для пользователя необходимо создавать различные RoleBinding'и. RBAC Manager помогает, позволяя сделать всего один RoleBinding сразу со всей авторизацией. Для установки необходимо загрузить YAML-файл из репозитория на GitHub:

              
              Официальная документация — в GitHub-репозитории. Пример работы:

              Заключение

              Мы создали пользователей в кластере Kubernetes с помощью клиентского сертификата X.509 с OpenSSL и наделили их полномочиями. Для более простого создания пользователей вы можете воспользоваться скриптом, доступном в моем репозитории на GitHub (или экспериментальными командами kubeadm — прим. перев.). Что касается администрирования кластера, можно воспользоваться Open Source-проектами, представленными в статье:

              В этой статье содержатся ответы на часто задаваемые вопросы об управлении доступом на основе ролей в Azure (Azure RBAC). Вы узнаете, какие ситуации возможны при использовании ролей, а также сможете устранить неполадки, связанные с доступом.

              Ограничение для назначения ролей Azure

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

              • Добавьте пользователей в группы и назначьте роли группам, а не отдельным пользователям.
              • Объедините несколько встроенных ролей в одну настраиваемую роль.
              • Назначайте часто используемые роли для большей области охвата, например для подписки или группы управления.
              • Если у вас Azure AD Premium P2, сделайте назначения ролей доступными в Azure AD Privileged Identity Management вместо их постоянного назначения.
              • Создайте еще одну подписку.

              Чтобы узнать число назначений ролей, можно просмотреть диаграмму на странице управления доступом (IAM) на портале Azure. Вы также можете воспользоваться такими командами Azure PowerShell:

              Ограничение назначений ролей Azure для групп управления

              Azure поддерживает до 500 назначений ролей для каждой группы управления. Это ограничение отличается от ограничения назначений ролей на подписку.

              Ограничение назначений ролей 500 для каждой группы управления фиксировано и не может быть увеличено.

              Проблемы с назначениями ролей в Azure

              Если не удается назначить роль в портал Azure управления доступом (IAM) , так как параметр добавления назначения роли отключен или возникла ошибка разрешения "у клиента с идентификатором объекта нет авторизации на выполнение действия", убедитесь, что вы вошли в систему с помощью пользователя, которому назначена роль с таким разрешением, как владелец или администратор доступа пользователей в области попытка назначения роли.

              Если для назначения ролей используется субъект-служба, может возникнуть ошибка "недостаточно прав для выполнения операции". Например, предположим, что у вас есть субъект-служба, которому назначена роль владельца, и вы пытаетесь создать следующее назначение роли в качестве субъекта-службы с помощью Azure CLI:

              Второй способ устранить эту ошибку — создать назначение роли с помощью параметра --assignee-object-id , а не --assignee . При использовании --assignee-object-id Azure CLI пропустит поиск в AAD. Вам потребуется указать идентификатор объекта для пользователя, группы или приложения, которому нужно назначить роль. Подробнее см. в статье Назначение ролей Azure с помощью Azure CLI.

              Если вы создадите новый субъект-службу и сразу же попытаетесь назначить роль этому субъекту-службе, в некоторых случаях такое назначение роли может завершиться ошибкой.

              Вы можете удалить назначение роли последнего владельца (или администратора доступа пользователей) в области подписки, если вы являетесь глобальным администратором клиента. В этом случае ограничение на удаление отсутствует. Однако если вызов поступает от другого участника, вы не сможете удалить назначение роли последнего владельца в области действия подписки.

              Проблемы с пользовательскими ролями

              Настраиваемые роли и группы управления

              • В AssignableScopes настраиваемой роли можно определить только одну группу управления. В настоящее время добавление группы управления в AssignableScopes доступно в режиме предварительной версии.
              • Настраиваемые роли с DataActions нельзя назначить в области группы управления.
              • Azure Resource Manager не проверяет существование группы управления, указанной в назначаемой области определения роли.
              • Дополнительные сведения о настраиваемых ролях и группах управления см. в статье Организация ресурсов с помощью групп управления Azure.

              Перенос подписки в другой каталог

              • Если вам нужно перенести подписку в другой каталог AAD, см. статью Перенос подписки Azure в другой каталог Azure AD.
              • Когда вы переносите подписку в другой каталог AAD, все назначения ролей удаляются из исходного каталога AAD без возможности восстановления и не переносятся в целевой каталог AAD. Вам потребуется повторно создать назначения ролей в целевом каталоге. Также необходимо вручную заново создать управляемые удостоверения для ресурсов Azure. Дополнительные сведения см. в статье Часто задаваемые вопросы об управляемых удостоверениях для ресурсов Azure, а также известные проблемы в их работе.
              • Если вы глобальный администратор AAD и у вас нет доступа к подписке после ее переноса в другой каталог, используйте переключатель Управление доступом для ресурсов Azure, чтобы временно повысить уровень прав для получения доступа к подписке.

              Проблемы с администраторами или соадминистраторами служб

              • Если у вас возникли проблемы с администратором служб или соадминистраторами, см. статью Добавление или изменение администраторов подписки Azure и Роли классического администратора подписки, роли Azure и роли Azure AD.

              Отказ в доступе или ошибки разрешений

              Перемещение ресурсов с назначениями ролей

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

              Назначения ролей с ненайденным удостоверением

              В списке назначений ролей для портала Azure иногда можно заметить, что субъект безопасности (пользователь, группа, субъект-служба или управляемое удостоверение) указан с пометкой Удостоверение не найдено и типом Неизвестно.

              
              

              Удостоверение может быть не найдено по двум причинам:

              • вы недавно пригласили пользователя при создании назначения роли;
              • вы удалили субъект безопасности, у которого было назначение роли.

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

              Однако если этот субъект безопасности не является недавно приглашенным пользователем, возможно, он удален. Если назначить роль субъекту безопасности, а затем удалить его без предварительного удаления назначения роли, то субъект безопасности будет указан с пометкой Удостоверение не найдено и типом Неизвестно.

              если вы перечислите назначение ролей с помощью Azure PowerShell, может отобразиться пустое DisplayName значение и SignInName . Например, командлет Get-AzRoleAssignment возвращает назначение роли, похожее на следующие выходные данные:

              Аналогично если вы получите данные назначения роли с помощью Azure CLI, может отобразиться пустой параметр principalName . Например, команда az role assignment list возвращает назначение роли, похожее на следующие выходные данные:

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

              Изменения в назначениях ролей не обнаруживаются

              Azure Resource Manager иногда кэширует конфигурации и данные для повышения производительности. При назначении ролей или удалении назначений ролей может потребоваться до 30 минут, чтобы изменения вступили в силу. Если вы используете портал Azure, Azure PowerShell или Azure CLI, можно принудительно обновить изменения назначения ролей, выйдя из учетной записи и повторно войдя в нее. Если вы вносите изменения в назначения ролей с помощью вызовов REST API, можно принудительно обновить изменения, обновив маркер доступа.

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

              Компоненты веб-приложений, требующие доступа для записи

              Если предоставить пользователю доступ только для чтения к одному веб-приложению, некоторые компоненты могут неожиданно отключиться. Перечисленные ниже возможности управления требуют доступа к веб-приложению с правом записи (роль участника или владельца), поэтому они недоступны при наличии прав только на чтение.

              • Команды (такие как запуск, остановка и т. д.).
              • Изменение параметров, таких как общие параметры конфигурации, параметры масштабирования, резервного копирования и мониторинга.
              • Доступ к учетным данным для публикации и другим секретным сведениям, например к параметрам приложений и строкам подключения.
              • Журналы потоковой передачи.
              • Настройка журналов ресурсов
              • Консоль (командная строка).
              • Активные и недавние развертывания (для локального непрерывного развертывания Git).
              • Приблизительные затраты.
              • Веб-тесты
              • Виртуальная сеть (видна читателю только в том случае, если ранее была настроена пользователем с доступом на запись).

              Если у вас нет доступа ни к одной из этих плиток, попросите администратора предоставить вам доступ к веб-приложению с правами участника.

              Ресурсы веб-приложений, требующие доступа для записи

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

              
              

              В результате, если вы предоставите кому-либо доступ только к веб-приложению, многие функции в колонке веб-сайта на портале Azure будут отключены.

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

              • просмотр ценовой категории веб-приложения (например, "Бесплатный" или "Стандартный");
              • параметры масштабирования (число экземпляров, размер виртуальной машины, настройки автоматического масштабирования);
              • квоты (квоты хранилища, пропускной способности, ресурсов ЦП).

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

              • TLS/SSL-сертификаты и привязки (TLS/SSL-сертификаты могут совместно использоваться сайтами, относящимися к одной группе ресурсов и находящимися в одном географическом расположении);
              • Правила оповещения
              • параметры автоматического масштабирования;
              • компоненты Application Insights;
              • Веб-тесты

              Компоненты виртуальных машин, требующие доступа для записи

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

              Виртуальные машины связаны с доменными именами, виртуальными сетями, учетными записями хранения и правилами оповещений.

              Элементы, требующие доступа к виртуальной машине с правом записи:

              • Конечные точки
              • IP-адреса
              • Диски
              • Модули

              Элементы, требующие доступа на запись как к виртуальной машине, так и к группе ресурсов, в которой она находится (а также к доменному имени):

              • Группа доступности
              • набор балансировки нагрузки;
              • Правила оповещения

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

              Функции Azure и доступ для записи

              Для некоторых компонентов решения Функции Azure требуется доступ на запись. Например, если пользователю назначена роль Читатель, он не сможет просматривать функции в пределах приложения-функции. На портале отобразится текст (Нет доступа).

              
              

              Пользователь с ролью читателя может щелкнуть вкладку Функции платформы и выбрать Все параметры, чтобы просмотреть некоторые параметры, связанные с приложением-функцией (так же, как для веб-приложения), но не может изменить эти параметры. Для доступа к этим возможностям потребуется роль Участник.

              Читайте также:

                
              • Сообщение о явлении природы 1 класс
                
              • Сообщение на мониторе out of range
                
              • Сообщение о озерах волгоградской области
                
              • Кровь сообщение на английском
                
              • Сообщение на тему пдк почвы