HDDS-11454. Ozone Ranger Integration in docker

[kumaab]

What changes were proposed in this pull request?

• Adds support for ozone integration with ranger in the compose/ozone subpath. (Support in compose/ozonesecure to follow soon)
• Enables OM container to come up with ranger plugin enabled and authorizer class set to: org.apache.ranger.authorization.ozone.authorizer.RangerOzoneAuthorizer
• Adds support for ranger containers to come up along with ozone containers sharing a common network.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-11454

How was this patch tested?

In docker containers on local machine with published binaries for ozone using version 1.4.1 and ranger version 2.6.0
The changes in the PR were copied over to ozone-1.4.1/compose/ozone/ and the following commands were run:

chmod +x ranger-plugin-setup.sh
./ranger-plugin-setup.sh

docker compose -f docker-compose.yaml -f docker-compose.ranger.yaml up -d

The following were verified:

• Verified all ranger and ozone containers come up with docker compose.
• Ranger plugin for Ozone is enabled once OM container starts. (attached logs to jira)
• Verified restart of ozone-om-1 container, plugin installation is skipped!
• Policies are synced to the plugin.
• The plugin is able to download policies, tags and roles to etc/ranger/dev_ozone/policycache
• Verified authorization for hadoop and om user, attaching audits seen in Ranger UI:
• No relevant errors are seen in ozone-om-1 container.
• ./test-ranger.sh passes with exit code 0.

[adoroszlai]

Thanks @kumaab for the patch.

Unfortunately CI requires amd64 images.

dependency failed to start: container ranger-postgres exited (255)

exec /usr/local/bin/docker-entrypoint.sh: exec format error

We can still commit it with the test disabled.

[adoroszlai]

Thanks @kumaab for updating the patch.

@smengcl can you please review and test this?

[adoroszlai]

I'll change this to use the property ranger.version in HDDS-12461.

[smengcl]

It looks to me ozone-dist is misbehaving during mvn clean install -Pdist -DskipTests -e -Dmaven.javadoc.skip=true.

It looks to be interpreting some variables in enable-ozone-plugin.sh to an unwanted hard-coded path. The following is found in the script under target/

$ pwd
/Users/smeng/repo/ozone-pr/hadoop-ozone/dist/target/ozone-2.0.0-SNAPSHOT
$ rg "/Users/smeng/repo/ozone-pr/hadoop-ozone/dist"
compose/ozone/ranger-plugin/enable-ozone-plugin.sh
24:        if [ -f "/Users/smeng/repo/ozone-pr/hadoop-ozone/dist/pom.xml" ]
26:            propertyValue=`grep "^${propertyName}[ \t]*=" /Users/smeng/repo/ozone-pr/hadoop-ozone/dist/pom.xml | awk -F= '{  sub("^[ \t]*", "", $2); sub("[ \t]*$", "", $2); print $2 }'`
64:if [ "/Users/smeng/repo/ozone-pr/hadoop-ozone/dist" = "." ]
67:elif [ "/Users/smeng/repo/ozone-pr/hadoop-ozone/dist" = ".." ]
113:PROJ_INSTALL_DIR=`(cd /Users/smeng/repo/ozone-pr/hadoop-ozone/dist ; pwd)`

(This causes the OM initial Ranger plugin setup upon startup to fail. Which causes NPE in RangerOzonePlugin and can crash OM.)

Take line 24 for example, in the source code it should be:

        if [ -f "${file}" ]

My question: Why would this bash script file even be changed during dist copy? Is there some maven plugin accidentally changing this? Do you happen to have any clue @adoroszlai ?

---

My steps for verification:

1. Switch to PR branch, launch maven build
2. Switch to compose/ozone/, install plugin and start Docker compose cluster

./ranger-plugin-setup.sh
docker compose -f docker-compose.yaml -f docker-compose.ranger.yaml up -d

3. Log in to Ranger Web UI http://localhost:6080/ with credentials: admin/rangerR0cks!
4. Attempt to use CLI:

ozone fs -ls ofs://om/

[adoroszlai]

It looks to me ozone-dist is misbehaving during mvn clean install -Pdist -DskipTests -e -Dmaven.javadoc.skip=true.

