Azure Cosmos Db for PostgreSQL
You manage azure cosmos db for postgresql access by setting up database roles and network rules. Teams grant read or write rights to group roles and add individual users to them. Most teams start by sharing one broad admin role across several apps and engineers. When roles are too broad, anyone with a key can alter tables or pull sensitive data. How roles work in azure cosmos db for postgresql This service runs on the standard Postgres engine with distributed table features. You control data
Azure RBAC + PostgreSQL Access Control: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You manage azure cosmos db for postgresql access by setting up database roles and network rules. Teams grant read or write rights to group roles and add individual users to them. Most teams start by sharing one broad admin role across several apps and engineers. When roles are too broad, anyone with a key can alter tables or pull sensitive data.
How roles work in azure cosmos db for postgresql
This service runs on the standard Postgres engine with distributed table features. You control data access using built-in database roles and object privileges. Instead of granting rights to each person, admins create group roles for specific job duties. When a new engineer joins the team, you add their account to the group role.
Every database also includes a special role called PUBLIC that includes every user on the system. By default, this special role lets all users log in and create temporary tables. It also lets users run functions and procedures unless the object owner removes those rights. In Postgres 15 and newer, regular users cannot create new objects in the public schema by default. On older upgraded databases, admins must manually remove public creation rights from that default schema.
For read-only needs, admins grant the SELECT privilege on tables, views, or materialized views. You can grant read rights on a whole table or limit them to specific columns. Keep in mind that the SELECT privilege also allows users to export data out. When teams add new tables later, default privilege rules only cover objects made by one specific role.
Why native roles leave gaps in daily operations
Native roles do a good job of deciding who can log in to the cluster. They also block unauthorized users from reading or writing to tables they should not touch. Still, database privileges are static rules that stay active all day and night. Once a user logs in with a valid role, the database trusts every query they send.
Azure RBAC + PostgreSQL Access Control: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Column rules are hard to maintain when schemas change every week across many distributed nodes. If you grant table read access, a developer can run a bulk export of customer emails. They can also pull phone numbers, card numbers, or national IDs in plain text. Native roles cannot rewrite matched fields in query results on the fly based on context. They also cannot require a peer review before a user runs one risky update command.
Managing query risks without static credentials
Sharing database passwords in chat apps or local files creates a major risk for engineering teams. Even when you rotate passwords, someone still holds standing rights to run destructive commands. Teams need a way to check each query in flight rather than trusting a static role. By separating human identity from raw database keys, you gain control over every single command.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Can I limit read access to specific columns in Azure Cosmos DB for PostgreSQL?
Yes, the standard Postgres SELECT privilege lets you grant read access to specific columns on a table. Still, managing column grants across dozens of changing tables takes a lot of manual work.
What permissions does every new database user get by default?
Every user inherits rights from the special PUBLIC role when you create their account. By default, this includes the right to connect, make temporary tables, and run functions.
Why can users still create tables in my public schema after an upgrade?
Databases created before Postgres 15 allowed all users to create objects in the public schema. When you upgrade an older database, an admin must manually revoke that creation right from PUBLIC.