Hadoop Common
  1. Hadoop Common
  2. HADOOP-8554

KerberosAuthenticator should use the configured principal

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 1.0.0, 2.0.0-alpha, 3.0.0
    • Fix Version/s: None
    • Component/s: security

      Description

      In KerberosAuthenticator we construct the principal as follows:

      String servicePrincipal = "HTTP/" + KerberosAuthenticator.this.url.getHost();
      

      Seems like we should use the configured hadoop.http.authentication.kerberos.principal instead right?

      I hit this issue as a distcp using webhdfs://localhost fails because HTTP/localhost is not in the kerb DB but using webhdfs://eli-thinkpad works because HTTP/eli-thinkpad is (and is my configured principal). distcp using Hftp://localhost with the same config works so it looks like this check is webhdfs specific for some reason (webhdfs is using spnego and hftp is not?).

        Activity

        Hide
        Laxman added a comment -

        About to raise another issue and noticed.
        We are also facing this problem in 2.0.1

        Seems like we should use the configured hadoop.http.authentication.kerberos.principal instead right?

        I don't find this property in trunk. I think it's better to pass principal from the user of KerberosAuthenticator.

        Any different opinion?

        Show
        Laxman added a comment - About to raise another issue and noticed. We are also facing this problem in 2.0.1 Seems like we should use the configured hadoop.http.authentication.kerberos.principal instead right? I don't find this property in trunk. I think it's better to pass principal from the user of KerberosAuthenticator. Any different opinion?
        Hide
        Rajiv Chittajallu added a comment -

        tying to figure out SPN for multihomed systems is a matter of policy. For clusters, it simpler to generate it from the uri or make rDNS a requirement.

        Show
        Rajiv Chittajallu added a comment - tying to figure out SPN for multihomed systems is a matter of policy. For clusters, it simpler to generate it from the uri or make rDNS a requirement.
        Hide
        Eli Collins added a comment -

        I don't find this property in trunk. I think it's better to pass principal from the user of KerberosAuthenticator.

        See AuthenticationFilterInitializer, this config name is constructed via the PREFIX variable.

        Show
        Eli Collins added a comment - I don't find this property in trunk. I think it's better to pass principal from the user of KerberosAuthenticator. See AuthenticationFilterInitializer, this config name is constructed via the PREFIX variable.
        Hide
        Alejandro Abdelnur added a comment -

        @Eli, the line of code you point out happens on the client side, if your URL is of the form http://foohost/.... then the principal is created as 'HTTP/foohost'. There is a JIRAs to add support for kerberos name rules HADOOP-8518. IMO this JIRA is invalid.

        Show
        Alejandro Abdelnur added a comment - @Eli, the line of code you point out happens on the client side, if your URL is of the form http://foohost/ .... then the principal is created as 'HTTP/foohost'. There is a JIRAs to add support for kerberos name rules HADOOP-8518 . IMO this JIRA is invalid.
        Hide
        Eli Collins added a comment -

        You're right, thanks for the explanation, I didn't realize the principal config was server-side only. Also, the reason I hit this with webhdfs and not hftp is that hftp doesn't support SPNEGO.

        Show
        Eli Collins added a comment - You're right, thanks for the explanation, I didn't realize the principal config was server-side only. Also, the reason I hit this with webhdfs and not hftp is that hftp doesn't support SPNEGO.
        Hide
        Laxman added a comment -

        @Eli & Alejandro, IMHO this issue is valid.

        On server side, there is a provision to configure a principal like "web/hadoop@MYREALM"
        Here second component "hadoop" refers to my cluster/domain identifier but not the canonical hostname.
        Also, Kerberos doesn't mandate to use hostname only.

        So, I think this is a valid issue. Correct me if I'm missing something here.

        Please refer to ZOOKEEPER-1467 for similar issue of client side hardcoding.

        Show
        Laxman added a comment - @Eli & Alejandro, IMHO this issue is valid. On server side, there is a provision to configure a principal like "web/hadoop@MYREALM" Here second component "hadoop" refers to my cluster/domain identifier but not the canonical hostname. Also, Kerberos doesn't mandate to use hostname only. So, I think this is a valid issue. Correct me if I'm missing something here. Please refer to ZOOKEEPER-1467 for similar issue of client side hardcoding.
        Hide
        Alejandro Abdelnur added a comment -

        Laxman, isn't HADOOP-8518 addressing your concern?

        Show
        Alejandro Abdelnur added a comment - Laxman, isn't HADOOP-8518 addressing your concern?

          People

          • Assignee:
            Unassigned
            Reporter:
            Eli Collins
          • Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development