Аутентификация с использованием MIT Kerberos KDC в ADB

Шаг 1. Установка и настройка MIT Kerberos KDC

РЕКОМЕНДАЦИЯ

Ознакомиться с основными концепциями Kerberos-аутентификации можно в документации MIT Kerberos.

Ниже показан пример установки и настройки сервера с MIT Kerberos KDC на хосте bds-kerberos.ru-central1.internal с операционной системой CentOS 7. В качестве имени области (realm) используется RU-CENTRAL1.INTERNAL. Обратите внимание, что имя realm Kerberos требуется заполнять в верхнем регистре:

  1. Установите серверные и клиентские пакеты Kerberos:

    $ sudo yum install krb5-libs krb5-server krb5-workstation
  2. Отредактируйте конфигурационные файлы Kerberos, используя редактор vi (или vim).

    • В файле /etc/krb5.conf заполните секции realms, domain_realm и поле default_realm в секции libdefaults:

      $ sudo vi /etc/krb5.conf

      Пример содержимого файла приведен ниже. Обратите внимание, что в полях kdc и admin_server секции realms указывается адрес хоста, на котором устанавливается Kerberos KDC (вместе с номером порта). Вместо доменного имени допускается использовать IP-адрес:

      # Configuration snippets may be placed in this directory as well
      includedir /etc/krb5.conf.d/
      
      [logging]
       default = FILE:/var/log/krb5libs.log
       kdc = FILE:/var/log/krb5kdc.log
       admin_server = FILE:/var/log/kadmind.log
      
      [libdefaults]
       default_realm = RU-CENTRAL1.INTERNAL
       dns_lookup_realm = false
       dns_lookup_kdc = false
       ticket_lifetime = 24h
       renew_lifetime = 7d
       forwardable = true
       default_tgs_enctypes = aes128-cts des3-hmac-sha1 des-cbc-crc des-cbc-md5
       default_tkt_enctypes = aes128-cts des3-hmac-sha1 des-cbc-crc des-cbc-md5
       permitted_enctypes = aes128-cts des3-hmac-sha1 des-cbc-crc des-cbc-md5
      
      [realms]
       RU-CENTRAL1.INTERNAL = {
        kdc = bds-kerberos.ru-central1.internal:88
        admin_server = bds-kerberos.ru-central1.internal:749
        default_domain = ru-central1.internal
       }
      
      [domain_realm]
       .ru-central1.internal = RU-CENTRAL1.INTERNAL
       ru-central1.internal = RU-CENTRAL1.INTERNAL
      
      [appdefaults]
       pam = {
          debug = false
          ticket_lifetime = 36000
          renew_lifetime = 36000
          forwardable = true
          krb4_convert = false
       }
    • В файле /var/kerberos/krb5kdc/kdc.conf замените имя realm в секции realms:

      $ sudo vi /var/kerberos/krb5kdc/kdc.conf

      Пример содержимого файла:

      [kdcdefaults]
       kdc_ports = 88
       kdc_tcp_ports = 88
      
      [realms]
       RU-CENTRAL1.INTERNAL = {
        #master_key_type = aes256-cts
        acl_file = /var/kerberos/krb5kdc/kadm5.acl
        dict_file = /usr/share/dict/words
        admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
        supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
       }
  3. Создайте базу данных Kerberos, используя утилиту kdb5_util. В этой базе будут храниться ключи для всех realm, обслуживаемых текущим Kerberos KDC. Опция -s обозначает создание stash-файла: без ее использования при каждом запуске Kerberos-сервера будет запрашиваться пароль.

    $ sudo kdb5_util create -s

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

    Loading random data
    Initializing database '/var/kerberos/krb5kdc/principal' for realm 'RU-CENTRAL1.INTERNAL',
    master key name 'K/M@RU-CENTRAL1.INTERNAL'
    You will be prompted for the database Master Password.
    It is important that you NOT FORGET this password.
    Enter KDC database master key:
    Re-enter KDC database master key to verify:
  4. Создайте принципала gpadmin/admin с административными правами в базе Kerberos KDC с помощью утилиты kadmin.local:

    $ sudo kadmin.local -q "addprinc gpadmin/admin"

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

    Authenticating as principal root/admin@RU-CENTRAL1.INTERNAL with password.
    WARNING: no policy specified for gpadmin/admin@RU-CENTRAL1.INTERNAL; defaulting to no policy
    Enter password for principal "gpadmin/admin@RU-CENTRAL1.INTERNAL":
    Re-enter password for principal "gpadmin/admin@RU-CENTRAL1.INTERNAL":
    Principal "gpadmin/admin@RU-CENTRAL1.INTERNAL" created.
  5. Определите необходимые разрешения для созданного принципала, отредактировав файл /var/kerberos/krb5kdc/kadm5.acl:

    $ sudo vi /var/kerberos/krb5kdc/kadm5.acl

    Например, приведенная ниже запись файла означает, что каждый принципал в области RU-CENTRAL1.INTERNAL с именем, заканчивающимся на /admin, имеет все административные привилегии, кроме извлечения ключей:

    */admin@RU-CENTRAL1.INTERNAL    *
  6. Запустите сервисы Kerberos, последовательно выполнив следующие команды:

    $ sudo systemctl start kadmin
    $ sudo systemctl start krb5kdc
  7. Для проверки текущего статуса сервисов Kerberos можно воспользоваться командами:

    $ systemctl status kadmin
    $ systemctl status krb5kdc

    Ниже показан пример вывода для первой из команд:

    ● kadmin.service - Kerberos 5 Password-changing and Administration
       Loaded: loaded (/usr/lib/systemd/system/kadmin.service; disabled; vendor preset: disabled)
       Active: active (running) since Thu 2024-05-23 10:02:07 UTC; 41s ago
      Process: 15825 ExecStart=/usr/sbin/_kadmind -P /var/run/kadmind.pid $KADMIND_ARGS (code=exited, status=0/SUCCESS)
     Main PID: 15826 (kadmind)
       CGroup: /system.slice/kadmin.service
               └─15826 /usr/sbin/kadmind -P /var/run/kadmind.pid
  8. Для настройки автоматического запуска сервисов Kerberos после перезагрузки хоста предназначены следующие команды:

    $ sudo systemctl enable krb5kdc.service
    $ sudo systemctl enable kadmin.service

    Ниже приведен результат выполнения первой команды:

    Created symlink from /etc/systemd/system/multi-user.target.wants/krb5kdc.service to /usr/lib/systemd/system/krb5kdc.service.

