I have a web software application where I have users with roles in a hierarchy like
Organization -> Team -> project -> folder, each level admin has access to all levels under it, and some other custom permissions for each user. For each level I keep SQL join table with columns like
team_id, user_id, role, permissions
I wonder if it is worth converting this hierarchical system to flat action based permission for each user. Having additional database or tables keeping all actions for each user. Which one is better approach.
Flattening for performance will make it perform better, but require a lot of duplication of data in order to specify all the various permissions.
The best-of-both is to have the hierarchical or RBAC representation be the desired state and translate that into a read-only flattened view on update. This can take a LOT of space though, depending on how fine-grained your permissions get (permissions-per-row can explode this to an unreasonable degree)
Related
Suppose I have 2 users available for the same project. The requirement is to restrict the table access in the same project to one user. How can it be managed it in Bigquery? what kind of access controls to be applied and how?
Thanks in advance.
You can use table level ACLS and set Bigquery roles/bigquery.dataViewer for users on the tables you wish to grant access. More details here https://cloud.google.com/bigquery/docs/table-access-controls-intro
This approach doesn't require creating a separate dataset(as a workaround for table level access) for access control which use to be the case earlier.
Depending on requirements, and the strictness of them, this is what I do:
Grant the user access to a specific table within a dataset by granting the BigQuery Data Viewer role at the table level.
You can do this as follows:
-> Open the table in the console and click Share, then click Add Principal
And to make it easier for the user to navigate the metadata of the table, such as schema, details and preview, I grant them the BigQuery Metadata Viewer role at the dataset level.
You should only do this of course if it is ok for the user to see which other tables within the dataset are there. (they can't see the data in the other tables, just the schema etc)
The advantage is that it will be easier for the user to see the schema and a preview of the data.
More info can be found here:
https://cloud.google.com/bigquery/docs/table-access-controls
I am new to HANA Database. I am just trying to create new User in HANA DB through Eclipse systems editor. I have selected only below role as part of user creation.
sap.hana.xs.lm.roles::Developer
But, it is showing below roles as a result of executing query select role_name from "PUBLIC"."EFFECTIVE_ROLES" where USER_NAME = 'TEST_USER';
ROLE_NAME
PUBLIC
sap.hana.xs.lm.roles::Developer
sap.hana.uis.db::SITE_USER
sap.hana.xs.lm.roles::Display
sap.hana.xs.lm.pe.roles::PE_Display
Why being added other roles to user even not selected?
Roles in SAP HANA are collections of privileges and other roles.
This can lead to a situation where a role contains several other roles, each of which can contain other roles and privileges. That way you have a hierarchy of direct and indirect role- and privileges assignments to a user account.
The system view you query is EFFECTIVE_PRIVILEGES. It’s single most important function is to unroll all roles that have been assigned directly and indirectly (effectively going through the roles-privileges-hierarchy) and to return all those assignments.
This “unrolling” of hierarchical structures is not easy/efficient to do in plain SQL, so this system view provides this special feature as a built-in functionality.
The pre-defined role sap.hana.xs.lm.roles::Developer contains several other roles (as your query result shows).
To double-check you can even review the role definition in the HANA XS repository by navigating to thesap.hana.xs.lm.roles package, as this role is delivered as a design-time artefact.
If you actually only want to see the direct assignments of roles/privileges to a user (or to roles), using system views GRANTED_ROLES or GRANTED_PRIVILEGES will get you that.
Issue: In GCP IAM I have >30 users assigned the pre-defined roles BigQuery Data Viewer and BigQuery Data Editor, and now when I create a new dataset, it's automatically accessible to these 30+ users because of "policy inheritance".
Question: As BQ project admin, I want a newly created dataset only accessible to certain users (a small subset of the 30+ users). What's the best approach to do this? Thanks!
You cannot override the permissions granted at higher leves. So, if you want to restrict access at dataset level, the best approach would be to:
1) Remove the current permissions BigQuery Data Viewerand BigQuery Data Editor from project level.
2) Grant the permissions again, but only at dataset level
This also complies with the recommended best practice of least privilege. Also, if possible, use groups to grant the permissions, as it will be easier to manage.
In addition to this, you could use another project to create the dataset and allow access to the desired subset of users; however, I wouldn't recommend this approach as it only makes more difficult to handle the data and the users with access to them.
What permissions does a service account needs to read from BigQuery __TABLE__ tables? Our scenario is that we want to grant the service account collecting storage stats from our BigQuery projects minimum necessary permissions. Ideally it shouldn't be able to read the data from BQ tables but still it needs to read the __TABLE__ tables from all our datasets. We tried granting metadataViewer permissions but that didn't work, still getting 403.
Ideally it shouldn't be able to read the data from BQ tables but still it needs to read the __TABLE__ tables from all our datasets.
Currently, you cannot grant permissions on tables, views, columns, or rows. A dataset is the lowest level resource that supports access controls in BigQuery.
-- source --
Therefore you will need to grant roles/bigquery.dataViewer to the service account.
You might also need to grant a second permission. Under the hood the code that executes with service account credentials will be making API calls. I don't know the details applicable to your case, but the code will likely use one of the basic REST objects (such as Job object) to make the calls. And will likely need another permission(s) that come under umbrella of roles/bigquery.jobUser or similar role.
The required permissions to query __TABLES__ are the same as to query any regular tables. Thus, the roles/bigquery.dataViewer role viewer at dataset level should be enough.
Since your requirement is to only grant access to this particular table's data, but not to the user generated tables, a possible workaround is to create an authorized view in a separate dataset. The view will have dataViewer access to your current dataset and the user will have dataViewer access to the dataset containing the view.
I'm trying to create users in MarkLogic that have permissions to given databases. I read Security Guide from MarkLogic docs page and found that you can set permissions on given URIs, Collections or functions.
Permissions on collections can help me with marking given collections from database as readable only for given set of users, but still other users can create and modify documents in different collections (or create documents without collections).
For e.g.
I have two databases:
Test
Test2
And two users:
UserTest
UserTest2
How can I set permissions that UserTest will have permissions read/update/insert/execute on database Test and can't modify or read anything database Test2?
Each database can be associated with a dedicated security database. The way you describe your use case ("UserTest will have permissions read/update/insert/execute on database Test and can't modify or read anything database Test2"), you might want to consider dedicated security databases for the Test and Test2 databases.
The other way would be to use different document permissions for roles for the two databases. You can set read/update/insert/execute permissions at document level for a given role at insert time, or change them with xdmp:document-add-permissions() (retains previous permissions) or xdmp:document-set-permissions() (overrides previous permissions) after insert. For instance, you could have a role Test-Reader for database Test and a role Test2-Reader for database Test2, and ensure that (1) your UserTest user has the Test-Reader role (but not the Test2-Reader role), and (2) that all documents inserted into the Test database pair the read capability with the Test-Reader role (but not the Test2-Reader role) etc. (Same for the other capabilities.)
If controlling this explicitly sounds like a lot of work, note that default document permissions can be declared to apply implicitly both at the user and at the role level.
Finally, if you set no permissions at all during document insert (and if no implicit/default permissions are defined at user or role level), only users with the admin role can read/update/insert/execute.
Here's the relevant section for document permissions from the Understanding and Using Security Guide: https://docs.marklogic.com/guide/security/permissions#id_85471
There is no user-level specifications for a database. But keep in mind, a database is not accessible on its own - it is accessible by way of an application(s) which is linked to particular database. Unless you allow people to run eval and allow them to eval against another database, then you application will keep people within the specified database. (Note: ML8 Advanced HTTP server changes this a bit because you can switch database on-the-fly per request- but the rules about being stuck to a single database still stands).
The only other item I think is useful to you is the ability to define which URI prefixes a user can write to, but that does not negate the fact that the application level decided which DB is being accessed.