Безопасность в Hadoop. Kerberos

Перевод: Саянкин А.А.

Предисловие переводчика

---

Данная статья представляет перевод главы Kerberos из книги «Безопасность в Hadoop» (Hadoop Security) Бэна Спиви (Ben Spivey), Джоуи Ичиверия (Joey Echeverria).

Переводчик выражает благодарность Виктору Жуковскому за ценные правки и обсуждение рукописи.

Kerberos. Введение

Kerberos зачастую пугает даже опытных системных администраторов и разработчиков даже при первом своём упоминании. Использование Kerberos для обеспечения безопасности приложений и систем часто влечёт за собой множественные обращения в службу поддержки с просьбами исправить ту или иную проблему, связанную с ним. В этой статье мы рассмотрим основные концепции Kerberos, необходимые для понимания механизмов аутентификации, а также то, как эти принципы используются для аутентификации в Hadoop.

Так почему именно Kerberos? Возвращаясь к древнегреческой мифологии, мы можем заметить, что название Kerberos произошло от слова Цербер — многоголовой собаки, охраняющей вход в Аид — царство мёртвых. Войдя однажды в Аид, человек уже не мог из него выйти. С технической (и более приятной) точки зрения Kerberos — это название механизма аутентификации, разработанного Массачусетским технологическим институтом (МТИ). Kerberos стал де-факто стандартом надёжной аутентификации для компьютерных систем больших и малых масштабов, причём реализация механизма может быть выполнена самыми различными компаниями и организациями, начиная от МТИ дистрибутива и заканчивая компонентами аутентификации Microsoft’s Active Directory.

Почему Kerberos?

Давайте попытаемся разобраться — зачем вообще платформе Hadoop нужен Kerberos? Причина становится ясна, если более детально взглянуть на модель аутентификации Hadoop, принятую по умолчанию. Если пользователь получил доступ к кластеру под каким-либо именем, то платформа Hadoop «доверяет» этому пользователю и гарантирует, что каждая машина, входящая в кластер, также «доверяет».

Рассмотрим аналогию. Если к вам на вечеринке подошёл человек и представился как «Билл», вы, естественно поверите, что он и в самом деле Билл. Но откуда вы знаете, что он и вправду Билл? В общем-то, потому что он так сказал, и вы верите ему без вопросов. Hadoop без Kerberos ведёт себя во многом аналогично, за исключением того, что он идёт ещё дальше: Hadoop не только верит Биллу, что он и в самом деле Билл, но и гарантирует, что и все остальные компоненты кластера также верят что Билл — это в самом деле Билл. В этом и проблема.

Платформа Hadoop изначально спроектирована для работы с петабайтами данных. И с течением времени становится ясно, что большая мощь влечёт за собой большую ответственность. Hadoop при промышленном использовании уже не может пользоваться упрощёнными механизмами идентификации и работы с пользователями. Вернёмся к Kerberos. В нашей предыдущей аналогии Билл представился вам. А что если после этого вы попросите предъявить оригинал паспорта, и получив его (ну конечно! Каждый ведь приносит на вечеринку паспорт...) проверите, есть ли он в вашей базе? Вот такую «проверку личности» и добавляет Kerberos аутентификация в Hadoop кластере.

Обзор Kerberos

Декорации расставлены и пришло время погрузиться в работу Kerberos. Реализация Kerberos, как вы могли уже наверное вообразить, представляет собой клиент/серверную архитектуру. Прежде чем рассматривать компоненты более детально, проведём экскурс в терминологию Kerberos.

Во-первых, пользователи или сервисы, имеющие учётную запись, в Kerberos называются принципалами. Каждый пользователь или сервис, который участвует в протоколе аутентификации Kerberos должен иметь принципал, для однозначного представления себя системе. Принципалы разделяются на две категории: пользовательские принципалы и сервисные принципалы. Пользовательские имена принципалов (UPN, от англ. User principal names, — прим. перев.) представляют обычных пользователей. Это очень похоже на имена пользователей или учётные записи из мира операционных систем. Сервисные имена принципалов (SPN, от англ. Service principal names, — прим. перев.) представляют сервисы, к которым пользователь желает получить доступ, такие как база данных или специфический сервер. Отношения между UPN и SPN станут более ясными после того, как позже мы рассмотрим пример работы.