Шаг 2. Создание принципалов для ADB в MIT Kerberos KDC

В дополнение к принципалу с административными правами (создание которого описано выше) в Kerberos KDC необходимо добавить принципалы для всех пользователей ADB, которые будут проходить Kerberos-аутентификацию. Поскольку обычным пользователям административный доступ к серверу Kerberos в большинстве случаев не требуется, для управления их принципалами рекомендуется использовать утилиту kadmin вместо kadmin.local. В приведенных ниже примерах для демонстрационных целей будет использоваться только один принципал — gpadmin/admin@RU-CENTRAL1.INTERNAL (и соответствующая ему роль в ADB gpadmin/admin).

Еще одним обязательным шагом является добавление в Kerberos KDC сервисного принципала, соответствующего уже не роли, а процессу postgres на мастер-хосте ADB. Этот принципал необходим для корректной интеграции ADB и Kerberos. Имя принципала формируется по следующему шаблону:

postgres/<master_hostname>@<REALM>

где:

  • <master_hostname> — имя мастер-хоста ADB, которое может быть получено путем вызова команды hostname. Если команда возвращает FQDN — следует указать полное имя.

  • <REALM> — имя области (realm) в Kerberos.

Ниже приведен пример добавления сервисного принципала:

$ sudo kadmin.local -q "addprinc postgres/bds-mdw@RU-CENTRAL1.INTERNAL"

Результат:

