ACL в Knox

Сергей Тихомиров
Содержание

Вы можете ограничить доступ к сервисам кластера с помощью встроенного механизма авторизации сервисного уровня. Данный механизм реализован на основе списков контроля доступа (Access Control Lists, ACL). ACL подразумевает наличие "белых списков" пользователей, групп и IP-адресов, которым разрешен доступ к ресурсу.

Настройка

Для настройки доступа к сервису требуется добавить в топологию Knox (knox/conf/topologies/admin.xml) провайдер авторизации:

<provider>
    <role>authorization</role>
    <name>AclsAuthz</name>
    <enabled>true</enabled>
</provider>

Отредактировать топологию или создать новую можно с помощью REST API сервиса Knox. Данный провайдер позволяет использовать авторизацию на уровне сервиса и не более. Для дальнейшей настройки потребуется создать "белый список" для сервиса.

Например, существует следующая топология с определением сервиса (knox/conf/topologies/test_topology.xml):

<topology>
   <name>test-topology</name>
   <service>
      <role>WEBHDFS</role>
      <url>http://localhost:50070/webhdfs</url>
   </service>
</topology>

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

<provider>
    <role>authorization</role>
    <name>AclsAuthz</name>
    <enabled>true</enabled>
    <param>
        <name>webhdfs.acl</name>
        <value>[user list];[group list];[IP list]</value>
    </param>
</provider>

где:

  • [user list] — перечисленные через запятую пользователи, которым разрешен доступ;

  • [group list]-- перечисленные через запятую группы, членам которых разрешен доступ;

  • [IP list] — перечисленные через запятую IP-адреса, с которых разрешен доступ.

ВАЖНО

ACL может работать в двух режимах. В режиме по умолчанию — AND — для получения разрешения пользователь должен удовлетворять всем трем условиям (быть одновоременно в [user list] и [group list], при этом имея разрешенный IP-адрес). В данном случае, если имя пользователя есть в [user list], но он не является членом разрешенных групп, то доступ ему будет запрещен.

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

<param>
    <name>webhdfs.acl.mode</name>
    <value>OR</value>
</param>

В режиме AND вы можете использовать подстановочный знак * для разрешения доступа всем, в то время как в режиме OR этот же подстановочный знак запрещает доступ.

Пример

Следующий пример демонстрирует, как ограничить доступ к сервису Solr кластера ADPS. Ограничение доступа к любому другому сервису Hadoop выполняется идентичным образом.

  1. Например, существует следующая топология для Solr:

    <?xml version="1.0" encoding="UTF-8"?>
<topology>
   <uri>https://stikhomirov-adps.ru-central1.internal:8443/gateway/solr</uri>
   <name>solr</name>
   <timestamp>1733257387073</timestamp>
   <generated>true</generated>
   <redeployTime>0</redeployTime>
   <gateway>
      <provider>
         <role>authentication</role>
         <name>HadoopAuth</name>
         <enabled>true</enabled>
         <param>
            <name>config.prefix</name>
            <value>hadoop.auth.config</value>
         </param>
         <param>
            <name>hadoop.auth.config.cookie.domain</name>
            <value>ru-central1.internal</value>
         </param>
         <param>
            <name>hadoop.auth.config.cookie.path</name>
            <value>/</value>
         </param>
         <param>
            <name>hadoop.auth.config.kerberos.keytab</name>
            <value>/etc/security/keytabs/HTTP.service.keytab</value>
         </param>
         <param>
            <name>hadoop.auth.config.kerberos.name.rules</name>
            <value>DEFAULT</value>
         </param>
         <param>
            <name>hadoop.auth.config.kerberos.principal</name>
            <value>HTTP/stikhomirov-adps.ru-central1.internal@AD.RANGER-TEST</value>
         </param>
         <param>
            <name>hadoop.auth.config.simple.anonymous.allowed</name>
            <value>false</value>
         </param>
         <param>
            <name>hadoop.auth.config.token.validity</name>
            <value>1800</value>
         </param>
         <param>
            <name>hadoop.auth.config.type</name>
            <value>kerberos</value>
         </param>
      </provider>
      <provider>
         <role>identity-assertion</role>
         <name>Default</name>
         <enabled>true</enabled>
      </provider>
   </gateway>
   <service>
      <role>SOLR</role>
      <url>http://stikhomirov-adps.ru-central1.internal:8983/solr/</url>
   </service>
</topology>

  2. Добавьте в неё провайдер авторизации, как описано в настройке:

    <provider>
    <role>authorization</role>
    <name>AclsAuthz</name>
    <enabled>true</enabled>
    <param>
        <name>solr.acl</name>
        <value>s_tikhomirov_krb1;*;*</value>
    </param>
</provider>

    В данном случае работа производится на керберизованном кластере, поэтому имя принципала Kerberos подходит в качестве имени пользователя.

  3. Попробуйте получить доступ к сервису Solr через Knox:

    $ curl -ik --negotiate -u : -X GET https://stikhomirov-adps.ru-central1.internal:8443/gateway/solr/solr

  4. При верно описанных условиях в ответе вы получите код HTML-страницы. В противном случае вернется код ошибки 403 Forbidden.

Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней