Are replication and privileged administrator memberships Azure-managed defaults in PostgreSQL 17 Flexible Server?

Ron Lohr 0 Reputation points
2026-11-04T02:43:25.2466667+00:00

I am validating the security baseline of a newly provisioned Azure Database for PostgreSQL Flexible Server running PostgreSQL 17.11. The server is a primary with high availability disabled and no read replicas. The configured password administrator is referred to below as server_admin; this is a generic placeholder, not a resource-specific name.

Observed role attributes

  • server_admin: LOGIN=yes; INHERIT=yes; CREATEROLE=yes; CREATEDB=yes; BYPASSRLS=yes; SUPERUSER=no; REPLICATION=no.
  • replication: LOGIN=yes; INHERIT=yes; REPLICATION=yes; SUPERUSER=no; CREATEROLE=no; CREATEDB=no; BYPASSRLS=no.

Equivalently, the configured administrator has LOGIN, INHERIT, CREATEROLE, CREATEDB, BYPASSRLS, NOSUPERUSER, and NOREPLICATION. The replication role has LOGIN, INHERIT, REPLICATION, NOSUPERUSER, NOCREATEROLE, NOCREATEDB, and NOBYPASSRLS.

Observed memberships

  • Granted role azure_pg_admin; member server_admin; grantor azuresu; ADMIN=yes; INHERIT=yes; SET=yes.
  • Granted role pg_read_all_settings; member server_admin; grantor azuresu; ADMIN=yes; INHERIT=yes; SET=yes.
  • Granted role pg_read_all_stats; member server_admin; grantor azuresu; ADMIN=yes; INHERIT=yes; SET=yes.
  • Granted role pg_stat_scan_tables; member server_admin; grantor azuresu; ADMIN=yes; INHERIT=yes; SET=yes.
  • Granted role pg_use_reserved_connections; member replication; grantor azuresu; ADMIN=no; INHERIT=yes; SET=yes.

Microsoft documentation establishes part of this behavior:

The available documentation does not appear to define the complete PostgreSQL 17.11 role-and-membership contract above. Could a Microsoft Azure Database for PostgreSQL product or engineering representative provide authoritative confirmation of the following?

  1. Is the configured password-administrator role provider-created with exactly the listed attributes, including BYPASSRLS, NOSUPERUSER, and NOREPLICATION?
  2. Is the replication role provider-created by default on a newly provisioned PostgreSQL 17.11 primary with high availability disabled and no read replicas? If so, are its exact listed positive and negative attributes expected?
  3. Are all five membership rows provider-created with exactly the listed grantor and ADMIN, INHERIT, and SET options?
  4. Which of these role names, attributes, memberships, grantors, and membership options are controlled or reserved by the Azure service?
  5. Can a customer administrator create an equivalent role or lookalike, alter either role's attributes, or grant equivalent memberships and options? Please distinguish technically possible customer changes from provider-controlled state.
  6. Are these properties established during initial provisioning, and are they preserved or recreated during maintenance, restore, and PostgreSQL minor-version upgrades?
  7. Are there version-specific, topology-specific, or lifecycle-specific differences that affect PostgreSQL 17.11?
  8. Is there official documentation or authenticated control-plane metadata that describes this complete contract and is stable enough for strict, fail-closed commissioning validation?

A Microsoft-authored product/engineering response or an official documentation reference is required for this use case. An AI-generated summary or an inference from the role names alone is not sufficient. No remediation or access to a specific server is requested.

Azure Database for PostgreSQL
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-11-04T02:44:28.6733333+00:00

    Only server_admin and its membership in azure_pg_admin are documented Azure-managed defaults; the complete replication role, monitoring grants, BYPASSRLS, and membership-option inventory shown cannot currently be treated as a documented or stable PostgreSQL 17.11 provisioning contract.

    What Microsoft documents

    Item Status
    server_admin created during provisioning Documented default
    server_admin attributes LOGIN, NOSUPERUSER, INHERIT, CREATEDB, CREATEROLE Documented
    server_admin -> azure_pg_admin Documented default
    azuresu reserved for Microsoft control-plane operations Documented
    server_admin BYPASSRLS Not documented as a universal default
    replication role with LOGIN REPLICATION Its existence is recognized, but these exact attributes are not documented as a provisioning contract
    Three pg_* monitoring memberships Not documented as universal administrator defaults
    replication -> pg_use_reserved_connections Consistent with documented service behavior, but not documented as universally provisioned
    Exact ADMIN, INHERIT, and SET options or azuresu grantor Not documented as stable defaults

    Flexible Server documentation names three Azure defaults: azure_pg_admin, azuresu, and the administrator selected during provisioning. It explicitly says the administrator belongs to azure_pg_admin, does not belong to azuresu, and that only Microsoft uses the superuser role for managed operations.^1^

    The documented administrator attributes are:

    • LOGIN
    • NOSUPERUSER
    • INHERIT
    • CREATEDB
    • CREATEROLE

    That documentation does not include NOREPLICATION or BYPASSRLS in the administrator’s guaranteed attribute list.^2^

    BYPASSRLS

    For PostgreSQL 16 and later, Microsoft documents that the newer role model permits roles to be created with BYPASSRLS. This establishes that the privilege is supported; it does not establish that every newly provisioned PostgreSQL 17 administrator must itself have that attribute.^1^

    Therefore, the observed server_admin BYPASSRLS may be service-provisioned behavior, but it is not presently documented as a universal PostgreSQL 17.11 invariant.

    replication and reserved connections

    The Azure Backup support matrix expects that a replication role can already exist on the restore target and says the resulting “role already exists” error can be ignored. It also documents restore errors involving grants of pg_use_reserved_connections.^3^

    This supports the conclusion that both objects participate in managed-server behavior, but it does not define:

    • Whether every new non-HA primary receives replication.
    • Whether that role must have both LOGIN and REPLICATION.
    • Whether it must inherit pg_use_reserved_connections.
    • The exact membership options or grantor.

    For PostgreSQL 17 Flexible Server, reserved_connections is read-only, fixed at 5, and reserves slots for roles holding pg_use_reserved_connections.^4^ That documents the purpose of the built-in privilege, not which Azure role must receive it.

    Implication for commissioning validation

    Do not fail commissioning solely because these undocumented details differ:

    • server_admin BYPASSRLS
    • replication attributes
    • Administrator monitoring memberships
    • replication -> pg_use_reserved_connections
    • ADMIN, INHERIT, or SET option combinations
    • The recorded grantor

    A strict baseline can safely assert only the documented subset, including the administrator’s documented attributes and membership in azure_pg_admin. Record the other values as observational telemetry or drift warnings rather than fail-closed requirements.

    If contractual confirmation of the complete inventory is required, open an Azure Support request and ask whether these fields are guaranteed across new provisioning, maintenance, and minor-version updates. No public Microsoft document currently supplied here defines that complete PostgreSQL 17 role-and-membership contract.

    References

    1. Access management in Azure Database for PostgreSQL flexible server
    2. Manage users in Azure Database for PostgreSQL flexible server
    3. Support matrix for Azure Database for PostgreSQL- Flexible Server vaulted backup
    4. Connections and Authentication / Connection Settings (postgresql-17)
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.