Настройка авторизации в WS GRAM на основании VOMS-расширений прокси-сертификатов

Table of Contents

  1. 0 Общие положения
    1. 0.1 Зачем нужна VOMS-авторизация на вычислительных ресурсах
    2. 0.2 Зачем нужен этот текст, да ещё и лежащий в Wiki
    3. 0.3 Статус разработки данного текста
    4. 0.4 Соглашения по тексту
    5. 0.5 Требования к окружению
  2. 1 Работа инсталляционного скрипта
    1. 1.1 Обзор скрипта
    2. 1.2 Внутреннее устройство скрипта
    3. 1.3 Архитектура и ограничения авторизационной подсистемы
  3. 2 Настройка авторизации через пул эккаунтов и её проверка с помощью glexec
  4. 3 Настройка gridftp
  5. 4 Настройка веб-сервисов

0 Общие положения

0.1 Зачем нужна VOMS-авторизация на вычислительных ресурсах

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

0.2 Зачем нужен этот текст, да ещё и лежащий в Wiki

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

0.3 Статус разработки данного текста

В тексте описана настройка авторизации на основании VOMS-расширений прокси-сертификатов в сервисах gridftp, delegation, rft и gram. Настройка MDS не описывается, этот вопрос стоит задать разработчикам Информационной системы.

Данный текст разработан на основе канонической инструкции от центральной команды ГридННС. Кроме того, может оказаться полезной прочая формализованная мудрость Романа Куракина.

Приведённые ниже файлы настройки lcmaps-*.db выполняют возложенные на них функции по voms-авторизации, однако содержат посторонние модули, в частности - могут содержать авторизацию по фиксированным отображениям DN->эккаунт.

Наконец, часть glite-овских софтин при компиляции требуют патчения, так что, видимо, следует продолжать обсуждение с их разработчиками через glite-овские билетики.

0.4 Соглашения по тексту

Настройки производились для виртуальной организации gridnnn и сервера gtb1.grid.kiae.ru, так что не забудьте менять соответствующие названия на свои.

0.5 Требования к окружению

Текст написан для ЭВМ под управлением Centos5 с установленными на неё Java и Ant. Сборка не проверялась на 64 битных архитектурах, так что приготовьте напильник.

1 Работа инсталляционного скрипта

1.1 Обзор скрипта

На данный момент разработан набор bash-евских скриптов, устанавливающих всё необходимое ПО поверх операционной системы CentOS 5.2 . Учтите, что на данный момент в нём не реализован контроль за ошибками, связанными с сетевыми проблемами или несоответствием реальной операционной системы указанной.

Для протоколирования консольного ввода-вывода рекомендуется использовать команду 

script <имя файла>

Скрипты доступны в svn: svn co https://svn.ngrid.ru/voms-integration/trunk voms-integration. После скачивания, в файле install.sh задайте значение переменной VO_NAME и запустите этот файл.

1.2 Внутреннее устройство скрипта

Сначала базовый скрипт install.sh инсталлирует модули, входящие в состав CentOS: openldap-devel doxygen libxml2-devel apr-devel httpd-devel perl-XML-Parser ant-nodeps automake libtool bison flex gcc-c++ pkgconfig openssl-devel curl-devel. За тем из-под рута из исходников собирается и инсталлируется gSoap и xacml.

После этого из-под пользователя globus запускается несколько (под)скриптов. Использование отдельного пользователя помогает защитить остальную систему от переписывания файлов в случае каких-то ошибок в инсталляционном сценарии. Скрипты изменяют, компилируют и устанавливают (как правило, безо всякой настройки) следующее ПО:

  • install1.sh - GT4.2.1 (как правило уже выполнено на стыках ЛМР)
  • install2.sh - lcas, lcas-interface и gridsite
  • install3.sh - VOMS API
  • install4.sh - lcas-plugins-basic, lcas-plugins-voms
  • install5.sh - lcmaps, lcmaps-plugins-basic, lcmaps-plugins-verify-proxy, lcmaps-plugins-voms
  • install6.sh - glexec
  • install7.sh - lcas-lcmaps-gt4-interface
  • install8.sh - lcas-lcmaps-pdp

Порядок компиляции таков, что самые простые тесты, исполняемые с помощью glexec, могут производиться после успешного выполнения с 1-го по 6-й скриптов. Успешное исполнение 7-го скрипта приводит к возможности настройки и тестирования gridftp-сервера, 8-го -- веб сервисов delegation, rft и gram.