Authenticating as principal root/admin@RU-CENTRAL1.INTERNAL with password.
WARNING: no policy specified for postgres/bds-mdw@RU-CENTRAL1.INTERNAL; defaulting to no policy
Enter password for principal "postgres/bds-mdw@RU-CENTRAL1.INTERNAL":
Re-enter password for principal "postgres/bds-mdw@RU-CENTRAL1.INTERNAL":
Principal "postgres/bds-mdw@RU-CENTRAL1.INTERNAL" created.

Когда все необходимые принципалы (включая сервисный) созданы, добавьте их в keytab-файл с помощью следующей команды. Впоследствии этот keytab-файл потребуется скопировать на master-host ADB.

$ sudo kadmin.local -q "ktadd -k bds-kerberos.keytab postgres/bds-mdw@RU-CENTRAL1.INTERNAL gpadmin/admin@RU-CENTRAL1.INTERNAL"

Результат:

Authenticating as principal root/admin@RU-CENTRAL1.INTERNAL with password.
Entry for principal postgres/bds-mdw@RU-CENTRAL1.INTERNAL with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:bds-kerberos.keytab.
Entry for principal postgres/bds-mdw@RU-CENTRAL1.INTERNAL with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:bds-kerberos.keytab.
Entry for principal gpadmin/admin@RU-CENTRAL1.INTERNAL with kvno 3, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:bds-kerberos.keytab.
Entry for principal gpadmin/admin@RU-CENTRAL1.INTERNAL with kvno 3, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:bds-kerberos.keytab.

