We are using AWS PostgreSQL RDS and we would like to limit some accounts to be accessed from a specific set of CIDR. Since RDS is managed DBMS by AWS we do not have access to pg_hba.conf.
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html
By checking the CREATE ROLE and USER DDL in PG, it does not seem to be an option.
https://www.postgresql.org/docs/current/sql-createrole.html
https://www.postgresql.org/docs/current/sql-createuser.html
you can try to write you own rules via function/procedure checking, using SELECT inet_server_addr() (just keep in mind that it works only with non-localhost connections).
Also some useful functions here (like local/remote ip/port): https://www.postgresql.org/docs/9.4/functions-info.html
Related
I have windows based application that communicates with PostgreSQL (installed on another Windows Server). Currently I use connection string with username and password (user is configured on PostgreSQL DB). Is it possible to somehow change it so that in connection automatically logged to windows User is passed and somehow configured on Postgres so that he can have access to db?
I need to do it in order to add some audit: when record is added to table I would like to add information in separate column about which user inserted it (it would be great to do it on :) thanks!
Answer depends on environment. If you work in domain and all your user do (careful on permissions), then it is possible on server side (see https://www.postgresql.org/docs/12/auth-methods.html)
But if not, then the easiest approach is to include information in insert call, or call function which performs insert, but takes user info as an argument.
If your server is on Windows too, the natural thing to do would be to use SSPI (Windows single-sign-on) authentication. For that, use sspi authentication in pg_hba.conf and add SSPI configuration parameters after that.
We are trying to write a powershell script that can read data from an Aurora PostgreSQL cluster. We want to do this from within the Lambda dotnetcore3.1 environment. I don't see any documentation anywhere in google space that gives any pointers on what program/cmdlet/module could be used. In Windows, we can use an ODBC driver and/or psql. However, neither of these seem to exist in the Lambda ecosystem.
Has anyone successfully made a connection to PostgreSQL in Lambda using powershell? If so, what did you use to do it?
I reckon the core question is how to get your Lambda function access to the RDS PostgreSQL instance, which I can think of 2 approaches:
Use AWS Secretes Manager to securely database username and password, retrieve them via AWS SDK during Lambda execution: https://aws.amazon.com/blogs/security/how-to-securely-provide-database-credentials-to-lambda-functions-by-using-aws-secrets-manager/
Use RDS IAM Authentication to grant Lambda function access to RDS: https://aws.amazon.com/blogs/database/iam-role-based-authentication-to-amazon-aurora-from-serverless-applications/
Personally I'd recommend approach #2, though in the past I only used approach #1.
I'm in the early stages of a web project which requires a database. Until now, I've managed to get away with using an SQLite database locally for development and a PostgreSQL database running on AWS RDS in "production" (mainly just for alpha testers). I haven't really had any state in the database that I couldn't just blow away and re-seed whenever necessary.
However, I'm now at the point in my project where I'm going to have state in the production database that I can't easily reproduce via seeding in my local SQLite database. So I've decided to create another development database that I create via a script which just takes the last snapshot of my production database and creates a production database. I've managed to get this script running with some degree of success...
But I'm having difficulty connecting to this development database in my local development environment. Each time I try to connect, I timeout. Most of the resources on Amazon seem to indicate that this is likely a security group issue. The security group corresponding to my database currently has these inbound settings (security group erased, but it is the group listed as my RDS security group):
Is there something obviously wrong here? How do I set up my security groups such that I can connect to this development database on my local machine?
The source shouldn't be set to the same security group, but rather whatever source you'll be connecting from. You can use 0.0.0.0/0 to enable traffic from any source.
I am following the tutorial on how to set up and connect a PostgreSQL server on AWS found HERE
When I try to sign in on workbench, I get this message:
At first I thought it was because my DB instance was not available yet, so I waited until it finished backing up. This did not seem to work as I am still getting this message. I will appreciate assistance on this.
Have you created a secutiry group and allow databases connection port?
From the docs:
VPC Security Group(s): Select Create New Security Group. This will
create a security group that will allow connection from the IP address
of the device you are currently using, to the database created.
I am aware that I have to add the IP addresses of remote hosts in pg_hba.conf file and restart the PostgreSQL server for changes to take effect.
But I would like to get a list of hosts currently allowed for the host-based authentication, directly from the server that is already running.
Similar to how I can get the max_connections setting using show max_connections;, I would hypothetically imagine it to be something like show hosts; or select pg_hosts(); (neither really exists).
Is this possible?
EDIT: I understand exposing the hosts would present a security risk. But how about the psql utility invoked directly in the database server's terminal? Does it have a special command to get the list?
The psql command at the terminal has no permission to get the list. Only the PostgreSQL database does.
The best way to do this (if you really must) is to create a PL/PerlU function which reads the pg_hba.conf and parses it, and returns the information in the way you want it. You could even build a management system for the pg_hba.conf with such functions (reloading the db might get interesting but you could do this with a LISTEN/NOTIFY approach).
Note, however, if you do this, your functions have a security footprint. You would probably want to just revoke permission to run the functions from public, grant access to nobody, and thus require users be superusers in order to run the functions. I would personally avoid exposing such critical information to the db unless there was a compelling reason but I could imagine that there could be cases where it might be helpful on balance. It is certainly dangerous territory however.