It looks to be interpreting some variables in enable-ozone-plugin.sh to an unwanted hard-coded path. The following is found in the script under target/

Nice catch @smengcl.

This is intentional, but sometimes surprising. We use maven-resources-plugin to replace properties (filtering=true) while copying these files. Unfortunately file is also a built-in property, so ${file} needs to be used as $file, or renamed to something else, like ${f} or ${arg}.

ozone/hadoop-ozone/dist/pom.xml

Lines 154 to 172 in e805c15

	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-resources-plugin</artifactId>
	<executions>
	<execution>
	<id>copy-compose-files</id>
	<goals>
	<goal>copy-resources</goal>
	</goals>
	<phase>compile</phase>
	<configuration>
	<outputDirectory>${basedir}/target/compose</outputDirectory>
	<resources>
	<resource>
	<directory>src/main/compose</directory>
	<filtering>true</filtering>
	</resource>
	</resources>
	</configuration>
	</execution>

BTW, some of these files look like are copied from Ranger as is. In the long run we should get them from Ranger, instead of duplicating them in Ozone. That would also avoid this problem.

[kumaab]

Thanks @smengcl and @adoroszlai for the above analysis.
I introduced enable-ozone-plugin.sh to override the enable-ozone-plugin.sh that comes pre-packaged with the plugin, as the former is simpler and a relatively minified version compared to the latter for unsecure docker dev. I'll try to see if I can use the original and not do an override to help with this issue.

[smengcl]

Nice catch @smengcl.

This is intentional, but sometimes surprising. We use maven-resources-plugin to replace properties (filtering=true) while copying these files. Unfortunately file is also a built-in property, so ${file} needs to be used as $file, or renamed to something else, like ${f} or ${arg}.

ozone/hadoop-ozone/dist/pom.xml

Lines 154 to 172 in e805c15

	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-resources-plugin</artifactId>
	<executions>
	<execution>
	<id>copy-compose-files</id>
	<goals>
	<goal>copy-resources</goal>
	</goals>
	<phase>compile</phase>
	<configuration>
	<outputDirectory>${basedir}/target/compose</outputDirectory>
	<resources>
	<resource>
	<directory>src/main/compose</directory>
	<filtering>true</filtering>
	</resource>
	</resources>
	</configuration>
	</execution>

BTW, some of these files look like are copied from Ranger as is. In the long run we should get them from Ranger, instead of duplicating them in Ozone. That would also avoid this problem.

Thanks @adoroszlai for confirming my suspicion. It is indeed unfortunate that ${file} and ${basedir} fell into the built-in properties and occurrences are thus unintentionally replaced.

ref: https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html

Another possible workaround would be to specifically exclude this file from filtering, something like (diff attached below, NOT TESTED, might need further tinkering):

diff --git i/hadoop-ozone/dist/pom.xml w/hadoop-ozone/dist/pom.xml
index d02d5f8d48..a06f4441b3 100644
--- i/hadoop-ozone/dist/pom.xml
+++ w/hadoop-ozone/dist/pom.xml
@@ -165,8 +165,18 @@
               <resources>
                 <resource>
                   <directory>src/main/compose</directory>
+                  <excludes>
+                    <exclude>ozone/ranger-plugin/enable-ozone-plugin.sh</exclude>
+                  </excludes>
                   <filtering>true</filtering>
                 </resource>
+                <resource>
+                  <directory>src/main/compose</directory>
+                  <includes>
+                    <include>ozone/ranger-plugin/enable-ozone-plugin.sh</include>
+                  </includes>
+                  <filtering>false</filtering>
+                </resource>
               </resources>
             </configuration>
           </execution>

I saw other folks doing this as well, e.g. :

https://github.com/thingsboard/thingsboard/blob/61254a68507c6def8c055b7b3ae70413c456a4ac/pom.xml#L226-L242

[adoroszlai]

Good point @smengcl, probably better to add exclusion for all files coming from Ranger. This will make it easier to update them later e.g. from Ranger 2.7 or 3.0. (Until we use it from Ranger directly.)

[adoroszlai]

Thanks again @kumaab for the patch. I suggest closing this, and filing follow-up if you have any improvement ideas over the existing implementation (7af8c44).