install.sh генерирует пул эккаунтов для заданной в переменной VO_NAME виртуальной организации, но не создаёт домашние каталоги пользователей и скрэтч-каталоги для передачи файлов (обычно - ~/.globus/scratch ).

При исполнении 1-го скрипта могут возникать проблемы с линковкой динамических библиотек. Запустите ldconfig и перезапустите install.sh ещё раз.

1.3 Архитектура и ограничения авторизационной подсистемы

Сервис gridftp использует lcas-lcmaps-gt4-interface в качестве авторизационного модуля. Это позволяет настраивать доступ практически к любым файлам и каталогам файловой системы шлюза, т.к. даёт возможность выбирать не только юниксовый эккаунт, но и перечень вторичных юниксовых групп, под которыми процесс gridftp обращается к файловой системе.

Ошибка в модуле lcas-lcmaps-gt4-interface требует для правильной авторизации в gridftp наличия VOMS-расширения в одном из неголовных сертификатов цепочки прокси-сертификата. В условиях штатной эксплуатации шлюзов к ресурсам ГридННС это, по-видимому, вообще не является проблемой, т.к. авторизация с помощью этого модуля осуществляется прокси-сертификатами, делегированными через сервис делегирования. В любом случае, имея прокси-сертификат с VOMS-расширением, можно без особого труда получить такую цепочку генерированием нового прокси-сертификата на основе имеющегося.

Веб-сервисы, запущенные в контейнере (delegation, rft и gram) используют специально разработанную библиотеку lcas-lcmaps-pdp -- т.н. перехватчик с интерфейсом PDP (Policy Decision Point). Этот перехватчик подгружает библиотеки LCAS и LCMAPS, позволяя использовать любые подключаемые к ним модули авторизации для назначения локального пользовательского эккаунта, однако не позволяет осуществлять назначение локальных вторичных (supplementary) пользовательских групп запускаемому GRAM-ом процессу в силу ограничений Globus Toolkit. Обход этих ограничений, видимо, возможен только при внесении изменений в код самого GT. Кроме того, далеко не все локальные менеджеры ресурсов можно настроить на допуск задач к очередям на основании перечня вторичных групп запускающего задачу процесса.

Это ограничение порождает ограничение на возможные подгруппы ВО. Для данной виртуальной организации невозможно корректно различать подгруппы G1...GN, для которых нельзя сказать, что G1 содержит G2, которая содержит G3, ... которая содержит GN. Например, если есть почти всегда пустая очередь A для маленьких задач и очередь B для больших и долгих задач, то нельзя настроить систему так, чтобы по аттрибуту /VO/groupA пользователей пускали к очереди A, а по аттрибуту /VO/groupB пользователей пускали бы к очереди B, т.к. при наличии в аттрибутном сертификате одновременно /VO/groupA и /VO/groupB не понятно, из какого пула эккаунтов выбирать эккаунт: из эккаунта пользователей, допущенных лишь к очереди A, или из эккаунтов пользователей, допущенных лишь к очереди B.

Заставить LCMAPS на основании наличия в АС лишь двух этих аттрибутов выбирать пользователей из пула эккаунтов, допущенных к обоим очередям, невозможно. Обходы этого ограничения палиативны, например: пусть пользователи, допущенные к очереди B, будут допущены и к очереди A. Другой вариант: завести в VOMS-сервере аттрибут /VO/groupAB и следить, чтобы обладатели аттрибутов /VO/groupA и /VO/groupB получали бы в довесок аттрибут /VO/groupAB.

Скрипт install7.sh "намертво" прописывает "локальную" авторизацию gridftp через gridmapdir (точнее, ссылку на конфигурационный файл lcmaps-local.db).

2 Настройка авторизации через пул эккаунтов и её проверка с помощью glexec

Как уже было сказано, install.sh создаёт пул эккаунтов. Если читатель желает генерировать этот пул самостоятельно, то перед запуском install.sh необходимо в этом файле закомментировать соответствующий кусок кода.

Кроме того, необходимо самостоятельно создать пользовательские каталоги для каждого эккаунта из пула. В них, в частности, должны быть созданы скрэтч-каталоги, обычно ~/.globus/scratch , в которых в последствии будут создаваться рабочие каталоги для каждой запущенной на ресурсе гридовской задачи.

Тестироваться будем из-под пользователя test. Под рутом: 

adduser test -g glexec -u 9999

Создаём конфигурационные файлы. /etc/grid-security/grid-mapfile : 

"/gridnnn" .gridnnn

/etc/grid-security/groupmapfile : 

