PostgreSQL

Configuring PostgreSQL Integration for Veza Lifecycle Management

Overview

The Veza integration for PostgreSQL enables automated user provisioning, access management, and deprovisioning capabilities. This integration allows you to synchronize identity information, manage group memberships, and automate the user lifecycle from onboarding to offboarding.

Action Type	Description	Supported
SYNC_IDENTITIES	Synchronizes identity attributes between systems, with options to create new identities and update existing ones.	✅
MANAGE_RELATIONSHIPS	Controls entitlements such as group memberships for identities.	✅
DEPROVISION_IDENTITY	Safely removes or suspends access for identities.	✅
DELETE_IDENTITY	Deletes the identity name, specifically the unique identifier associated with it.	✅

This document outlines the steps to enable PostgreSQL integration for use in Lifecycle Management, including supported actions and relevant notes. See Supported Actions for more details.

Enabling Lifecycle Management for PostgreSQL

Prerequisites

1. You will need administrative access in Veza to configure the integration and grant API scopes in PostgreSQL.

2. Ensure you have an existing PostgreSQL integration in Veza or add a new one for use with Lifecycle Management.

3. Verify your PostgreSQL integration has completed at least one successful extraction.

4. Ensure the integration service account has the required privileges. The service account must be a superuser to manage other PostgreSQL roles, including those with elevated privileges:

   ALTER ROLE veza_service WITH SUPERUSER CREATEROLE;

   Note: SUPERUSER is required because Lifecycle Management may need to create or modify roles with SUPERUSER, BYPASSRLS, or other elevated privileges. Without SUPERUSER, the service account cannot manage roles with privileges equal to or greater than its own.

Configuration Steps

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for or create a PostgreSQL integration

3. Check the box to Enable usage for Lifecycle Management

Configure the extraction schedule to ensure your PostgreSQL data remains current:

1. Go to Veza Administration > System Settings

2. In Pipeline > Extraction Interval, set your preferred interval

3. Optionally, set a custom override for PostgreSQL in the Active Overrides section

To verify the health of the Lifecycle Management data source:

1. Use the main Veza navigation menu to open the Lifecycle Management > Integrations page or the Veza Integrations overview

2. Search for the integration and click the name to view details

3. In the Properties panel, click the magnifying glass icon under Lifecycle Management Enabled

Supported Actions

PostgreSQL can serve as a source for identity information in Lifecycle Management Policies. User identity details are synchronized from PostgreSQL, with changes propagated to connected systems.

PostgreSQL can also be a target for identity management actions, based on changes in another external source of truth or as part of a workflow.

The integration supports the following Lifecycle Management Actions:

Sync Identities

Primary action for user management (creating or updating users):

• Entity Types: PostgreSQL User

• Create Allowed: Yes (New user identities can be created if not found)

• SQL Command: CREATE ROLE {username} WITH LOGIN PASSWORD 'password' [attributes]

Note: In PostgreSQL's architecture, users are roles with the LOGIN privilege. When Veza creates a user, it uses CREATE ROLE with the LOGIN attribute. This is functionally identical to PostgreSQL's CREATE USER command, which is simply an alias for CREATE ROLE ... WITH LOGIN.

The following attributes can be synchronized:

PostgreSQL User Attributes

Property	Required	Type	Description
name	Yes	String	The role name (unique identifier). Must follow PostgreSQL naming rules: start with a letter or underscore, contain only alphanumeric characters and underscores, maximum 63 bytes.
is_super_user	No	Boolean	Grants SUPERUSER privilege. Superusers bypass all permission checks and have full control over the database. Use with extreme caution.
can_create_db	No	Boolean	Grants CREATEDB privilege, allowing the role to create new databases.
can_create_role	No	Boolean	Grants CREATEROLE privilege, allowing the role to create, alter, and drop other roles. Cannot modify superusers unless the role is also a superuser.
can_initiate_streaming_replication	No	Boolean	Grants REPLICATION privilege. Allows the role to connect in replication mode and access Write-Ahead Log (WAL) streams. Typically used for replication standby servers.
can_by_pass_all_row_level_security	No	Boolean	Grants BYPASSRLS privilege. Allows the role to bypass Row-Level Security (RLS) policies on all tables. Use when the role needs unrestricted access to data regardless of RLS policies.

Manage Relationships

Controls relationships between users and PostgreSQL groups:

• Supported Relationship Types:

  • PostgreSQL Group: Manages group membership for users

• Assignee Types: PostgreSQL User

• Supports Removing Relationships: Yes

Technical details:

• Adding a user to a group: GRANT {group} TO {user}

• Removing a user from a group: REVOKE {group} FROM {user}

• Group memberships use PostgreSQL's role inheritance system, where users inherit permissions from their assigned groups

Deprovision Identity

Disables a user's ability to authenticate to PostgreSQL while preserving the role and its attributes:

• Entity Type: PostgreSQL User

• Action: Revokes the LOGIN privilege (equivalent to ALTER ROLE {username} WITH NOLOGIN)

• Removes All Group Memberships: Yes (user is removed from all PostgreSQL groups)

• Preserves:

  • The role itself (can be re-enabled later)

  • All role attributes (SUPERUSER, CREATEDB, CREATEROLE, REPLICATION, BYPASSRLS)

  • Ownership of database objects (tables, schemas, etc.)

  • Granted permissions on database resources

Use case: Temporary offboarding or leave of absence where you may need to restore access later.

Security note: A deprovisioned superuser cannot log in but retains SUPERUSER status. If the role is re-enabled without updating attributes, it will have full superuser privileges. Consider using a Sync Identities action to revoke SUPERUSER before deprovisioning if this is a concern.

Delete Identity

Permanently removes a user role from PostgreSQL:

• Entity Type: PostgreSQL User

• Action: Drops the role from the database (equivalent to DROP ROLE {username})

• Impact: Complete and irreversible removal of the role

Important limitations:

• Will fail if the user owns database objects: PostgreSQL prevents dropping roles that own schemas, tables, functions, or other database objects. PostgreSQL will return an error: role "username" cannot be dropped because some objects depend on it

• Will fail if the user has granted permissions: If the role has granted permissions to other roles or is referenced in default privileges, the drop will fail

• Will fail if referenced in policies: Row-level security policies or other database policies that reference the role must be removed first

Note: Unlike some database systems, PostgreSQL allows dropping roles with active connections, but the operation will still fail if any of the above dependencies exist.

Recommended workflow:

1. Use Deprovision Identity first to revoke LOGIN and remove group memberships

2. Verify the user has no owned objects, granted permissions, or policy references

3. Use Delete Identity only when permanent removal is required

Alternative for users with dependencies: PostgreSQL administrators can manually run REASSIGN OWNED BY {username} TO {new_owner} followed by DROP OWNED BY {username} before triggering deletion through Veza, or handle the deletion entirely through PostgreSQL.