Следующий важный термин в Kerberos — это реалм (англ. realm — сфера, область — прим. перев.). Реалм Kerberos — это административный домен аутентификации. Все принципалы принадлежат определённому реалму в Kerberos. Реалм определяет сферу работы принципалов, что упрощает администрирование.

Теперь, когда мы установили что такое принципалы и реалмы, следующим естественным шагом будет разобраться, где хранится эта информация и как ею управлять. Ответ — это центр распределения ключей (KDC, от англ. key distribution center — прим. перев.). Центр распределения ключей состоит из трёх компонент: базы данных Kerberos, сервиса аутентификации (AS, от англ. authentication service — прим. перев.) и сервиса предоставления тикетов (TGS, от англ. ticket-granting service — прим. перев.).

Первый компонент центра распределения ключей (KDC) — это база данных Kerberos. База данных Kerberos хранит среди прочего всю информацию о принципалах и реалмах, которым они принадлежат. Принципалы Kerberos определяются согласно следующим стандартам именования:

alice@EXAMPLE.COM

Это пользовательское имя принципала (UPN), которое однозначно определяет пользователя alice в реалме EXAMPLE.COM. (также называется кратким именем). Согласно стандартам именования имя реалма всегда пишется прописными буквами.

bob/admin@EXAMPLE.COM

Разновидность стандартного пользовательского имени принципала (UPN), которая определяет администратора bob для реалма EXAMPLE.COM. Слэш (/) в пользовательском имени принципала отделяет краткое имя от классификатора имени. Компонента admin обычно используется для указания того, что данный пользователь является администратором, однако это можно изменить, как мы увидим далее.

hdfs/node1.example.com@EXAMPLE.COM

Это сервисное имя принципала для сервиса hdfs, работающего на узле node1.example.com, в Kerberos реалме EXAMPLE.COM. Слэш (/) в сервисном имени принципала отделяет краткое имя hdfs от имени узла node1.example.com.

Примечание. Обратите внимание, что имя принципала чувствительно к регистру! Например, принципал hdfs/Node1.Hadoop.com@EXAMPLE.COM отличается от hdfs/node1.example.com@EXAMPLE.COM. Вообще говоря, для принципала принято использовать нижний регистр, за исключением реалма, который записывается в верхнем регистре. Заметим, что упомянутое выше имя узла в сервисном имени принципала также пишется в нижнем регистре, что является общепринятой практикой для имён узлов (хостов) и DNS.

Второй компонент центра распределения ключей (KDC) — это сервис аутентификации (AS), ответственный за выдачу клиенту тикета для предоставления тикетов (TGT, от англ. ticket-granting ticket — прим. перев.) по запросу от клиента. Тикет для предоставления тикетов (TGT) используется для получения доступа к другим сервисам.

Третий компонент центра распределения ключей (KDC) — это сервис предоставления тикетов (TGS) ответственный за проверку тикета для предоставления тикетов (TGT) и предоставление сервисных тикетов. Сервисные тикеты позволяют аутентифицированным принципалам использовать сервисы, предоставляемые сервером приложений. Сервисы должны иметь сервисные имена принципалов (SPN). Процесс работы, который заключается в получении тикета для предоставления тикетов (TGT), передаче его сервису предоставления тикетов (TGS), а затем получении сервисного тикета, более подробно рассмотрен в следующем разделе. Сейчас же заметим, что в центре распределения ключей (KDC) только два компонента принимают запросы на аутентификацию и предоставление доступа: сервис аутентификации (AS), сервис предоставления тикетов (TGS) — третий компонент (база данных Kerberos) используется для хранения принципалов.

Примечание. В базе данных Kerberos существует специальный принципал, задаваемый по шаблону krbtgt/<REALM>@<REALM>, например krbtgt/EXAMPLE.COM@EXAMPLE.COM. Этот принципал для внутреннего использования как сервисом аутентификации (AS) так и сервисом предоставления тикетов (TGS). Ключ для этого принципала используется для шифрования содержимого тикета для предоставления тикетов (TGT), который выдаётся клиентам. Таким образом гарантируется, что тикет для предоставления тикетов (TGT), выданный сервисом аутентификации (AS) может быть подтверждён только сервисом предоставления тикетов (TGS).

В таблице 1 собраны воедино все термины и аббревиатуры, введённые в этой главе.