Шаг 3. Настройка мастер-хоста ADB и проверка аутентификации

  1. Установите клиентские библиотеки Kerberos на мастер-хост ADB:

    $ sudo yum install krb5-libs krb5-workstation
  2. Скопируйте содержимое файла /etc/krb5.conf с Kerberos-сервера в одноименный файл /etc/krb5.conf на мастер-хосте ADB.

  3. Скопируйте keytab-файл, созданный ранее на Kerberos-сервере (в нашем примере bds-kerberos.keytab), в директорию /home/gpadmin/ на мастер-хосте ADB и настройте для него владельца и права доступа следующим образом:

    $ sudo chown gpadmin:gpadmin /home/gpadmin/bds-kerberos.keytab
    $ sudo chmod 400 /home/gpadmin/bds-kerberos.keytab
  4. Подключитесь к мастеру ADB под пользователем gpadmin и сохраните путь к keytab-файлу в серверном конфигурационном параметре (GUC) krb_server_keyfile:

    $ sudo su - gpadmin
    $ gpconfig -c krb_server_keyfile -v  '/home/gpadmin/bds-kerberos.keytab'

    Результат:

    20240523:10:50:32:008181 gpconfig:bds-mdw:gpadmin-[INFO]:-completed successfully with parameters '-c krb_server_keyfile -v /home/gpadmin/bds-kerberos.keytab'
  5. Откройте конфигурационную страницу сервиса ADB в ADCM и добавьте в поле Custom pg_hba section запись о Kerberos-аутентификации следующего вида:

    host all all 0.0.0.0/0 gss include_realm=0 krb_realm=RU-CENTRAL1.INTERNAL

    Подробнее про формат, используемый в файле pg_hba.conf для описания Kerberos-аутентификации, описано в разделе Шаг 4. Сопоставление ролей ADB с принципалами Kerberos KDC. Приведенная выше запись разрешает подключение ко всем БД кластера ADB со всех хостов для тех ролей ADB, имена которых совпадают с именами принципалов в области RU-CENTRAL1.INTERNAL. Опция include_realm=0 означает, что имя realm должно исключаться из имен принципалов при их сопоставлении с ролями ADB.

    Для применения изменений нажмите Save и запустите действие сервиса ADB Reconfigure.

    Настройка Kerberos-аутентификации для ADB в ADCM
    Настройка Kerberos-аутентификации для ADB в ADCM
    ПРИМЕЧАНИЕ
    Адрес 0.0.0.0/0 использован в тестовых целях и не рекомендуется для производственных сред.
  6. Создайте роль gpadmin/admin с правами superuser в ADB, которая будет соответствовать принципалу с правами администратора gpadmin/admin@RU-CENTRAL1.INTERNAL:

    $ createuser gpadmin/admin --superuser
  7. Используя команду kinit, создайте тикет на предоставление тикетов (Ticket Granting Ticket, TGT) для принципала gpadmin/admin@RU-CENTRAL1.INTERNAL:

    $ kinit -k -t /home/gpadmin/bds-kerberos.keytab gpadmin/admin@RU-CENTRAL1.INTERNAL
    ПРИМЕЧАНИЕ
    В этом и ниже приведенных примерах при запросе тикета выполняется обращение к ранее созданному keytab-файлу (за счет использования опций -k и -t). На практике keytab-файлы используются чаще всего для сервисных учетных записей. Обычные пользователи могут вызвать kinit без параметров — в этом случае потребуется ввести пароль, указанный при создании соответствующего принципала в Kerberos. Дальнейшие шаги в этом случае выполняются аналогично.
  8. Убедитесь в успешном создании тикета, запустив команду klist:

    $ klist

    Результат содержит выданный тикет:

    Ticket cache: FILE:/tmp/krb5cc_2042
    Default principal: gpadmin/admin@RU-CENTRAL1.INTERNAL
    
    Valid starting       Expires              Service principal
    05/23/2024 15:23:38  05/24/2024 15:23:37  krbtgt/RU-CENTRAL1.INTERNAL@RU-CENTRAL1.INTERNAL
  9. Подключитесь к базе данных adb под ролью gpadmin/admin, используя клиент psql:

    $ psql adb -U "gpadmin/admin" -h bds-mdw
  10. Выполнив подключение, можно вывести текущего пользователя для проверки успешной аутентификации:

    SELECT current_user;

    Результат:

     current_user
    ---------------
     gpadmin/admin
  11. Если выйти из psql и повторно вызвать команду klist, ее результат будет содержать не только TGT, но и сервисный тикет (Ticket Granting Service, TGS), необходимый ADB для реализации протокола аутентификации Kerberos (см. принципал postgres/bds-mdw@RU-CENTRAL1.INTERNAL):

    Ticket cache: FILE:/tmp/krb5cc_2042
    Default principal: gpadmin/admin@RU-CENTRAL1.INTERNAL
    
    Valid starting       Expires              Service principal
    05/23/2024 15:23:38  05/24/2024 15:23:37  krbtgt/RU-CENTRAL1.INTERNAL@RU-CENTRAL1.INTERNAL
    05/23/2024 15:24:03  05/24/2024 15:23:37  postgres/bds-mdw@
    05/23/2024 15:24:03  05/24/2024 15:23:37  postgres/bds-mdw@RU-CENTRAL1.INTERNAL
    ПРИМЕЧАНИЕ
    Наличие дополнительной записи с пустым значением realm (postgres/bds-mdw@) не является ошибкой и связано с изменениями алгоритма обработки host referrals в более поздних версиях krb5, чем 1.6.

Шаг 4. Сопоставление ролей ADB с принципалами Kerberos KDC

В примере, приведенном выше, использован следующий шаблон для добавления записи о Kerberos-аутентификации в файл pg_hba.conf:

host                <database>  <user>  <address>     <auth-method>  [<auth-options>]

Получить подробную информацию по каждому атрибуту этой записи, а также ознакомиться с другими возможными ее формами можно в статье документации PostgreSQL The pg_hba.conf File. Ниже остановимся на опциях (<auth-options>), специфичных для аутентификации на базе протокола GSSAPI, используемого при Kerberos-аутентификации. Комбинируя различные сочетания этих опций, можно настроить наиболее подходящее для ваших целей cопоставление ролей ADB с принципалами Kerberos KDC:

  • include_realm — при значении опции, равном 0, realm исключается из имен принципалов Kerberos перед сопоставлением с ролями в ADB; при значении 1 — включается. Использование значения 0 является небезопасным в случаях, когда на стороне Kerberos KDC используются несколько различных realms (если при этом не заполнена опция krb_realm). Рекомендуется установка include_realm=1 и явное сопоставление ролей с принципалами с помощью опции map.

  • krb_realm — имя области (realm) Kerberos. При заполнении параметра аутентификация допускается только для принципалов из выбранной области.

  • map — имя сопоставления между ролями ADB и принципалами Kerberos, добавленного в файл pg_ident.conf в data-директории мастер-хоста ADB. Сопоставление оформляется в файле pg_ident.conf следующим образом:

    # MAPNAME       SYSTEM-USERNAME         PG-USERNAME
    <map_name>       <principal_name>      <role_name>

    где:

    • <map_name> — имя сопоставления, которое необходимо указать в файле pg_hba.conf: map=<map_name>.

    • <principal_name> — имя принципала Kerberos KDC. Должно включать имя realm (после @) только при значении include_realm=1.

    • <role_name> — имя роли в ADB.

