[HDDS-1901] Fix Ozone HTTP WebConsole Authentication

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.4.0
• Fix Version/s: 0.4.1
• Labels: pull-request-available
• Target Version/s: 0.4.1
• Sprint: Done
• Assignee: Xiaoyu Yao
• Reporter: Vivek Ratnavel Subramanian
• Created: 03/Aug/19 06:50
• Updated: 06/Aug/19 20:06
• Resolved: 06/Aug/19 19:30

Description

This was found during integration testing where the http authentication is enabled but anonymous can still access the ozone http web console like scm:9876 or om:9874. This can be reproed with the following configurations added to the ozonesecure docker-compose.

CORE-SITE.XML_hadoop.http.authentication.simple.anonymous.allowed=false

CORE-SITE.XML_hadoop.http.authentication.signature.secret.file=/etc/security/http_secret

CORE-SITE.XML_hadoop.http.authentication.type=kerberos

CORE-SITE.XML_hadoop.http.authentication.kerberos.principal=HTTP/[e-mail]

CORE-SITE.XML_hadoop.http.authentication.kerberos.keytab=/etc/security/keytabs/HTTP.keytab

CORE-SITE.XML_hadoop.http.filter.initializers=org.apache.hadoop.security.AuthenticationFilterInitializer

After debugging into the KerberosAuthenticationFilter, the root cause is the name of the keytab does not follow the AuthenticationFilter tradition. The fix is to change 

hdds.scm.http.kerberos.keytab.file to hdds.scm.http.kerberos.keytab and
hdds.om.http.kerberos.keytab.file to hdds.om.http.kerberos.keytab

I will also add an integration test for this under ozonesecure docker-compose.

Issue Links

• links to: GitHub Pull Request #1228