ACL in Knox

Sergei Tikhomirov

Contents

Configuration
Example

You can restrict cluster service access with an included service-level authorization mechanism. The implementation features a common access control list (ACL) pattern which implies creating whitelists of users, groups, and IPs that are allowed to access certain resources.

Configuration

To configure access for a service, you need to append the Knox topology (knox/conf/topologies/admin.xml) with an authorization provider:

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

You can edit a topology or create a new one via Knox’s REST API. This enables the service-level authorization in general, but lacks specific services and the corresponding whitelists.

For example, consider the following topology with a service definition (knox/conf/topologies/test_topology.xml):

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

To add a whitelist for it, edit the provider section described above the following way:

<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>

where:

[user list] is a comma-separated list of users that are allowed to access the service;
[group list] is a comma-separated list of groups, whose users are allowed to access the service;
[IP list] is a comma-separated list of IP addresses that are allowed to access the service.

IMPORTANT

There are two modes for the ACL. In the default AND mode, to get access, a user has to meet all the described conditions (be in [user list], [group list], and have a whitelisted IP address). In this case, if a user is present in the ACL but is not a member of a whitelisted group, they will be denied access.

The alternative is the OR mode, which requires a user to satisfy only one of the conditions instead of all of them. To change the operating mode, use the following parameter:

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

In the AND mode, you can use the * wildcard to allow anyone access, while in the OR mode, this wildcard denies access to anyone.

Example

The following example demonstrates how to restrict access to the Solr service in ADPS. To restrict access to any other Hadoop service, follow the same steps.

Consider the following topology for the Solr service:

<?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>

Append it with an ACL authorization provider as discussed in the configuration:

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

This is done on a kerberized cluster, so a Kerberos principal name works.

Try accessing the Solr service via the Knox proxy:

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

With a correct configuration, you will get an HTML page returned. Otherwise, there will be the 403 Forbidden error.

Found a mistake? Seleсt text and press Ctrl+Enter to report it