Ниже показан пример настройки кастомного сопоставления ролей ADB с принципалами Kerberos при помощи опции map:

  1. Подключитесь к мастер-хосту под пользователем gpadmin и создайте нового пользователя myadmin:

    $ createuser "myadmin" --superuser;
  2. Перейдите в data-директорию мастера и откройте для редактирования файл pg_ident.conf:

    $ cd /data1/master/gpseg-1
    $ vi pg_ident.conf
  3. Добавьте в файл запись о новом сопоставлении с именем mymap:

    # MAPNAME       SYSTEM-USERNAME         PG-USERNAME
    mymap       gpadmin/admin@RU-CENTRAL1.INTERNAL      myadmin
  4. Откройте конфигурационную страницу сервиса ADB в ADCM и замените ранее введенное значение поля Custom pg_hba section на запись следующего вида:

    host all all 0.0.0.0/0 gss include_realm=1 krb_realm=RU-CENTRAL1.INTERNAL map=mymap

    Обратите внимание, что значение опции include_realm=1. При значении, равном 0, на предыдущем шаге потребовалось бы использовать такую запись:

    # MAPNAME       SYSTEM-USERNAME         PG-USERNAME
    mymap       gpadmin/admin      myadmin
  5. Нажмите Save для сохранения настроек и примените действие Reconfigure к сервису ADB.

    ВНИМАНИЕ
    Запуск действия Reconfigure необходим после каждого изменения файла pg_ident.conf или значения поля Custom pg_hba section.
  6. Удалите существующие тикеты, если они есть, с помощью команды kdestroy:

    $ kdestroy
  7. Используя команду kinit, создайте TGT для принципала gpadmin/admin@RU-CENTRAL1.INTERNAL:

    $ kinit -k -t /home/gpadmin/bds-kerberos.keytab gpadmin/admin@RU-CENTRAL1.INTERNAL
  8. Проверьте возможность подключения к базе данных под пользователем myadmin:

    $ psql adb -U "myadmin" -h bds-mdw
  9. После успешного подключения и выхода из psql запустите команду klist для проверки выдачи сервисного тикета:

    $ klist

    Результат:

    Ticket cache: FILE:/tmp/krb5cc_2042
    Default principal: gpadmin/admin@RU-CENTRAL1.INTERNAL
    
    Valid starting       Expires              Service principal
    05/24/2024 07:21:57  05/25/2024 07:21:57  krbtgt/RU-CENTRAL1.INTERNAL@RU-CENTRAL1.INTERNAL
    05/24/2024 07:22:15  05/25/2024 07:21:57  postgres/bds-mdw@
    05/24/2024 07:22:15  05/25/2024 07:21:57  postgres/bds-mdw@RU-CENTRAL1.INTERNAL

При сопоставлении ролей и принципалов в файле pg_ident.conf допускается использовать регулярные выражения. Например, следующая запись сопоставляет роль myadmin любому принципалу в realm RU-CENTRAL1.INTERNAL, чье имя завершается словом admin:

# MAPNAME       SYSTEM-USERNAME         PG-USERNAME
mymap       /^.*admin@RU-CENTRAL1.INTERNAL$      myadmin

Более подробную информацию о сопоставлении с помощью опции map можно получить в документации PostgreSQL.

Шаг 5. Настройка Kerberos-аутентификации для клиентских приложений

После успешной настройки Kerberos-аутентификации клиентским приложениям для подключения к ADB требуются тикеты. Для формирования тикетов на стороне клиентов используется утилита kinit. Для ее функционирования на хосте, с которого выполняется подключение, необходимо добавить конфигурационный файл krb5-conf и keytab-файл, а также установить клиентские библиотеки Kerberos. Ниже показан пример настройки хоста с операционной системой CentOS 7 и последующего подключения с этого хоста к ADB с использованием psql:

  1. Установите клиентские библиотеки Kerberos на хост, с которого необходимо подключаться к базе данных ADB:

    $ sudo yum install krb5-libs krb5-workstation
  2. Скопируйте содержимое файла /etc/krb5.conf с Kerberos-сервера в одноименный файл /etc/krb5.conf на клиентском хосте.

  3. Скопируйте keytab-файл, созданный ранее на Kerberos-сервере (в нашем примере bds-kerberos.keytab), в домашнюю директорию пользователя (в нашем примере /home/gpadmin/) на клиентском хосте.

  4. Подключитесь к хосту под пользователем, в домашнюю директорию которого перемещен keytab-файл (в нашем примере gpadmin).

    $ sudo su - gpadmin
  5. Запросите TGT для принципала gpadmin/admin@RU-CENTRAL1.INTERNAL с помощью команды kinit:

    $ kinit -k -t /home/gpadmin/bds-kerberos.keytab gpadmin/admin@RU-CENTRAL1.INTERNAL
  6. Проверьте возможность подключения к базе данных под пользователем myadmin, создание которого описано в разделе Шаг 4. Сопоставление ролей ADB с принципалами Kerberos KDC:

    $ psql adb -U "myadmin" -h bds-mdw
  7. После успешного подключения и выхода из psql запустите команду klist для проверки выдачи сервисного тикета:

    $ klist

    Результат:

    Ticket cache: FILE:/tmp/krb5cc_2042
    Default principal: gpadmin/admin@RU-CENTRAL1.INTERNAL
    
    Valid starting       Expires              Service principal
    05/30/2024 13:07:02  05/31/2024 13:07:00  krbtgt/RU-CENTRAL1.INTERNAL@RU-CENTRAL1.INTERNAL
    05/30/2024 13:07:15  05/31/2024 13:07:00  postgres/bds-mdw@
    05/30/2024 13:07:15  05/31/2024 13:07:00  postgres/bds-mdw@RU-CENTRAL1.INTERNAL
Ошибки Kerberos-аутентификации

 

  • При попытке подключения к базе данных ADB под ролью, для которой не найдено соответствующего принципала в Kerberos KDC, возвращается ошибка следующего вида:

    psql: FATAL:  authentication failed for user "gpadmin2/admin": valid until timestamp expired
  • При истечении срока действия выданного ранее тикета формируется ошибка:

    psql: GSSAPI continuation error: Unspecified GSS failure.  Minor code may provide more information
    GSSAPI continuation error: Ticket expired
  • Если сопоставление указанной роли с принципалом выполнено успешно, но для принципала предварительно не сформирован тикет, возвращается ошибка:

    psql: GSSAPI continuation error: Unspecified GSS failure.  Minor code may provide more information
    GSSAPI continuation error: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_2042)

Шаг 6. Настройка JDBC-подключений

