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

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

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development