Таблица 1 - Термины и аббревиатуры Kerberos

Аббревиатура	Термин	Описание
UPN	Пользовательское имя принципала	Принципал, определяющий пользователя в данном реалме в формате <краткое имя><@РЕАЛМ> или <краткое имя>/admin@<РЕАЛМ>
SPN	Сервисное имя принципала	Принципал, определяющий сервис на заданном узле в заданном реалме в формате <краткое имя>/<имя узла>@<РЕАЛМ>
TGT	Тикет для предоставления тикетов	Специальный вид тикета, который выдаётся пользователю после успешной аутентификации в сервисе аутентификации (AS)
KDC	Центр распределения ключей	Сервер Kerberos, состоящий из трёх компонент: базы данных Kerberos, сервиса аутентификации (AS) и сервиса предоставления тикетов (TGS)
AS	Сервис аутентификации	Сервис, который выдаёт тикеты для предоставления тикетов (TGT)
TGS	Сервис предоставления тикетов	Сервис, который проверяет тикеты для предоставления тикетов (TGT) и выдаёт сервисные тикеты

Мы познакомились с основными компонентами Kerberos, необходимыми для понимания аутентификации на самом общем уровне. Архитектура и внутренне устройство Kerberos — сама по себе сложная тема, заслуживающая отдельной книги.

Kerberos в работе. Простой пример

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

EXAMPLE.COM

Реалм Kerberos

Alice

Пользователь системы, с назначенным для него пользовательским именем принципала (UPN) равным alice@EXAMPLE.COM

myservice

Сервис, расположенный на узле server1.example.com с назначенным для него сервисным именем принципала (SPN) равным myservice/server1.example.com@EXAMPLE.COM

kdc.example.com

Центр распределения ключей (KDC) для реалма EXAMPLE.COM

Для того чтобы Alice получила право доступа к сервису myservice, она должна предоставить действительный тикет для myservice. Следующий список шагов поясняет, как она это сделает (некоторые детали опущены для краткости):

1. Alice необходимо получить тикет для предоставления тикетов (TGT). Для этого она инициирует запрос к сервис аутентификации (AS) на kdc.example.com, идентифицируя себя как alice@EXAMPLE.COM.
2. Сервис аутентификации (AS) отвечает Alice и предоставляет ей тикет для предоставления тикетов (TGT) зашифрованный с помощью ключа (пароля) от принципала alice@EXAMPLE.COM.
3. После получения зашифрованного сообщения Alice вводит пароль для принципала alice@EXAMPLE.COM для того, чтобы расшифровать сообщение.
4. После успешной расшифровки сообщения, содержащего тикет для предоставления тикетов (TGT), Alice запрашивает у сервиса предоставления тикетов (TGS), работающему на узле kdc.example.com, сервисный тикет для получения доступа к сервису, определённому принципалом myservice/server1.example.com@EXAMPLE.COM. В запросе Alice посылает тикет для предоставления тикетов (TGT), а в ответ получает упомянутый выше сервисный тикет.
5. Cервис предоставления тикетов (TGS) проверяет тикет для предоставления тикетов (TGT) и предоставляет Alice сервисный тикет, зашифрованный ключом от принципала myservice/server1.example.com@EXAMPLE.COM.
6. Alice теперь передаёт сервисный тикет сервису myservice, который может его затем расшифровать используя ключ принципала myservice/server1.example.com@EXAMPLE.COM и выполнить проверку тикета.
7. Сервис предоставляет доступ Alice использовать самого себя, поскольку она корректно прошла аутентификацию.

Вот вкратце как работает Kerberos. Конечно, это очень упрощённый пример, и множество второстепенных деталей было опущено при изложении. На рисунке 1 изображена диаграмма последовательностей приведённого примера.

Доверительные каналы связи в Kerberos

До сих пор мы работали с Kerberos в предположении, что все пользователи и сервисы принадлежат одному и тому же Kerberos реалму. Этот вариант является удовлетворительным для знакомства с материалом, но в больших промышленных масштабах такое решение является неудовлетворительным. Со временем большие компании так или иначе приходят к использованию множества Kerberos реалмов по причине объединения отдельных коммерческих отделов, добавления новых подразделений либо для разграничения доступа к данным и сервисам для различных частей предприятия. Однако, по умолчанию центр распределения ключей (KDC) имеет информацию только о своих собственных реалмах и принципалах, которые хранятся в его базе данных. Что если пользователь под одним реалмом захочет использовать сервис, находящийся под другим реалмом? Для того чтобы это произошло необходимо установить доверительный канал связи между двумя реалмами.