Доступ из приложений Java к кластеру ADB, использующему Kerberos MIT KDC, осуществляется с помощью сервиса аутентификации и авторизации Java (Java Authentication and Authorization Service, JAAS). Ниже показан пример настройки и запуска на хосте с операционной системой CentOS 7 простого Java-приложения, которое считывает таблицу из базы данных ADB. Для подключения к ADB используется PostgreSQL JDBC Driver:

  1. Подключитесь к базе данных adb на мастер-хосте и создайте таблицу, которая будет использоваться в Java-приложении:

    CREATE TABLE book_type(id INT PRIMARY KEY, name TEXT UNIQUE NOT NULL)
    DISTRIBUTED REPLICATED;
  2. Добавьте тестовые данные в таблицу:

    INSERT INTO book_type VALUES(1,'novel'),(2,'non-fiction'),(3,'fantastic');
  3. На хосте, где планируется запуск Java-приложения, выполните все действия, описанные в разделе Шаг 5. Настройка Kerberos-аутентификации для клиентских приложений. В конце проверьте, что вы подключены к хосту под пользователем, под которым создавались тикеты (в нашем примере gpadmin):

    $ sudo su - gpadmin
  4. Убедитесь, что на хосте установлена Java:

    $ java -version

    В нашем примере используется Java 11:

    openjdk version "11.0.23" 2024-04-16 LTS
    OpenJDK Runtime Environment (Red_Hat-11.0.23.0.9-2.el7_9) (build 11.0.23+9-LTS)
    OpenJDK 64-Bit Server VM (Red_Hat-11.0.23.0.9-2.el7_9) (build 11.0.23+9-LTS, mixed mode, sharing)
  5. Создайте файл .java.login.config в домашнем каталоге текущего пользователя (в нашем примере /home/gpadmin):

    $ vi .java.login.config

    Содержимое файла показано ниже. Назначение опций подробно описано в документации Class Krb5LoginModule.

    pgjdbc {
      com.sun.security.auth.module.Krb5LoginModule required
      doNotPrompt=true
      useTicketCache=true
      debug=true
      client=true;
    };
  6. Создайте файл с кодом приложения:

    $ vi test.java

    Код приложения показан ниже. В нем выполняется подключение к базе данных adb на мастер-хосте ADB bds-mdw с использованием драйвера PostgreSQL JDBC, после чего из всех строк таблицы book_type считывается и выводится на экран значение столбца name:

    import java.sql.*;
    
    public class Test {
        public static void main(String []args) throws Exception {
    
            Class.forName("org.postgresql.Driver");
            String url = "jdbc:postgresql://bds-mdw:5432/adb?kerberosServerName=postgres&jaasApplicationName=pgjdbc&user=myadmin";
    
            try ( Connection conn = DriverManager.getConnection(url) ){
                try ( Statement statement = conn.createStatement() ) {
                    try (ResultSet rs = statement.executeQuery( "SELECT name FROM book_type") ){
                        while (rs.next())
                            System.out.println( "Get String: " + rs.getString(1));
                    }
                }
            }
        }
    }
    Особенности заполнения URL для JDBC-подключения

     

    Обратите внимание на заполнение URL JDBC-подключения при использовании в кластере ADB Kerberos-аутентификации. URL формируется по следующему шаблону:

    jdbc:postgresql://<master_hostname>:5432/<database_name>?kerberosServerName=postgres&jaasApplicationName=pgjdbc&user=<role_name>

    где:

    • <master_hostname> — имя мастер-хоста ADB, которое может быть получено путем вызова команды hostname. Важно, чтобы это имя совпадало с именем, которое было указано на этапе создания сервисного принципала — в противном случае попытка запуска приложения завершится ошибкой:

      KrbException: Server not found in Kerberos database (7) - LOOKING_UP_SERVER
    • <database_name> — имя базы данных ADB.

    • <role_name> — имя роли в ADB, для которой предварительно настроено сопоставление с принципалом Kerberos. В нашем примере используется пользователь myadmin, создание которого описано в разделе Шаг 4. Сопоставление ролей ADB с принципалами Kerberos KDC.

  7. Загрузите на хост JAR-файл драйвера PostgreSQL JDBC и пропишите путь к нему в переменной окружения CLASSPATH:

    $ export CLASSPATH=.:/home/gpadmin/postgresql-42.7.3.jar
  8. Запустите приложение:

    $ java test.java

    Результат успешного выполнения программы приведен ниже:

    Debug is  true storeKey false useTicketCache true useKeyTab false doNotPrompt true ticketCache is /tmp/krb5cc_2042 isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
    Acquire TGT from Cache
    Principal is gpadmin/admin@RU-CENTRAL1.INTERNAL
    Commit Succeeded
    
    Get String: novel
    Get String: non-fiction
    Get String: fantastic
Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней