Sentry privileges on Spark - apache-spark

I have a question regarding Spark privileges with Sentry on Hadoop cluster.
First, some background -
I'm using CDH version 5.13.2
ACL sync on HDFS is enabled
Impersonation disabled
Grant on database level and for specific cases gants on URI
Scenario
There are two databases, db_a and db_b. In db_a there is a view which selects from table which is defined in db_b.
I granted privilege for a specific user with read access (grant select) on db_a.
In Beeline/Impala/Hue the behavior is as expected:
show databases shows only db_a
when user's query the view in db_a it works perfect even the user don't have any privilege on db_b.
The problem with Spark SQL:
When the same user is trying to access the view in db_a, it's failed as user don't have access to db_b.
Again, same query with same user works fine in Hive/Impala.
Is there any configuration or workaround to resolve the problem?

Related

Row Level Access Control on Apache Cassandra

What I am trying to achieve is similar to what DSE Cassandra provide here, but on Apache Cassandra: Setting up Row Level Access Control (RLAC)
I've tried using Materialized View and grant SELECT permission on the created view to a specific role, but when I'm trying to access the view it returns an unauthorized error asking me to grant SELECT permission on the origin table.
Is there really no way to achieve this?

Cassandra sstableloader authorization

Small question about Cassandra 3.0.8. Not datastax.
is it possible to grant/revoke permissions for users, who use sstableloader? For now, user only authenticate in Cassandra and can update any table...
There is no specific authentication for just sstableloader. However you can
Create separate set of users/roles for each and every table within the keyspace.
In other words, there could be different users with different set of permissions on each and every table.
Here is an example on how to create user and define permission at table level
GRANT SELECT PERMISSIONS ON keyspace1.table1 TO USER1;
GRANT MODIFY PERMISSIONS ON keyspace1.table2 TO USER1;
So in the above example USER1 has select permission on table1 while update permission on table2. So you can authorize who gets to have update access on table1 but not if it comes from sstableloader or cql or application code.
Here is the reference for roles and permissions https://docs.datastax.com/en/cql/3.1/cql/cql_reference/grant_r.html

Authentication for Virtuoso HTTP POST/PUT

I tried to execute an INSERT statement for an RDF triple in Virtuoso using its web-based SPARQL endpoint (http://localhost:8890/sparql/):
INSERT DATA
{
GRAPH <http://my.graph>
{
<http://test.com/someid> <http://namespace.ref#someVar> 123
}
}
but I got
Virtuoso 42000 Error SR186:SECURITY: No permission to execute procedure DB.DBA.SPARQL_INSERT_DICT_CONTENT with user ID 107, group ID 107
I was able to run the same statement through my DB editor that uses a JDBC driver on port 1111, using the DBA login.
The web interface/service insert was successful after I ran the following as a DBA through port 1111:
grant execute on DB.DBA.SPARQL_INSERT_DICT_CONTENT to "SPARQL";
grant execute on DB.DBA.SPARQL_INSERT_DICT_CONTENT to SPARQL_UPDATE;
However, I would like to revoke those privileges from user SPARQL, which I understand is associated with the web interface, and send HTTP POST/PUT/DELETE requests with supplied user credentials using digest authentication. Is that possible and how? I went to this page of the manual but it was empty.
The OP's goal is discussed in the new location of the manual page they originally tried to visit. (More details are on the product site, than are reproduced below.)
Virtuoso reserves the path /sparql-auth/ for a SPARQL service supporting authenticated SPARUL (a/k/a SPARQL-Update). This endpoint allows specific SQL accounts to perform SPARUL over the SPARQL protocol. To be allowed to log in via SQL or ODBC and update physical triples, a user must be granted SPARQL_UPDATE privileges. To grant this role:
Go to the Virtuoso administration UI, i.e., http://host:port/conductor
Log in as user dba
Go to System Admin → User Accounts → Users
Click the Edit link
Set User type to SQL/ODBC Logins and WebDAV.
From the list of available Account Roles, select SPARQL_UPDATE and click the >> button to add it to the right-hand list.
Click the Save button.
This procedure, which I picked up here, worked for me:
Logged in as dba, under System Admin > User Accounts,
grant SPARQL_UPDATE to "SPARQL"

Does CouchDB replication require an admin of the system or the database admin?

I setup some security on a database called test.
The user with the name "user_test" is not a system Admin. Therefore, he has the admin permissions and member permissions on the test database.
As stated :
Creating design documents is restricted to admins, and if the replication is triggered without admin credentials, writing the design documents during replication will fail and be recorded as doc_write_failures. If you have admins, be sure to include the credentials in the replication request:
Since they are referring to the design docs, I was thinking about the database admin.
Therefore, when I try to setup a replication document in the _replicator database, the connection "hang" with the "user_text" credentials.
If I use my system admin, the replication get triggered instantly.
So my question :
In the target or source property, do I need to put the system admin credential or the database admin credentials?
Update
Setting up a replication using a system admin gets triggered automatically (good).
If I use a database admin, nothing occurs. Not even an error. Wich is kind of weird because it works on other pcs...
For you information, after testing and fixing some errors, I figured out that you can use non-system admin for replication.
Even tough, I had some problems with my replications that were having errors. I ended up clearing the corrupted documents in the _replicator and restarting each instance and everything got fixed.

Is there any way to use Linux integrated security for MongoDb?

We have c# web app connecting MongoDb deployed on Linux server. The idea is to use single designated Linux account for our web application to login and connect into MongoDb. As I understand from what I read, MongoDb does not support integrated security at all by default, it supposed to have its own user database with passwords, and no roles too, right? If so, I wonder if there is any separate third-party framework/tool or something that helps me use desired approach?
Other than that, if you know good online article regarding best practices to implement Security for Mongo in web applications, like where and how to store users and encrypted passwords etc., please give me a link.
please give me a link.
I did some security documentation a few months ago for MongoDB and it can be found here, this should be your starting point.
As I understand from what I read, MongoDb does not support integrated security at all by default, it supposed to have its own user database with passwords, and no roles too, right?
Up until MongoDB 2.2, authentication and authorisation is all local.In 2.2, there is limited RBAC (Role Based Access), i.e. two roles "read" and "write", with "write" being able to do everything on that database, i.e. admin.
Things will change in 2.4 with new roles:
name description of privilege
read ability to query data in any collection in the database, other than 'system.users', and also ability to run any command without an A or W attribute
readWrite everything permitted by 'read' privilege, and also the ability to insert, update,
or remove documents or indexes in any collection other than 'system.users', and also the ability to run any command without an A attribute
userAdmin ability to read and write the 'system.users' collection
dbAdmin ability to run admin commands affecting a single database; see list below
serverAdmin ability to run admin commands affecting the entire database server; Can only be set on admin database; see discussion
clusterAdmin admin commands for a cluster of shards or a replica set; Can only be set on admin database
as documented here. This enhanced RBAC will be available in all versions of MongoDB from 2.3.2 (development build) and the next production release, 2.4.0.
With MongoDB 2.4, there will also be the ability to use Kerberos for authentication, however, this delegated authentication will only be available in the Enterprise builds, which require a Commercial Support contract for us.
There is currently nothing within MongoDB that enforces password complexity but obviously in 2.4 with Kerberos, the KDC can do this. You will manually have to ensure (through your internal password policy etc) that users realise the issues of using non-complex passwords and re-using the same passwords on multiple devices. Assuming you are running 2.2, all logins, passwords and permissions for MongoDB access are stored in the system.users collection under each database. Here is the exact link to the documentation that you should read.

Resources