Can't create a PostgreSQL Superuser role to get an Application installed and running - postgresql

I want to install an application (Odoo) that uses PostgreSQL, but it needs you create a superuser Role to allow the aplication process instalation create its own database. I just created an Azure PostgreSQL database (PaaS), but the user it creats is not a Superuser, and can't create a superuser role. Is there a way to get my admin user a Superuser?

To explain the users and roles a little better for Azure Database for PostgreSQL:
By default, when a server is created we have the following 3 roles defined, which you can also see when you run SELECT rolname FROM pg_roles; –
azure_pg_admin
azure_superuser
server admin login – the admin login the user created the server with – which by default is a member of azure_pg_admin.
Ours is a managed PaaS service and Microsoft is the azure_superuser. We don’t grant superuser privileges to the user.
With that as baseline, there is at least one role (user) at any given time that is part of azure_pg_admin group i.e. server admin login. This user can create databases, create custom roles and customize privileges, and create additional users that are member of azure_pg_admin. A user is either a part of this group or not. Any user outside this group will not have those privileges.
Hope that helps answer your question.
Saloni

When we postgres as service then we cannot be superuser but can enable extensions allowed
Azure console => Azure Database for PostgreSQL flexible server => => Server parameters => azure.extensions => => Save

Related

How can I add pg_monitor role to a postgresql user on heroku

I'm trying to set up a Datadog PostgreSQL integration that requires a user with pg_monitor role and SELECT permission on pg_stat_database as described on their own documentation.
My database is currently hosted on Heroku and it seems the default user doesn't have SUPERUSERpermissions because, when I try to apply the above role and permission to a "monitor" user I have the following error message:
ERROR: must have admin option on role "pg_monitor"
So I'm looking for some way of:
grant the necessary permissions to that user without being a superuser
get superuser access on Heroku Postgres (what I think is not possible)
Someone has ever faced this issue? There is a way to handle this case?
I had to open a ticket asking the Heroku CS team to apply the "pg_monitor" role to my user. They've granted the role and now everything is working fine

Using AWS RDS Postgresql database with a login from secrets manager

So, I've been looking around for more details, but can't find it.
I have a AWS RDS Postgresql cluster. In the typical sense, when I want to add a login to my database, I use the
create user xxxx with password 'yyy'
then I grant that user access to the tables and other rights.
Now, I tried to add another user with secrets manager linked to this RDS database.
I'm not sure what to do next....should that new user I only created in secrets, appear in the login for the database, because I don't see it? How would we grant access to the tables and other things for that user?

How to set or change role upon login automatically in postgres?

I have an existing postgres 11 database called host_db and we have an existing application called host_app that has been using this database for a long time. This service uses superuser host_app_user to connect to database and do all the transactions. Hence, all the database objects are owned by this database superuser.
Now, we want to create db_admin superuser role too in our database whose credentials will be maintained by Vault. But to not mix up database ownership, I was thinking that whenever db_admin logs in to the database, it assumes the role of host_app_user. That way whatever changes the logged admin does will all be done as host_app_user.
My question is: Is there a way I can automatically set the role of logged in user in postgres at the time of logging in?
Use:
alter role db_admin set role host_app_user;
db_admin's role will be set to host_app_user on login.
Note though that db_admin must be a member of host_app_user.
I think the answer is no. But you could do this:
grant db_admin to host_app_user;
Then host_app_user will have all the permissions that db_admin has.

Setting session_replication_role for GCP Cloud SQL

I am trying to run SET session_replication_role = 'replica'; in a GCP Cloud SQL Postgres 9.6 instance, however I'm encountering this error ERROR: permission denied to set parameter "session_replication_role" even if the postgres user is a cloudsql admin user. Do I have to spin up my own self managed instance to solve the problem or is there a way around it?
Unfortunately, it is not connected with the service is in Beta or not, you can't set session_replication_role in GCP Cloud SQL.
You need to have superuser privileges to do that operation, but GCP Cloud only allows to cloudsqlsuperuser privileges. It's features as follows:
When you create a new Cloud SQL for PostgreSQL instance, the default postgres user is already created for you, though you must set its password.
The postgres user is part of the cloudsqlsuperuser role, and has the following attributes (privileges): CREATEROLE, CREATEDB, and LOGIN. It does not have the SUPERUSER or REPLICATION attributes.
You can find much more information in this blog post.
From what I was looking at, since the service is currently in Beta, there are still some features that are not available, such as that. Therefore we would need to wait a bit more for Google to realease the final version of their product.
We also encountered same issue . This is because postgres user does not have Replication permission.
To resolve this issue:
a) Login with postgres user
b) Since postgres user has Create role permission. Now create a new user with below command:
CREATE USER <YOUR_USER> WITH PASSWORD '<YOUR_PASSWORD>' CREATEDB CREATEROLE REPLICATION IN GROUP cloudsqlsuperuser;
replace <YOUR_USER> with your user name and <YOUR_PASSWORD> with password.
c) Login with newly created user and run
SET session_replication_role = 'replica';
if you see response SET then you are good to go

Postgres ACL for Schemas

I'm not a DBA and I have got some questions around access controls for schemas. Let's say I have a Postgres server running a several databases. The admin user is postgres. I have another user tmpUser with which I could log in to the remote server using pgadmin3 client.
I now create a database called myDatabase which is by default owned by the postgres user. I then use my admin client to remotely log in to this myDatabase using the tmpUser account.
I now create a new schema inside this myDatabase called myDbSchema. I created a new role called myDbRole and did a grant usage, grant all on myDatabase, myDbSchema to the myDbRole.
The question now is how should I control access to this myDatabase. I tried to log in to the remote server using the tmpUser and when I tried to execute select * from myTable where myTable is a table in myDatabase, it came back with a permission denied sql message. So I changed the owner of the table to the tmpUser which I really do not want to!
Is there a guide or something on how I should go about creating and organizing roles with schemas in postgres?
It is not entirely clear what your problem is (for instance, what is role "myDbRole" for, is that a group role (NOLOGIN) or a user role (LOGIN)?) but in general you could follow this pattern of permission management:
Create a specific role to own a database and all or most of the objects in it. This should be a group role (NOLOGIN) for security reasons. Do not use the postgres user; if you need to login as that role often to do regular database work, you are doing something wrong. Any superuser (or other user role that has that role granted to it) can "impersonate" that owner role using SET SESSION AUTHORIZATION to do necessary maintenance. In a production environment this should be hardly ever necessary; during development you might want to consider making the role with LOGIN permission for ease of use.
The owner creates all the schemas, tables, views, functions, etc. that you need for your application. By default, all of those objects are only available to the database owner, with the exception of functions.
Define a number of group role profiles, each having specific requirements of the database. You could have, for instance sales_staff, product_managers, accounting and senior_management for a company, or web_user, web_admin, app_developer and app_manager for a web site. The database owner then GRANTs access to the database (CONNECT), schemas (USAGE), tables, views and functions (EXECUTE), as needed. I usually REVOKE ALL ON FUNCTION x() TO public, for security reasons.
Assign group role membership to user roles, as needed: GRANT sales_staff TO jane. The user roles should have LOGIN INHERIT such that they can log in and inherit the permission of group roles that they are a member of. That includes the permission to connect to a database and usage rights on schemas. Note that a single user role can have membership in multiple group roles.
Lastly, update your pg_hba.conf file to enable remote access to the database.