"/gridnnn" gridnnn

/etc/grid-security/glexec.conf : 

[glexec]
lcmaps_db_file               = /etc/grid-security/lcmaps/lcmaps-local.db
lcmaps_log_file              = /var/log/glexec/lcas_lcmaps.log
lcmaps_debug_level           = 5
lcmaps_log_level             = 5
lcmaps_get_account_policy    = glexec_get_account
lcmaps_verify_account_policy = glexec_verify_account
lcas_db_file                 = /etc/grid-security/lcas/lcas-local.db
lcas_log_file                = /var/log/glexec/lcas_lcmaps.log
lcas_debug_level             = 5
linger                       = yes
silent_logging               = no
log_level                    = 5
user_identity_switch_by      = lcmaps
user_white_list              = test, root

/etc/grid-security/lcmaps/lcmaps-local.db : 

path = /opt/glite/lib/modules

posix_enf        = "lcmaps_posix_enf.mod"
                   " -maxuid 1"
                   " -maxpgid 1"
                   " -maxsgid 32"

verifyproxy = "lcmaps_verify_proxy.mod"
              " -certdir /etc/grid-security/certificates"
              " --allow-limited-proxy"

localaccount     = "lcmaps_localaccount.mod"
                   "-gridmapfile /etc/grid-security/grid-mapfile"

poolaccount      = "lcmaps_poolaccount.mod"
                   " -override_inconsistency"
                   " -gridmapfile /etc/grid-security/grid-mapfile"
                   " -gridmapdir /etc/grid-security/gridmapdir"

vomslocalgroup   = "lcmaps_voms_localgroup.mod"
                   "-groupmapfile /etc/grid-security/groupmapfile"
                   "-mapmin 1"

vomspoolaccount  = "lcmaps_voms_poolaccount.mod"
                   "-gridmapfile /etc/grid-security/grid-mapfile"
                   "-gridmapdir /etc/grid-security/gridmapdir"
                   "-do_not_use_secondary_gids"

vomslocalaccount = "lcmaps_voms_localaccount.mod"
                   "-gridmapfile /etc/grid-security/grid-mapfile"
                   "-use_voms_gid"

glexec_get_account:
verifyproxy -> vomslocalgroup
vomslocalgroup -> vomspoolaccount
vomspoolaccount -> posix_enf
vomslocalaccount -> posix_enf
localaccount -> posix_enf
poolaccount -> posix_enf

/etc/grid-security/lcas/lcas-local.db : 

pluginname=lcas_userban.mod,pluginargs=/etc/grid-security/ban_users.db

Создаём каталог /etc/grid-security/vomses. Мы честно пытались найти все места в коде, ссылающиеся на /opt/glite/etc/vomses, чтобы заменить этот путь на /etc/grid-security/vomses, но тщетно. По этой причине, создайте, пожалуйста, каталог /etc/grid-security/vomses, и сделайте на него symlink со стороны /opt/glite/etc/vomses. Это наш маразм, но иначе у нас это не работает.

Итак, в /etc/grid-security/vomses должны лежать файлы с именами, соответствующими именам виртуальных организаций. Эти файлы должны содержать строчки, которые можно подсмотреть во вкладке Configuration интерфейса VOMS-Admin нужной СУВО. Например, для ВО gridnnn такая строчка, находящаяся по адресу https://voms.ngrid.ru:8443/voms/gridnnn/Configuration.do, имеет вид: 

"gridnnn" "voms.ngrid.ru" "15002" "/C=RU/O=NanoGrid/OU=hosts/OU=sinp.msu.ru/CN=voms.ngrid.ru" "gridnnn"

В каталоге /etc/grid-security/certificates должны быть указаны СА, выписавшие сертификаты СУВО серверов и пользователей.

CRL-ы должны быть свежими. Это достигается, например, командой fetch-crl.

В каталоге /etc/grid-security/vomsdir для каждой ВО должен быть создан подкаталог с именем этой ВО. В нём для каждого сервера VOMS создаётся файл с именем <FQDN>.lsc с двумя строками, в первой из которых записывается DN VOMS-сервера, а во второй - DN CA, выписавшего сертификат этого сервера. Например, файл /etc/grid-security/vomsdir/gridnnn/voms.ngrid.ru.lsc имеет вид: 

/C=RU/O=NanoGrid/OU=hosts/OU=sinp.msu.ru/CN=voms.ngrid.ru
/C=RU/O=NanoGrid/CN=NanoGrid CA

Создаём место для журналов: 

mkdir /var/log/glexec

