Блог

В настоящее время я настраиваю среду Kubeflow в Azure с помощью AKS. Все настроено и работает (пользователи могут входить в платформу kubeflow, используя учетные данные Azure AZ, и запускать модули блокнота в своем собственном пространстве имен). Я предполагаю, что эти учетные данные AD встроены где-то в процессе создания контейнера, и мне интересно, можно ли использовать эти учетные данные для других сервисов, интегрированных с AD?

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

Пользователь работает в записной книжке Jupyter, запущенной с платформы Kubeflow. Пользователь хочет получить доступ к данным в большом двоичном объекте хранилища Azure. Вместо того, чтобы входить в Azure из сеанса notebook, в контейнере уже хранятся их учетные данные.

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

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

Способ работы OIDC заключается в возврате токена с заданной аудиторией (с кем он должен использоваться) и грантов (что, по его словам, вы должны уметь делать). Токен, который выдается Kubeflow, действителен только для основной аудитории службы Kubeflow; другими словами, вы не можете использовать тот же токен и использовать его с API Azure. Это сделано специально и является одним из ключевых факторов безопасности OIDC. Предоставление Kubeflow разрешений на выдачу большего количества токенов (обычно с помощью разрешения user_impersonation) создает довольно серьезную проблему безопасности — теперь любой, кому удастся скомпрометировать этот секрет приложения, может получить мощные токены вместо токенов ограниченной области, как обычно.

Если ресурсы, к которым они должны получить доступ, не относятся к конкретным пользователям, о которых идет речь, aad-pod-identity можно использовать для предоставления токена доступа к модулям, которые запускают пользователи, вместо того, чтобы требовать от них повторного входа в систему.