Предположим, что Example является очень большой корпорацией, принявшей решение создать несколько реалмов для идентификации различных бизнес-подразделений: включая реалм для отдела по работе с персоналом HR.EXAMPLE.COM и реалм отдела маркетинга MARKETING.EXAMPLE.COM. Поскольку пользователям в указанных реалмах может понадобиться доступ к сервисам, находящимся в другом реалме, Центр распределения ключей (KDC) реалма HR.EXAMPLE.COM должен установить доверительный канал связи с MARKETING.EXAMPLE.COM и наоборот.

На первый взгляд это кажется довольно очевидным, за исключением того, что фактически есть два типа доверительных каналов связи: однонаправленный доверительный канал связи и двунаправленный доверительный канал связи (иногда называемый также полным доверительным каналом связи).

Предположим, что есть также реалм DEV.EXAMPLE.COM, где разработчики хранят принципалы, которым необходимо дать доступ к реалмам DEV.EXAMPLE.COM и MARKETING.EXAMPLE.COM, при этом пользователи отдела маркетинга не должны иметь доступ к реалму DEV.EXAMPLE.COM. Как это сделать? Данный сценарий требует использования однонаправленного доверительного канала связи.

Однонаправленные доверительные каналы связи очень часто используются в кластерах Hadoop в ситуации, когда центр распределения ключей (KDC) установлен и настроен на хранение всей информации о сервисных именах принципалов (SPN) на узлах кластера, но пользовательские имена принципалов существуют в другом реалме, например в Active Directory. Зачастую, либо администраторы Active Directory, либо принципы корпоративной политики запрещают полные доверительные каналы связи.

Итак, как устанавливается доверительный канал связи в Kerberos? Ранее мы указывали, что сервис аутентификации (AS) и сервис предоставления тикетов (TGS) используют для внутренней работы специальный принципал вида krbtgt/<REALM>@<REALM>. Этот принципал приобретает важнейшее значение настройке доверительных каналов связи. При их использовании он принимает вид krbtgt/<РЕАЛМ_ДОВЕРИТЕЛЬ>@<ДОВЕРЯЕМЫЙ_РЕАЛМ>. Суть в том, что данный принципал существует в двух реалмах. Например, если HR.EXAMPLE.COM — реалм доверитель, а MARKETING.EXAMPLE.COM — доверяемый реалм, то принципал krbtgt/HR.EXAMPLE.COM@MARKETING.EXAMPLE.COM должен существовать в обоих реалмах.

Примечание. Пароль и тип шифрования для принципала krbtgt/<РЕАЛМ_ДОВЕРИТЕЛЬ>@<ДОВЕРЯЕМЫЙ_РЕАЛМ> должны быть одинаковы в обоих реалмах для установления доверительного каналы связи.

В предыдущем примере мы рассмотрели необходимые действия для установления однонаправленного доверительного канала связи. Для установления полного доверительного канала связи принципал krbtgt/MARKETING.EXAMPLE.COM@HR.EXAMPLE.COM также должен существовать в обоих реалмах. Иначе говоря, для установления полного доверительного канала связи между HR.EXAMPLE.COM и MARKETING.EXAMPLE.COM оба реалма должны иметь принципалы krbtgt/MARKETING.EXAMPLE.COM@HR.EXAMPLE.COM и krbtgt/HR.EXAMPLE.COM@MARKETING.EXAMPLE.COM.

Реализация Kerberos Массачусетского технологического института

Упомянутый в начале главы протокол Kerberos был впервые создан в Массачусетском технологическом институте. На протяжении нескольких лет было выпущено несколько версий, текущей из которых является MIT Kerberos V5 или krb5 как её часто ещё называют. В этом разделе описаны компоненты реализации Kerberos Массачусетского технологического института для того, чтобы привести пример реального использования концептуальных идей, обозначенных выше.

Ранее в примере мы рассмотрели ситуацию, когда Alice инициирует запрос на аутентификацию. На практике Alice использует для этого инструмент kinit.

Пример. Аутентификация с помощью kinit для пользователя по умолчанию

[alice@server1 ~]$ kinit

Enter password for alice@EXAMPLE.COM:

[alice@server1 ~]$

Этот пример связывает текущего пользователя Linux alice с реалмом по умолчанию для формирования принципала alice@EXAMPLE.COM и выполнения запроса аутентификации. Понятие реалма по умолчанию будет введено далее при более детальном рассмотрении файлов конфигурации. Инструмент kinit также позволяет пользователям явно задать принципал для аутентификации.

Пример. Аутентификация с помощью kinit для заданного принципала

[alice@server1 ~]$ kinit alice/admin@EXAMPLE.COM

Enter password for alice/admin@EXAMPLE.COM:

[alice@server1 ~]$

Как показано в примере выше, явное задание имени принципала часто требуется для аутентификации администраторов. Другой способ аутентификации — это использование keytab файла. Файл keytab хранит действительный ключ шифрования, который может быть использован вместо процедуры ввода пароля для данного принципала. Обычно файл keytab создаётся для неинтерактивных принципалов, таких как сервисные имена принципалов (SPN), которые часто присваиваются долго живущим процессам (например, фоновые процессы Hadoop). Один файл keytab не обязательно должен соответствовать строго одному принципалу. Различные ключи разных принципалов могут хранится в одном и том же keytab файле. Пользователь может использовать kinit совместно с keytab файлом, задавая расположение keytab файла и имя принципала для аутентификации (повторим, несколько ключей различных принципалов могут хранится в одном keytab файле). См. пример ниже.

Пример. Использование kinit и keytab файла

[alice@server1 ~]$ kinit -kt alice.keytab alice/admin@EXAMPLE.COM

[alice@server1 ~]$

Файл keytab позволяет аутентифицировать пользователя без знания пароля. Принимая во внимание данный факт, файлы keytab должны быть защищены соответствующими инструментами для предотвращения аутентификации с их помощью несанкционированных пользователей. Это особенно важно, когда файлы keytab создаются для административных принципалов.

Другой удобный инструмент, являющийся частью дистрибутива Kerberos Массачусетского технологического института — это klist. Утилита klist позволяет посмотреть, какие учётные записи с параметрами доступа пользователя, сформированными после его успешной аутентификации, находятся в кеше учётных записей. Кеш учётных записей — это место в локальной файловой системе, где после успешной аутентификации в сервисе аутентификации хранятся тикеты для предоставления тикетов. По умолчанию кеш хранится в файле /tmp/krb5cc_<uid>, где <uid> - числовой идентификатор пользователя в локальной файловой системе. После успешной аутентификации с помощью kinit, alice может просмотреть свой кеш учётных записей с помощью klist, как показано в примере ниже.

Пример. Просмотр кеша учетных записей с помощью klist

[alice@server1 ~]$ kinit

Enter password for alice@EXAMPLE.COM:

[alice@server1 ~]$ klist

Ticket cache: FILE:/tmp/krb5cc_5000

Default principal: alice@EXAMPLE.COM

Valid starting Expires Service principal

02/13/14 12:00:27 02/14/14 12:00:27 krbtgt/EXAMPLE.COM@EXAMPLE.COM

renew until 02/20/14 12:00:27

[alice@server1 ~]$

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

Пример. Просмотр кеша учетных записей без аутентификации

[alice@server1 ~]$ klist

No credentials cache found (ticket cache FILE:/tmp/krb5cc_5000

[alice@server1 ~]$

Ещё один полезный инструмент являющийся частью дистрибутива Kerberos Массачусетского технологического института — это kdestroy. Как видно из имени он позволяет пользователям удалять учётные записи из кеша учётных записей. Это бывает полезно при переключении пользователей либо при отладке новой конфигурации.

Пример. Удаление учётной записи с помощью утилиты kdestroy.

[alice@server1 ~]$ kinit

Enter password for alice@EXAMPLE.COM:

[alice@server1 ~]$ klist

Ticket cache: FILE:/tmp/krb5cc_5000

Default principal: alice@EXAMPLE.COM

Valid starting Expires Service principal

02/13/14 12:00:27 02/14/14 12:00:27 krbtgt/EXAMPLE.COM@EXAMPLE.COM

renew until 02/20/14 12:00:27

[alice@server1 ~]$ kdestroy

[alice@server1 ~]$ klist

No credentials cach

Пока мы рассматривали примеры работы утилит из дистрибутива Kerberos Массачусетского технологического института, которые «просто работают» при запуске. В примерах мы опустили тот факт, что необходимо выполнить множество шагов по конфигурированию Kerberos прежде, чем всё это заработает как на клиентской так и на серверной стороне. В следующих разделах мы опишем основы конфигурирования Kerberos необходимые для того, чтобы связать воедино предоставленные выше концепции.

Серверная конфигурация

Серверная конфигурация Kerberos главным образом определяется в файл kdc.conf, представленным в примере ниже. Этот файл находится в каталоге /var/kerberos/krb5kdc/ в системах Red Hat/CentOS.

Пример. Файл kdc.conf

[kdcdefaults]

kdc_ports = 88

kdc_tcp_ports = 88

[realms]

EXAMPLE.COM = {

acl_file = /var/kerberos/krb5kdc/kadm5.acl

dict_file = /usr/share/dict/words

supported_enctypes = aes256-cts:normal aes128-cts:normal arcfour-hmac-md5:normal

max_renewable_life = 7d

}

Первая секция kdcdefaults содержит настройки, которые применяются ко всем реалмам. Если же конкретный реалм содержит то же свойство, но с другим значением, отличным от общих настроек, то оно будет переопределено для данного реалма. Настройки kdc_ports и kdc_tcp_ports определяют соответственно UDP (User Datagram Protocol – протокол пользовательских датаграмм – прим. перев.) и TCP (Transmission Control Protocol — протокол управления передачей – прим. перев.) порты, которые будет слушать центр распределения ключей (KDC). В следующей секции realms содержаться все реалмы, которые обслуживает центр распределения ключей (KDC). Один и тот же центр распределения ключей (KDC) может поддерживать несколько реалмов. Настройки для реалма в приведённом выше примере следующие:

acl_file

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

dict_file

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

supported_enctypes

Определяет все типы шифрования, которые поддерживает центр распределения ключей (KDC). При взаимодействии с центром распределения ключей (KDC) клиенты должны поддерживать как минимум один тип шифрования из приведённых здесь. Будьте осторожны и не используйте слабые типы шифрования, такие как DES, поскольку их легко взломать.

max_renewable_life

Определяет максимальное время, в течении которого тикет может быть возобновлён. Клиенты могут возобновить тикет в течении этого времени. Типичное значение — семь дней, обозначаемое 7d.

Примечание. По умолчанию настройка шифрования дистрибутива Kerberos Массачусетского технологического института часто содержит множество типов шифрования, в том числе и слабые типы шифрования, такие как DES. По возможности удаляйте слабые типы шифрования, для обеспечения более надёжной безопасности. Слабые типы шифрования легко взломать, кроме того, они хорошо документированы. При использовании AES-256 (Advanced Encryption Standard - симметричный алгоритм блочного шифрования (размер блока 128 бит, ключ 128/192/256 бит), принятый в качестве стандарта шифрования правительством США по результатам конкурса AES – прим. перев.) на все узлы кластера должны быть установлены криптографические расширения Java для включения в работу типов шифрования с неограниченной глубиной шифрования. Важно заметить, что в некоторых странах запрещено использовать данные типы шифрования. Всегда выполняйте государственные законы о глубине шифрования для вашей страны.

Файл, заданный в свойстве acl_file (обычно это kadm5.acl) используется для определения того, какие пользователи будут иметь привилегированный доступ к административной базе данных Kerberos. Администрирование базы данных Kerberos осуществляется двумя различными, но взаимосвязанными компонентами: kadmin.local и kadmin. Первая компонента — это утилита, позволяющая пользователю root центра распределения ключей (KDC) модифицировать базу данных. Как видно из имени, утилита может быть запущена только пользователем root на той машине, где расположена база данных Kerberos. Администраторы, желающие управлять базой данных Kerberos удалённо, должны использовать сервер kadmin.

Сервер kadmin — это фоновый процесс, который позволяет посредством удалённых соединений администрировать базу данных Kerberos. В этом случае мы используем файл kadm5.acl (см. пример выше). Утилита kadmin использует аутентификацию Kerberos, а файл kadm5.acl определяет какие пользовательские имена принципалов (UPN) разрешены для выполнения привилегированных функций.

Пример. Файл kadm5.acl

*/admin@EXAMPLE.COM *

cloudera-scm@EXAMPLE.COM * hdfs/*@EXAMPLE.COM

cloudera-scm@EXAMPLE.COM * mapred/*@EXAMPLE.COM

Этот файл позволяет любому принципалу из реалма EXAMPLE.COM с компонентой /admin выполнять административные действия. Конечно мы можем изменить компоненту /admin на любое другое произвольное имя; для простоты и понятности рекомендуется следовать соглашению в именовании компонент, согласно которому /admin — означает администраторов. Пользователи с правами администраторов должны использовать свои привилегии полного доступа только для административных задач, также как например, администраторы операционных систем не должны использовать пользователя root для повседневных задач, а только для специфических административных.

Этот пример также показывает как список управления доступом (ACL, Access Control List - прим. перев.) может быть определён для ограничения привилегий целевых принципалов. В частности, видно, что пользователь cloudera-scm может выполнять выполнять любые действия, но только над сервисными именами принципалов (SPN), которые начинаются hdfs и mapred. Такой тип синтаксиса полезен для предоставления доступа программному обеспечению от третьих лиц на создание и администрирование принципалов Hadoop, при этом полный доступ к функциям администрирования не выдаётся.

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

Пример. Добавление нового принципала в базу данных Kerberos

kadmin: addprinc alice@EXAMPLE.COM

WARNING: no policy specified for alice@EXAMPLE.COM; defaulting to no policy

Enter password for principal "alice@EXAMPLE.COM":

Re-enter password for principal "alice@EXAMPLE.COM":

Principal "alice@EXAMPLE.COM" created.

kadmin:

Пример. Получение информации по принципалу из базы данных Kerberos

kadmin: getprinc alice@EXAMPLE.COM

Principal: alice@EXAMPLE.COM

Expiration date: [never]

Last password change: Tue Feb 18 20:48:15 EST 2014

Password expiration date: [none]

Maximum ticket life: 1 day 00:00:00

Maximum renewable life: 7 days 00:00:00

Last modified: Tue Feb 18 20:48:15 EST 2014 (root/admin@EXAMPLE.COM)

Last successful authentication: [never]

Last failed authentication: [never]

Failed password attempts: 0

Number of keys: 2

Key: vno 1, aes256-cts-hmac-sha1-96, no salt

Key: vno 1, aes128-cts-hmac-sha1-96, no salt

MKey: vno1

Attributes:

Policy: [none]

kadmin:

Пример. Удаление принципала из базы данных Kerberos

kadmin: delprinc alice@EXAMPLE.COM

Are you sure you want to delete the principal "alice@EXAMPLE.COM"? (yes/no): yes

Principal "alice@EXAMPLE.COM" deleted.

Make sure that you have removed this principal from all ACLs before reusing.

kadmin:

Пример. Отображение всех принципалов в базе данных Kerberos

kadmin: listprincs

HTTP/server1.example.com@EXAMPLE.COM

K/M@EXAMPLE.COMbob@EXAMPLE.COM

flume/server1.example.com@EXAMPLE.COM

hdfs/server1.example.com@EXAMPLE.COM

hdfs@EXAMPLE.COM

hive/server1.example.com@EXAMPLE.COM

hue/server1.example.com@EXAMPLE.COM

impala/server1.example.com@EXAMPLE.COM

kadmin/admin@EXAMPLE.COM

kadmin/server1.example.com@EXAMPLE.COM

kadmin/changepw@EXAMPLE.COM

krbtgt/EXAMPLE.COM@EXAMPLE.COM

mapred/server1.example.com@EXAMPLE.COM

oozie/server1.example.com@EXAMPLE.COM

yarn/server1.example.com@EXAMPLE.COM

zookeeper/server1.example.com@EXAMPLE.COM

kadmin:

Клиентская конфигурация

По умолчанию клиентская конфигурация Kerberos находится в файле krb5.conf в каталоге /etc/ в системах Unix/Linux. Этот конфигурационный файл читается всякий раз, когда клиентское приложение использует Kerberos, включая утилиту kinit. Пример минимального файла конфигурации krb5.conf для систем Red Hat/CentOS 6.4 показан ниже.

Пример. Файл krb5.conf

[logging]

default = FILE:/var/log/krb5libs.log

kdc = FILE:/var/log/krb5kdc.log

admin_server = FILE:/var/log/kadmind.log

[libdefaults]

default_realm = DEV.EXAMPLE.COM

dns_lookup_realm = false

dns_lookup_kdc = false

ticket_lifetime = 24h

renew_lifetime = 7d

forwardable = true

default_tkt_enctypes = aes256-cts aes128-cts

default_tgs_enctypes = aes256-cts aes128-cts

udp_preference_limit = 1

[realms]

EXAMPLE.COM = {

kdc = kdc.example.com

admin_server = kdc.example.com

}

DEV.EXAMPLE.COM = {

kdc = kdc.dev.example.com

admin_server = kdc.dev.example.com

}

[domain_realm]

.example.com = EXAMPLE.COM

example.com = EXAMPLE.COM

.dev.example.com = DEV.EXAMPLE.COM

dev.example.com = DEV.EXAMPLE.COM

В данном примере несколько различных разделов. Первый, logging, говорит сам за тебя. Он определяет, где будут храниться файлы журналов многочисленных компонент Kerberos. Второй раздел, libdefaults, содержит общую конфигурационную информацию по умолчанию. Рассмотрим более детально содержание данного раздела:

default_realm

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

dns_lookup_realm

Задаёт будет ли использоваться DNS для определения того, какой реалм Kerberos нужно использовать.

dns_lookup_kdc

Задаёт будет ли использоваться DNS для определения расположения центра распределения ключей (KDC).

ticket_lifetime

Определяет время, в течении которого тикет действителен. Может принимать все значения не превышающие максимально времени действия тикета, заданного в центре распределения ключей (KDC).

renew_lifetime

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

forwardable

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

default_tkt_enctypes

Определяет тип шифрования сессионных ключей при выполнении запросов к сервису аутентификации (AS). Типы шифрования выбираются в порядке следования, слева направо.

default_tgs_enctypes

Определяет тип шифрования сессионных ключей при выполнении запросов к сервису предоставления тикетов (TGS). Типы шифрования выбираются в порядке следования, слева направо.

udp_preference_limit

Определяет максимальный размер пакета перед тем как переключиться с UDP на TCP. При установке в значение 1, TCP будет использоваться всегда.

В следующем разделе realms содержится список всех реалмов Kerberos, доступных клиенту. Свойства kdc и admin_server задают имя узла, где запущенны процессы центра распределения ключей (KDC) и kadmin соответственно. Можно также задать порт. Если порт не задан, по умолчанию используется порт 88 для процесса центра распределения ключей (KDC) и порт 749 для kadmin. В примере выше показаны два реалма. Это типичная конфигурация, когда используется однонаправленный доверительный канал связи между двумя реалмами и клиенты должны знать об обоих реалмах. Реалм EXAMPLE.COM содержит все принципалы конечных пользователей, а реалм DEV.EXAMPLE.COM — все сервисные принципалы Hadoop кластера разработчиков. Используя настройки выше мы добиваемся того, что пользователи кластера разработчиков могут использовать свои существующие параметры доступа в DEV.EXAMPLE.COM для доступа к EXAMPLE.COM.

Последний раздел, domain_realm, устанавливает соответствие между DNS именами и реалмами Kerberos. Первая строка этого раздела сообщает о том, что подузлы узла example.com соответствуют реалму EXAMPLE.COM, а вторая строка сообщает, что сам по себе узел example.com также соответствует реалму EXAMPLE.COM. Аналогичные настройки выполнены для dev.example.com и DEV.EXAMPLE.COM. Если данный раздел пуст, то клиент попытается использовать доменную часть имени DNS (приведённую к верхнему регистру) в качестве имени реалма.

Выводы

Важным итогом данной главы является то, что аутентификация Kerberos является многошаговым клиент/серверным процессом предоставляющим хорошо защищённую аутентификацию для пользователей и сервисов. Мы рассмотрели реализацию Kerberos Массачусетского технологического института, которая является наиболее популярной. Несмотря на то, что в этой главе мы описали некоторые детали настройки реализации Kerberos Массачусетского технологического института, мы рекомендуем обращаться к официальной документации по данному проекту, поскольку, во-первых, она описывает все последние в реализации и, во-вторых, служит более детальным руководством о всех доступных опциях доступных администратору для настройки Kerberos окружения.

Перечень использованных ссылок

1. http://shop.oreilly.com/product/0636920033332.do