1. Forum
  2. Usenet
  3. COMP.PROTOCOLS.KERBEROS

  • Impersonate Kerberos user on HDFS

    From Philippe de Rochambeau@21:1/5 to All on Thu Apr 11 08:40:40 2024
    Hello,

    Let's say a user has the following rights on HDFS (which are constrained Apache Ranger):

    /prd/a/b/c <- read right
    /prd/a/b/d <- read/write right

    I would like to get a broad picture of his/her complete access rights.

    I could look at the general policies in Apache Ranger and try to figure out which apply to my user, but that's complicated.

    I wonder if there is another way (which ideally could be automated with a script) roughly:

    - impersonate the user as, say, admin, with kinit; e.g. kinit <user>
    - scan all HDFS directories and try to read or write

    Does anyone have suggestions?

    PS I've asked similar questions on the Apache Ranger mailing list, but with no success.

    Many thanks.

    Philippe

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ken Hornstein@21:1/5 to Philippe de Rochambeau on Thu Apr 11 08:24:29 2024
    Copy: [email protected]

    - impersonate the user as, say, admin, with kinit; e.g. kinit <user>
    - scan all HDFS directories and try to read or write

    Does anyone have suggestions?

    In general, your options are:

    - Have access to to user's key/password and generate a ticket for that
    user using kinit. As someone else already noted, this isn't really
    impersonating a user.
    - Have access to the TGS key and generate a TGT for that user (or any user).
    This is generally referred to as "ticket printing". I don't _think_
    the Kerberos distributions come with a utility to do that, but I
    believe there are example programs floating around that do that. I
    have to say that doing so would require access to the TGS key and
    having that outside of your Kerberos database would be extremely
    dangerous as if it was compromised your entire realm would be
    compromised.
    - Have access to the HDFS service key and print a service ticket for that
    user. Again, I don't know if the Kerberos distributions have such
    a utility, but this would be less dangerous (you already have to have
    the HDFS key on disk somewhere). I don't know how Kerberos works with
    HDFS, but if there are multiple service tickets for a HDFS filesystem
    spread across multiple servers that might be complicated.

    --Ken

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Ken Hornstein via Kerberos on Thu Apr 11 07:54:39 2024
    Copy: [email protected] (Philippe de Rochambeau)
    Copy: [email protected] (Ken Hornstein)

    Ken Hornstein via Kerberos <[email protected]> writes:

    - Have access to to user's key/password and generate a ticket for that
    user using kinit. As someone else already noted, this isn't really
    impersonating a user.
    - Have access to the TGS key and generate a TGT for that user (or any user).
    This is generally referred to as "ticket printing". I don't _think_
    the Kerberos distributions come with a utility to do that, but I
    believe there are example programs floating around that do that. I
    have to say that doing so would require access to the TGS key and
    having that outside of your Kerberos database would be extremely
    dangerous as if it was compromised your entire realm would be
    compromised.

    I have in the past written a variation on these two approaches as a
    service that runs directly on the KDC. It accepted authenticated
    requests, applied some sort of complex ACL, and, if the authenticated user making the request passed that ACL, returned a printed ticket (and of
    course logged that this was happening). Since it ran on the KDC, it
    already had access to the keys required to do so. I convinced myself that
    this was acceptably secure.

    (The actual project was for a former employer and I don't have the source,
    and there were some other weird things about that environment that meant I
    was able to maintain separate keytabs for each user without worrying about
    them being invalidated, so I didn't do the full ticket printing approach
    based on the TGS key and just used a bunch of user keytabs since that was
    a lot easier to set up without having to work too hard.)

    The huge drawback of all variations on this type of approach is that you
    lose the ability to distinguish between user accesses based on their own authentication and third-party accesses via ticket printing. That can be
    a real problem if anything goes wrong and you need to figure out whether
    it was really the user or some ticket-printing service, and can be hard to explain (for good reason) in various audit situations. So probably best avoided if you can find a different approach.

    --
    Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simo Sorce@21:1/5 to Ken Hornstein on Thu Apr 11 15:41:57 2024
    To: [email protected] (Philippe de Rochambeau)
    Copy: [email protected]

    On Thu, 2024-04-11 at 08:24 -0400, Ken Hornstein via Kerberos wrote:
    - impersonate the user as, say, admin, with kinit; e.g. kinit <user>
    - scan all HDFS directories and try to read or write

    Does anyone have suggestions?

    In general, your options are:

    - Have access to to user's key/password and generate a ticket for that   user using kinit. As someone else already noted, this isn't really   impersonating a user.
    - Have access to the TGS key and generate a TGT for that user (or any user).   This is generally referred to as "ticket printing". I don't _think_   the Kerberos distributions come with a utility to do that, but I   believe there are example programs floating around that do that. I   have to say that doing so would require access to the TGS key and   having that outside of your Kerberos database would be extremely   dangerous as if it was compromised your entire realm would be   compromised.
    - Have access to the HDFS service key and print a service ticket for that   user. Again, I don't know if the Kerberos distributions have such
      a utility, but this would be less dangerous (you already have to have   the HDFS key on disk somewhere). I don't know how Kerberos works with   HDFS, but if there are multiple service tickets for a HDFS filesystem   spread across multiple servers that might be complicated.

    Modern kerberos implementation additionally allow to impersonate users
    via s4u2self and s4u2proxy services (implementations like AD and
    FreeIPA provide this but standard MIT db does not) without having to
    obtain any secret credential out of services.

    That said, trying to read/write files can have unwanted side effects on
    a large shared file system.

    Posix ACLS are not that hard to interpret but group memberships can get
    tricky to resolve w/o access to how the HDFS serve resolves them (or
    the KDC resolves them in case AD is used the the MS-PAC is used by
    Hadoop to infer group membership of a user by its authentication
    ticket).

    Philippe,
    this is not a trivial problem, may make sense to consider what brought
    you to this point and if there is any better way to handle the problem
    at hand.

    Simo.

    --
    Simo Sorce
    Distinguished Engineer
    RHEL Crypto Team
    Red Hat, Inc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)