I am getting confused between the group and role concept in RedShift. When do we use groups and when are roles used? I was trying to understand it from typical RBAC implementation in other products, but could not match it with how RedShift has implemented it. It looks like it is continuing with PostgreSQL legacy approach
You can't have groups inheriting groups. Roles can inherit other roles. Unless you need tiered hierarchies, groups and users are easier to manage and you can get all the information you need to manage users and groups using the admin views in the amazon redshift utilities https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AdminViews
In Redshift, nobody has permission to see the pg_roles tables and I still haven't found a way out to see which GRANTs are assigned to a given ROLE. Without this, administration of roles is a bit trickier in Redshift.
Related
i'm new-ish to postgresql and wondering what are good patterns for securing objects in your databases.
i've been using MSFT SQL server for most of my career, and like the approach that they have taken to securing databases and objects. Some of the things that I'm missing in postgresql are pre-defined roles at the instance and database levels, such as db_reader and db_writer.
how do you handle security of new objects?
are you limiting peoples ability to create new objects within the database (of course you are, but i'm interested in an approach or patterns), and how are you doing that (using CICD, manually, event-based triggers)
Currently, i'm using a series of event-based triggers and roles to manage new object creation. I don't like it though, and feel like its overly complex, but here's the criteria that I used. I also wanted to avoid others (non-administrators) from having to "escalate their security context", and was hoping to use DEFAULT PRIVILEGES to do this. Unfortunately, that didn't work for me, which I believe is a result of using a hosted solution, and not having a true SUPERUSER role.
Overview
3 default roles
db_reader, read-only access to user-defined databases
db_writer, read-write access to user-defined databases
db_admin, full database access to user-defined databases
Each role inherits the privileges of its “parent”
db_writer inherits all privileges of db_reader
db_admin inherits all privileges of db_writer
Role-based Privileges
Reader role (db_reader)
CONNECT on all user-defined databases
USAGE on all user-defined schemas
SELECT on all user-defined tables, views, and sequences
Writer role (db_writer)
all privileges associated with db_reader
INSERT, UPDATE, DELETE on all user-defined tables and sequences
Admin role (db_admin)
all privileges associated with db_writer
CREATE on all user-defined databases
TRUNCATE on all user-defined tables
Two types of roles
Group Role (users and permissions)
User Role (generally personal or application names)
Privileges are assigned to group roles via GRANT and REVOKE.
User roles inherit privileges from associated group roles and have the LOGIN privilege.
WHAT
I have users that share a database, but have their own schemas. Each user is only able to access objects on their schema - they have been explicitly revoked usage on the schemas that are not theirs.
I am not concerned about a user inappropriately accessing others' schema; however, I would very much like for them not to be able to see the contents or even the existence of the other schema to which they have no access.
WHY
I am aware that this is mostly "cosmetic", but the primary reason for this would be that my users do not have to shift through objects that they cannot access in certain tools (Tableau, DB IDEs, etc) - so I think it does add some practical value.
ATTEMPTS
I've been searching for a solution, but haven't found one that works. For instance, I revoked users' access on information_schema and pg_catalog (I know this is not recommended); however, it had no effect.
Is this at all possible?
It is not possible to limit access to pg_class, pg_attribute, or pg_proc. Therefore what you want can only be achieved by separating each user in their own databases rather than individual schemas.
I am new to Postgres/databases and am thinking of how to design a multi tenant application. I read some of the basic stuff such as schemas supported by Postgres and Row Level Security which is added since Postgres 9.5. So in my case a tenant can have many users. Two different tenants can have users with same name ( Kind of like a hierarchy). So at the top level, I can have a schema for each tenant. And then within each there is a RLS policy for users. Can this be done in Postgres and is this a good option ? With RLS, I will need a role for each user. This will probably blow up since my understanding is that roles are global across schemas.
Or other thing I can think of is that I keep everything in same tables but have policies which honor the user as well as tenant columns in the table. Is this possible in Postgres ? For example, when I add a policy with current_users = "column_name" ,can I add another condition where I add a check that the top level tenant name matches. But where and how is this set, similar to SET ROLE "user"
Bit confused about the right approach to use.
I would go with tenant per database. This is a little easier to backup (per tenant) and a little more secure by default. And a little easier to manage w pgAdmin.
You don't need a db user for each application user to use RLS, but it's probably a good idea.
Set db_user_namespace=true in postgresql.conf to allow per-db usernames. See http://www.postgresql.org/docs/9.5/static/runtime-config-connection.html for caveats
Relational Databases are able to set permissions for users to insert, update, delete, etc by schema or table (e.g. I can allow bob CRUD access to table someschema.XYZ but only allow read access to someschema.FooBar and no access to schema ABC)
Graph databases do not have predefined schemas but have an arbitrary set of node types. Is it possible to set restrictions on a graph database for what a user can access like you do for relational databases or does this granularity not exist in graph databases due to it's nature?
I am specifically looking at Neo4j but if this exists in other examples, then I would like to know.
Neo4j allows you to implement your own SecurityRules. A SecurityRule acts similar to a servlet filter, every request is evaluated with the SecurityRule.
However you have to implement the logic on your own which gives great flexibility but might also cause a serious amount of work.
I've setup our postgresql server with two databases: one production and one training. I would like users to be limited to their true roles in the production database, but be given free reign in the training database.
ie.
Assign one set of roles to a user on one database, and another set of roles to the same user in a different database on the same server.
I figure one way around this would be to create a new "training" role with full access, and then limit this role to just the training database using pg_hba.conf. It's not what I'm hoping for, but is this the only option?
You can GRANT different privileges to different ROLES in different databases, but ROLES are global to the entire server. You might consider using GROUPS (prod_dba group vs dev_dba group) and then assign users to the different groups.