Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Some deployments would like to avoid needing kerberos principals for taking administrative actions with the HBase shell, substituting their own authentication. The HBase shell is a regular HBase client, which could run anywhere, and cannot be trusted with simple authentication or impersonation of arbitrary users.

      Other Hadoop ecosystem components have a service process registered in cluster configuration afforded the elevated privilege of impersonation. For HBase, this could be a trusted administration server that would reside at a fixed location, could be trusted to impersonate, with the shell modified to optionally proxy administrative commands through it.

      Carried over from HBASE-2016 without comment.

        Activity

        Hide
        Mikhail Antonov added a comment -

        However, does someone else see the end users to authenticate directly via LDAP, while HBase/Zk/... services authenticate between each other via kerberos - as practical usecase? Or, most people would just do cross-realm trust for Kerberos to accept users from corporate LDAP and that's it?

        Show
        Mikhail Antonov added a comment - However, does someone else see the end users to authenticate directly via LDAP, while HBase/Zk/... services authenticate between each other via kerberos - as practical usecase? Or, most people would just do cross-realm trust for Kerberos to accept users from corporate LDAP and that's it?
        Hide
        Mikhail Antonov added a comment -

        Yes, I agree that's not really HBase feature, more like very custom requirement which has to be implemented as a custom solution.

        Show
        Mikhail Antonov added a comment - Yes, I agree that's not really HBase feature, more like very custom requirement which has to be implemented as a custom solution.
        Hide
        Gary Helmling added a comment -

        Rewording my comment from HBASE-2016 in order to capture it here as well:

        I don't really see a proxy for HBase shell, which would need its own kerberos credentials and would have to perform its own authentication of clients, as core HBase functionality. Instead it's like putting a proxy in place in order to circumvent security. Instead, I think the best direction for HBase would be to invest effort to support pluggable authentication of clients at the RPC layer, using the same mechanisms under development for Hadoop.

        However, if someone does want to invest the effort to support an impersonating proxy for shell commands as an optional service, that is completely up to them, as long as it does not undermine core security.

        Show
        Gary Helmling added a comment - Rewording my comment from HBASE-2016 in order to capture it here as well: I don't really see a proxy for HBase shell, which would need its own kerberos credentials and would have to perform its own authentication of clients, as core HBase functionality. Instead it's like putting a proxy in place in order to circumvent security. Instead, I think the best direction for HBase would be to invest effort to support pluggable authentication of clients at the RPC layer, using the same mechanisms under development for Hadoop. However, if someone does want to invest the effort to support an impersonating proxy for shell commands as an optional service, that is completely up to them, as long as it does not undermine core security.

          People

          • Assignee:
            Unassigned
            Reporter:
            Andrew Purtell
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Development