Footnote: once #2422 is merged there will be precedent for the mentioned,
enhanced kind of storage plugin that establishes connections per Drill user.
The Phoenix plugin will do this when impersonation is switched on. But note
that it makes no use of creds providers, being entirely based on
Thanks to everyone who shared the thoughtful observations about security
architecture. This email is just to add some specific feedback on the
credential provider proposal below.
Only the in-memory PlainCredentialsProvider wraps a Map of credentials.
The other implementations only ever
GRANT and REVOKE implicitly assumes that the database is king of access
control. That works when the database owns the data.
In the modern world where data storage is separated from query, it is truly
painful to have to manage permissions for each analysis and each query tool
and nearly
Hi @All,
for me, that uses Drill with a kerberized hadoop cluster and Ranger as central
Access-Control-System i would love to have an Ranger-Plugin for Drill, but i
would assume a lot Drill users just spins up a cluster in front of S3 or azure.
So why not using a generic approach with GRANT
Hey All,
Other members of the Hadoop Ecosystem rely on external systems to handle
permissions: Ranger or Sentry. There is probably something different in the
AWS world.
As you look into security, you'll see that you need to maintain permissions
on many entities: files, connections, etc. You need
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
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