Проверяем glexec из-под пользователя test:

Создаём пользовательский RFC прокси сертификат с VOMS-расширением. Для выполнения следующих команд у пользователя test в каталоге .globus должен завестись сертификат, выписанный СА, разрешённым в ГридННС, а так же закрытый ключ к нему. 

/opt/glite/bin/voms-proxy-init -voms gridnnn -rfc -hours 24
/opt/globus/globus-4.2.1/bin/grid-proxy-init -key /tmp/x509up_u`id -u` -cert /tmp/x509up_u`id -u`

Если что не так -- пишите.

Проверка: 

export GLEXEC_CLIENT_CERT=/tmp/x509up_u`id -u`
/opt/glite/sbin/glexec /usr/bin/id

Не сработало? См. код возврата $?, syslog (/var/log/messages) и файлы /var/log/glexec/* .

Не помогает? Пошлите нам билет.

Вывелось? Алилуйа, скрипты с 1 по 6й сработали.

3 Настройка gridftp

В файле /etc/grid-security/gsi-authz.conf задать: 

globus_mapping /opt/glite/lib/liblcas_lcmaps_gt4_mapping_gcc32dbg.so lcmaps_callout

Сделать ссылку на модуль авторизации с суффиксом "_gcc32dbg.so" . 

ln -s /opt/glite/lib/liblcas_lcmaps_gt4_mapping.so /opt/glite/lib/liblcas_lcmaps_gt4_mapping_gcc32dbg.so

Убрать из /etc/grid-security/lcmaps/lcmaps-local.db строчку: 

verifyproxy -> vomslocalgroup

Иначе будет проверяться закрытый ключ прокси-сертификата, которого у ftp-сервера не должно быть по определению.

Запустить non-threaded версию gridftp 

/opt/globus/globus-4.2.1/sbin/gcc32dbg/shared/globus-gridftp-server -p 2812 -debug -d ALL

и попробовать что-нибудь с него скопировать командой globus-url-copy, например: 

/opt/globus/globus-4.2.1/bin/globus-url-copy gsiftp://gtb1.grid.kiae.ru:2812/bin/ls ./ls

Не получилось? А не забыли ли Вы создать прокси-сертификат с VOMS расширением, находящемся в не последнем сертификате цепи?

Может оказаться полезным заглянуть в /var/log/gt4_lcas_lcmaps.log .

Всё равно не получилось? Откройте билетик.

Далее пропишите gridftp в сервисе xinetd. 

service gsiftp
{
        instances       = 100
        socket_type     = stream
        wait            = no
        user            = root
        env             += GLOBUS_LOCATION=/opt/globus/globus-4.2.1
        env             += GLOBUS_TCP_PORT_RANGE=20000,25000
        server          = /opt/globus/globus-4.2.1/sbin/gcc32dbg/shared/globus-gridftp-server
        server_args     = -i
        log_on_success  += DURATION
        disable         = no
}

Пути к библиотекам не прописываются, т.к. они уже были прописаны скриптом в файле /etc/ld.so.conf .

Перезапустите xinetd и проверьте его работоспособность. 

/opt/globus/globus-4.2.1/bin/globus-url-copy gsiftp://gtb1.grid.kiae.ru/bin/ls ./ls

Не работает? Откройте билет.

4 Настройка веб-сервисов

В /opt/globus/globus-4.2.1/etc/globus_wsrf_core/server-config.wsdd в разделе <globalConfiguration> включить публикацию доменного имени контейнера: 

<parameter name="publishHostName" value="true"/>

В файлах, лежащих в /opt/globus/globus-4.2.1/etc:

  • globus_delegation_service/factory-security-config.xml
  • globus_delegation_service/service-security-config.xml
  • globus_wsrf_rft/factory-security-config.xml
  • globus_wsrf_rft/security-config.xml
  • globus_wsrf_gram/managed-job-factory-security-config.xml
  • globus_wsrf_gram/managed-job-security-config.xml

прописать в разделе serviceSecurityConfig.authzChain.pdps единственный PDP (т.е. старый нужно стереть): 

        <interceptor name="lcas-lcmaps-pdp:ru.ngrid.security.LcasLcmapsPDP"/>

или с параметрами: 

        <interceptor name="lcas-lcmaps-pdp:ru.ngrid.security.LcasLcmapsPDP">
            <parameter>
                <param:nameValueParam>
                    <param:parameter name="lcasLcmapsLogFile"
                        value="/opt/globus/globus-4.2.1/var/lcas_lcmaps_pdp.log"/>
                    <param:parameter name="lcasConfig"
                        value="/etc/grid-security/lcas/lcas-local.db"/>
                    <param:parameter name="lcmapsConfig"
                        value="/etc/grid-security/lcmaps/lcmaps-java.db"/>
                    <param:parameter name="lcmapsPolicy"
                        value="voms_mapping"/>
                    <param:parameter name="lcasLcmapsLogLevel" value="1"/>
                </param:nameValueParam>
            </parameter>
        </interceptor>

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

<serviceSecurityConfig
        xmlns="http://www.globus.org/security/descriptor/service"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.globus.org/security/descriptor name_value_type.xsd"
        xmlns:param="http://www.globus.org/security/descriptor">

Прописать /etc/grid-security/lcmaps/lcmaps-java.db: 

path = /opt/glite/lib/modules 

good             = "lcmaps_dummy_good.mod"

voms             = "lcmaps_voms.mod"
                   " -vomsdir /etc/grid-security/vomsdir"
                   " -certdir /etc/grid-security/certificates"

localaccount     = "lcmaps_localaccount.mod"
                   "-gridmapfile /etc/grid-security/grid-mapfile"

poolaccount      = "lcmaps_poolaccount.mod"
                   " -override_inconsistency"
                   " -gridmapfile /etc/grid-security/grid-mapfile"
                   " -gridmapdir /etc/grid-security/gridmapdir"   

vomslocalgroup   = "lcmaps_voms_localgroup.mod"
                   "-groupmapfile /etc/grid-security/groupmapfile"
                   "-mapmin 0"                                    

vomspoolaccount  = "lcmaps_voms_poolaccount.mod"
                   "-gridmapfile /etc/grid-security/grid-mapfile"
                   "-gridmapdir /etc/grid-security/gridmapdir"
                   "-do_not_use_secondary_gids"

vomslocalaccount = "lcmaps_voms_localaccount.mod"
                   "-gridmapfile /etc/grid-security/grid-mapfile"
                   "-use_voms_gid"

static_account_mapping:
localaccount -> good

voms_mapping:
vomslocalgroup -> vomslocalaccount
vomslocalaccount -> good | vomspoolaccount
vomspoolaccount -> good

classic_poolaccount:
poolaccount -> good

Как видно, здесь вместо переключения uid-ов в lcmaps-local.db происходит просто подтверждение правильности авторизации.

Исполняемый файл /opt/globus/globus-4.2.1/libexec/globus-gridmap-and-execute заменить на скрипт-пустышку: 

#! /bin/bash
exec "$@"

Оригинальный globus-gridmap-and-execute ещё раз проверяет соответствие локального эккаунта сертификату пользователя. Теоретически можно было бы осуществлять такую дополнительную проверку допуска пользователя с помощью не-setuid-ного glexec. Оставим этот вопрос на усмотрение администраторам конкретных систем.

С помощью команды visudo дописать в конец /etc/sudoers: 

Runas_Alias GLOBUSUSERS = %gridnnn

Defaults>GLOBUSUSERS !requiretty
Defaults>globus !requiretty

globus  ALL=(GLOBUSUSERS) NOPASSWD:     ALL

Здесь в переменной GLOBUSUSERS через запятую перечисляются пользователи, допущенные к запуску через gram, в данном случае - члены юниксовой группы gridnnn.

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

Не получается? Для начала посмотрите в /opt/globus/globus-4.2.1/var/lcas_lcmaps_pdp.log. Если информация в этом файле есть, но её не достаточно, то можно повысить в вышеуказанных файлах *security-config.xml значение переменной lcasLcmapsLogLevel до 5го уровня, тогда библиотеки LCAS и LCMAPS будут выдавать в журнал всё, что могут.

Если авторизация не доходит до модуля LCAS/LCMAPS, т.е. записи в файл журнала не было, то посмотрите в /opt/globus/globus-4.2.1/var/container.log .

Если всё равно творится что-то не понятное, то попробуйте прописать дополнительный отладочный вывод в /opt/globus/container-log4j.properties, например: 

log4j.category.org.globus.delegation.factory.DelegationFactoryService=DEBUG
log4j.category.org.globus.exec=DEBUG
log4j.category.org.globus.transfer=DEBUG
log4j.category.ru.ngrid.security.LcasLcmapsPDP=DEBUG

После перезапуска контейнера указанные классы java начнут выдавать дополнительную информацию.

Не выходит не смотря ни на что? Обратитесь, наконец, в поддержку.