В предыдущей статье при регистрации и управлении кластером многие детали аутентификации и проверки подлинности были пропущены. Эта часть концепции действительно довольно извилиста.
Для прямого примера, в auth туннеля в предыдущем разделе очень расплывчато указано, что агент сообщает о jwt, а владелец ранчо одобряет запрос через jwt на стороне сервера. Это аутентификация или аутентификация? Что кажется довольно приятным для слуха, не так ли? Другой пример: выполняет ли OAuth аутентификацию или авторизацию?
Во время интервью я познакомился со многими людьми, и все часто сообщали, что знали, что эти штуки наконец-то позволили пользователям получить доступ к бизнес-ресурсам через систему контроля разрешений. Некоторые одноклассники даже спрашивали меня: мы не Конг Иджи, какие слова ты вычитаешь? Все кончено, если вы можете использовать его.
С точки зрения использования это правда, но все-таки мы инженеры, поэтому здесь мы поговорим о двух-трех вещах об аутентификации и аутентификации более подробно.
В этой статье я не буду
- Опишите технические детали различных аутентификаций k8s и rancher, например, какая команда используется для создания kubeconfig, например, что означает каждое поле RBAC k8s
- Расскажите некоторые справочные данные, такие как SSL, jwt
Если вы хотите знать этиusage, вы можете перейти к официальной документации. В этой статье я буду
- Каковы значения различных существительных, с которыми мы сталкиваемся, и каковы их различия и связи?
- Представьте игровой процесс аутентификации и аутентификации k8s и rancher, а также преимущества и недостатки.
Так что, если быть точным, эта статья на самом деле не является вводной книгой, она предназначена для студентов, которые имеют определенное представление об authn & authz и заинтересованы в небольшом углубленном изучении.
0. Как мы учимся?
Сертификация и аутентификация - это полный набор системы знаний и методологии. Просто прочитать эту статью определенно недостаточно. Я предпочитаю записывать здесь, как мы должны понимать систему знаний аутентификации и аутентификации. Опираясь на свой опыт, я быУзнать новые точки знаний из толкования существительных и установить связи с имеющимися знаниями.
Например, аутентификация (аутентификация) Википедия написала:
Authentication is the act of proving an assertion, such as the identity of a computer system user. In contrast with identification, the act of indicating a person or thing's identity, authentication is the process of verifying that identity.
Сначала перевел на свои собственные знания: сертификация - доказать, что пользователь - это ход его заявления о идентичности. После прочтения на протяжении всеми мы представили какую-то новую терминологию: пользователь (пользователь), идентичность (идентичность), номер счета (аккаунт).
Википедия про авторизацию говорит:
Authorization is the function of specifying access rights/privileges to resources, which is related to general information security and computer security, and to access control in particular.
В переводе на понятные слова: аутентификация — это процесс проверки того, есть ли у вас разрешение на просмотр определенного ресурса. Поэтому мы ввели новые термины: авторизация, контроль доступа, RBAC и т. д.
Ища объяснения этих терминов и определяя их нюансы, мы можем шаг за шагом построить собственную систему знаний об аутентификации и аутентификации.
1. Начнем с основ
1.1 Я не Конг Иджи, но все же хочу рассказать вам о трех способах написания хуэйцзы.
Перечислите некоторые концепции, которые лично я считаю относительно базовыми и ключевыми.
| Ключевые слова | китайский язык | Парафраз |
|---|---|---|
| user | Пользователь | Ты, я и он перед экраном живые люди |
| identity | личность | Фрагмент данных, уникальный в текущем домене службы, описывающий уникального конечного пользователя. |
| account | учетная запись | Часть данных, хранящихся в системе, которая записываетПользователь |
| identity provider | поставщик удостоверений | Системный компонент, отвечающий за управление идентификацией, предоставляющий возможности аутентификации |
| authentication | Сертификация | это процесс доказательства того, что пользователь является тем, за кого себя выдает |
| token-based authentication | токен аутентификации | Метод аутентификации, при котором пользователь удерживает токен, доказывая, что личность пользователя соответствует заявленному токену. |
| credential | сертификат | Учетные данные, которыми пользователи активно владеют для подтверждения своей личности, например имя пользователя и пароль. |
| authorization | Аутентификация | Процесс проверки того, авторизован ли пользователь для выполнения операции в системе. |
Приведенное выше определение может быть непонятным для новичков, но его гораздо легче понять на примере из жизни.
Предположим, Сяо Мин берет свое удостоверение личности, чтобы сесть на высокоскоростную железную дорогу.
Сяо Мин — пользователь, а серверная система — это высокоскоростная железная дорога.Чего хочет Сяо Мин, так это сесть на определенный поезд на определенную станцию в определенное время.
Сяо Мин приложил свое удостоверение личности к воротам на контрольно-пропускном пункте, прошел через ворота с помощью распознавания лиц и вошел на станцию высокоскоростной железной дороги.
Личность Сяо Мина определяется его удостоверением личности, которое поддерживает уникальность его личности благодаря его идентификационному номеру. Национальный веб-сайт идентификационной информации является поставщиком идентификационной информации, который предоставляет идентификационную информацию высокоскоростным железным дорогам.
Когда Сяо Мин хочет пройти через ворота, он сначала держит удостоверение личности и заявляет, что моя личность соответствует Сяо Мину.Это удостоверение личности можно рассматривать как сертификат. Самое простое, система может распознавать только удостоверение личности Сяомина, думаю, чтоЛицо, владеющее этим удостоверением личности, — Сяо Мин.. Но очевидно, что если удостоверение личности Сяо Мина потеряно, что, если у преступников есть удостоверение личности Сяо Мина? Таким образом, процесс аутентификации здесь также включает в себя распознавание лиц.
ID-карты и распознавание лиц можно сравнить с токенами и паролями. Удостоверение личности похоже на жетон и представляет собой удостоверение личности Сяо Мина, которое будет использоваться государством, когда он станет взрослым. Лицо Сяо Мина — это своего рода биологический код, который рождается у Сяо Мина и вводится по его собственной инициативе, инициатива находится в руках Сяо Мина.
После того, как все прошло, Сяо Мин прошел системную сертификацию и подтвердил свою личность.
Прежде чем сесть в автобус, Сяо Мин положил свое удостоверение личности на турникет, прошел, прошел на платформу и плавно сел в автобус.
Ворота имеют как аутентификацию, так и аутентификацию (этапы аутентификации такие же, как и раньше, и аутентификация завершается с помощью удостоверения личности). Человек, проводящий картой у этих ворот, должен сесть на поезд XXX. Гейт проверил серверную систему.Поскольку Сяо Мин купил билет на 12306, гейт обнаружил запись о покупке билета учетной записи пользователя, соответствующей Сяо Мину, и посчитал, что эта учетная запись соответствуетличностьВы можете сесть на этот поезд и пройти аутентификацию.
Вот некоторые из четырех очень важных моментов:
- Существует однозначное соответствие между пользователями и идентичностями
- Каждая учетная запись соответствует уникальному идентификатору
- Аутентификация ориентирована на учетную запись, и ее личность должна быть подтверждена.
- Аутентификация ориентирована на личность, и необходимо доказать, что личность имеет достаточные полномочия.
Я не знаю, есть ли у вас более полное представление об аутентификации и аутентификации на этом примере? Если это так, в следующем разделе мы возьмем k8s в качестве примера, чтобы увидеть, как k8s выполняет аутентификацию и аутентификацию.
1.2 k8s authn & authz
Читатели могут обратиться к официальномуАутентификация пользователячасть. Весь документ можно резюмировать в следующих ключевых моментах:
- k8s не управляет пользователями, только управляет учетными записями служб
- k8s поддерживает аутентификацию с помощью открытых и закрытых ключей и токенов, а также прокси аутентификации
- k8s имеет довольно ограниченную поддержку OIDC (подробнее об этом позже)
- k8s поддерживает олицетворение
Справочник по разделу аутентификации
1.2.1 Что такое сервисный аккаунт
Учетную запись можно разделить на учетную запись пользователя и учетную запись службы, где учетная запись пользователя соответствует конечному пользователю, а учетная запись службы — это внутренняя учетная запись службы, которая не соответствует реальной личности. Например, в микрослужбах учетная запись службы может быть учетной записью экземпляра микрослужбы.
Учетная запись службы обычно управляется самим k8s, а логика управления компилируется в исходный код apiserver как своего рода контроллер допуска. видетьИспользование контроллера допуска.
Модуль может объявить об использовании сервисной учетной записи (не говоря уже о том, как k8s определяет, может ли модуль использовать эту сервисную учетную запись), и тогда запросы от модуля к apiserver будут рассматриваться apiserver как инициированные этой сервисной учетной записью. Неважно, работает ли это программа в модуле или кто-либо выполняет запрос в модуль, это одно и то же.
Как правило, учетная запись службы связана с секретом, который содержит общедоступный сертификат ЦС, пространство имен и токен:
- Сертификат CA: он используется сервером для проверки запроса.Поскольку мы обычно используем самозаверяющий сертификат для k8s, нам необходимо иметь «открытый ключ» при запросе. Эти знания, связанные с криптографией, выходят за рамки этой статьи. Заинтересованные студенты могут обратиться кProtocol Forest 17 Мое личное сообщение с вами (протокол SSL/TLS).
- токен: это стандартный jwt.
Я не буду упоминать jwt здесь, и незнакомые читатели могут просто использовать его как учетные данные для аутентификации. Мы можем увидеть содержимое токена через kubectl, не забудьте расшифровать base64, а затем мы можемJSON Web Tokens (JWT) онлайн-расшифровкаЭтот сайт рассматривает декодированный контент. Они относительно тривиальны, поэтому я не буду их здесь раскрывать.
1.2.2 Что такое олицетворение
Олицетворение звучит пугающе и всегда имеет хакерский оттенок. олицетворение позволяет пользователю A выполнять команды от имени пользователя B, добавляя определенные заголовки. Предварительным условием является наличие у пользователя А достаточных разрешений, чтобы выдавать себя за пользователя Б.
олицетворение обычно связано сДепозитный счеттесно связаны. Счет условного депонирования — это когда разные системы подключены, и система А имеет учетную запись управления с достаточными полномочиями в системе Б, которая отвечает за выполнение операций из системы А в систему Б.
Предположим, я делаю систему управления на базе k8s, пользователи могут заходить в мою систему и создавать задачи на k8s. На данный момент с точки зрения счетов я могу сделать следующее:
- Полная синхронизация: Моя учетная запись - учетная запись k8s. Подойди к новому пользователю, я использую openssl для выдачи сертификата x509 на k8s, и даю этот сертификат пользователю. Запрос пользователя несет этот сертификат, и я передаю его напрямую в k8s.
- Учетная запись условного депонирования: я развертываю агент на k8s, и агент использует учетную запись администратора, такую как cluster-admin.Когда пользователь запрашивает, я контролирую разрешения в своей системе управления и использую эту учетную запись администратора для всех операций, минуя аутентификацию и аутентификация k8s.
Первое решение заведомо неосуществимо, если я переустановлю нижележащий k8s, он будет смазан, и все пользователи не смогут пройти аутентификацию.
Недостаток второго решения в том, что в это время я потерял всю пользовательскую информацию на стороне k8s, и вообще не могу заниматься аудитом, логированием и отслеживанием.
Олицетворение может помочь нам устранить упомянутые выше недостатки. Эта учетная запись условного депонирования может декларировать свою личность как обычный пользователь.В настоящее время часть аутентификации apiserver по-прежнему использует учетные данные учетной записи условного депонирования, но часть аутентификации (управление полномочиями) основана на личности пользователя.
мы используемkubectl --as xxxМаскировку личности можно выполнить один раз, и эти инструкции по использованию не расширяются.
1.2.3 Что? k8s не имеет учетной записи пользователя?
k8s не сохраняет учетную запись пользователя, преимущество, естественно, сильное расширение ...... Я не сделал ничего другого, затем я начал Tucao его недостатки.
- K8S, построенный на платформе, необходимо создать собственную систему счетов. Конечно, позиционирование K8S является платформой для платформы Ну, думаю, что это не недостаток, но функция
- Служебная учетная запись, которая мешает: Возьмем, к примеру, rancher, владелец ранчо управляет своей собственной учетной записью, но на k8s также есть служебная учетная запись, система учетных записей которой независима от приложения верхнего уровня. Его контроль разрешений отделен от управления владельцем ранчо. Это заставляет операторов быть осторожными с теми службами, которым требуется доступ к apiserver внутри контейнера, потому что их действия никогда не проходят через плоскость управления владельцем ранчо.
Здесь слишком далеко, чтобы жаловаться, и я расскажу об этом, когда буду вводить аутентификацию и аутентификацию владельца ранчо.
1.2.4 authz: RBAC
Прежде чем вводить аутентификацию, читатели должны про себя произнести предложение:Аутентификация ориентирована на учетную запись, аутентификация ориентирована на личность. Это хорошо отражено в k8s.
По умолчанию k8s использует RBAC (управление доступом на основе ролей) для контроля разрешений. В реализации k8s черезRoleа такжеRoleBindingвыполнить. Конечно, естьClusterRoleа такжеClusterRoleBinding, но отличается только область действия (независимо от того, ограничена ли она пространством имен). Его основная идея заключается в следующем:Предоставляет удостоверению набор ролей, каждая роль определяет набор разрешений.
Напомним, что k8s не управляет учетными записями пользователей. Допустим мы очень примитивны и выдаем x509 сертификаты через openssl.При выдаче аккаунтов можно указать-subj "/CN=jbeda/O=app1/O=app2",ВидетьСертификат клиента X509.
Здесь мы указываем имя пользователя и группу пользователей для этой учетной записи. После последующей аутентификации k8s учетная запись будет обрабатываться какusername: jbeda; groups: [app1, app2]такую информацию и использовать ее какличностьиметь дело с. В качестве примера посмотрим на поля привязки роли:
Чтобы авторизовать личность:
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
Или авторизовать группу пользователей (набор удостоверений):
subjects:
- kind: Group
name: manager
apiGroup: rbac.authorization.k8s.io
Здесь читатель видитkind: UserЭто может вызвать у читателей много сомнений относительно этой статьи. На самом деле есть лишь некоторые различия в определениях буквальных понятий.
В контексте этой статьи пользователь относится к конечному пользователю, а учетная запись делится на учетную запись пользователя и учетную запись службы. Так что здесь используйтеличностьЭта концепция инкапсулирует имя пользователя + группу пользователей, что более способствует пониманию читателями аутентификации. Причины следующие:
- Согласно k8s, RBAC предназначен для авторизации пользователей, но k8s не управляет пользователями, так откуда берутся пользователи? Это самый противоречивый пункт.
- пользователь также может заполнить
system:serviceaccount:xxx:xxx, если учетная запись службы также рассматривается как пользователь, какие слова следует использовать для описания реального конечного пользователя? - Я уже говорил, что учетная запись соответствует личности, а «пользователь» передаетСертификация, подтвердил свою личность. существуетАутентификацияНа самом деле вам вообще не нужно заботиться о концепции пользователей, просто позаботьтесь об этомличность. Предположим, что конечный пользователь A входит в модуль и получает доступ к apiserver через токен служебной учетной записи. Можете ли вы сказать, что аутентификация предназначена для пользователя A? Потому что в это время apiserver видит учетную запись службы, а не конечного пользователя.
По вышеуказанным причинам я все же надеюсь, что в контексте аутентификации использоватьличностьЭто слово для обозначения k8sUserописание.
1.2.5 Недостатки RBAC: слегка жесткие правила
Преимущество RBAC в том, что он прост и непосредственен.После определения роли и привязки можно выполнить самый простой контроль разрешений.
Но, к сожалению, во многих сценариях реальной жизни чистый RBAC не может удовлетворить потребности. Предположим, в школе введена система управления разрешениями, и есть правило: после 10 часов каждый вечер ученикам не разрешается покидать школу. Очевидно, что простой RBAC не может справиться с таким сценарием.
Решением является контекстно-зависимая авторизация, такая как ABAC. Каждая аутентификация может содержать контекст, который определяет некоторую дополнительную информацию, такую как время, местоположение и т.д. В определении ABAC,attributeОн сам может нести дополнительную информацию о состоянии.
К сожалению, k8s недостаточно поддерживает ABAC.Используйте аутентификацию ABAC, определение его стратегии по-прежнему может быть легко преобразовано с помощью RBAC и не может использовать преимущества ABAC.
1.2.6 Источник масштабируемости: authn/authz/admission webhook
k8s поддерживает пользовательские стратегии аутентификации и аутентификации и хорошо их объединяет:
- Сертификация: ДоступноАутентификация токена вебхукаВнедрить пользовательскую логику аутентификации
- Аутентификация: также доступнаРежим веб-перехватчика
- Политика динамического допуска: доступнаDynamic Admission Control, такие как веб-перехватчики допуска, для реализации полностью настраиваемых политик допуска.
По сути, k8s использует форму веб-хука, чтобы делать эти вещи, определять интерфейс, и каждый может это сделать. Если вы хотите включить веб-перехватчики, читатели должны обратить внимание на два момента:
- Если есть веб -ook, будь то аутентификация или аутентификация, K8S будет одновременно получить доступ к веб -ookook. Пока либо встроенный, так и веб-канал, запрос пройдет запрос.
- Обратите внимание на управление потоком, ведь каждый запрос должен проходить через вебхук
1.2.7 Краткий обзор k8s authn и authz
Начиная с определений различных основных терминов, эта небольшая статья включает в себя множество мелких моментов, а разбираться в тонких различиях между ними — тоже неясное и скучное дело.
После этого я разобрался, как делается аутентификация и аутентификация в k8s, и разобрал их режимы и характеристики, в том числе то, что он не управляет учетными записями пользователей, а управляет учетными записями служб, поддерживает камуфляж пользователей, использует RBAC для аутентификации и обладает высокой масштабируемостью. ... Через некоторую интерпретацию этих режимов мы действительно можем узнать преимущества и недостатки k8s в аутентификации и аутентификации.
Конечно, многие пункты нерешительны, потому что они не говорили о владельце ранчо напрямую. Итак, следующая статья начнётся с ранчера.Отталкиваясь от этих преимуществ и недостатков, вы сможете прочувствовать, какие возможности дополняет дизайн ранчера, почему он так устроен, и вы сможете глубже понять ранчера.