This is what we are handling with Vault outside of Drill, combined with aliasing. James is tracking some of what you've been finding with the credential store but even then we want the single source of auth. We can chat with James on the next Drill stand up (and anyone else who wants to feel the pain).
[image: avatar] Curtis Lambert CTO Email: cur...@datadistillr.com <cur...@datdistillr.com> Phone: + 706-402-0249 [image: LinkedIn]LinkedIn <https://www.linkedin.com/in/curtis-lambert-2009b2141/> [image: Calendly] Calendly <https://calendly.com/curtis283/generic-zoom> [image: Data Distillr logo] <https://www.datadistillr.com/> On Thu, Jan 13, 2022 at 3:29 PM Charles Givre <cgi...@gmail.com> wrote: > Hello all, > One of the issues we've been dancing around is having per-user access > controls in Drill. As Drill was originally built around the Hadoop > ecosystem, the Hadoop based connections make use of user-impersonation for > per user access controls. However, a rather glaring deficiency is the lack > of per-user access controls for connections like JDBC, Mongo, Splunk etc. > > Recently when I was working on OAuth pull request, it occurred to me that > we might be able to slightly extend the credential provider interface to > allow for per-user credentials. Here's what I was thinking... > > A bit of background: The credential provider interface is really an > abstraction for a HashMap. Here's my proposal.... The cred provider > interface would store two hashmaps, one for per-user creds and one for > global creds. When a user is authenticated to Drill, when they create a > storage plugin connection, the credential provider would associate the > creds with their Drill username. The storage plugins that use credential > provider would thus get per-user credentials. > > If users did not want per-user credentials, they could simply use direct > credentials OR use specify that in the credential provider classes. What > do you think? > > Best, > -- C > >
