Installation Accounts and Permissions

Policy uses separate database logins, dependency users, and Kubernetes workload identities. These accounts serve different purposes and cannot replace one another. Protegrity Provisioned Cluster (PPC) administrators prepare dependency users before installation. Database operators prepare credentials for PostgreSQL inside the Policy stack.

Use this reference with installation preparation and fresh installation. Default Secret names below apply in the pty-policy release namespace. Use your configured names when the release overrides them.

Database Accounts

The chart defines default Secret names, but no default database usernames or passwords. Choose three distinct login names and independently managed passwords. The example usernames below are suggestions, not chart defaults. Each Secret contains postgres_user and postgres_password. The default database name is policy. Database provisioning also creates the fixed PostgreSQL pmx_app permission role and grants it to runtime. This NOLOGIN role is not a fourth login, platform user, or credential Secret.

The following table lists the database accounts, their permissions, and default Secrets:

Database startup creates missing workload roles from these credentials. The separate bootstrap Job installs the schema and application grants. Operators supply the Secrets. The chart handles account creation and permission checks. No manual database grants or account-validation steps are required. Do not create platform users for these PostgreSQL logins.

The chart creates all three logins without SUPERUSER, CREATEDB, CREATEROLE, REPLICATION, or BYPASSRLS. Maintenance owns objects within the Policy database, not the PostgreSQL cluster. Never use its credentials for ordinary application programming interface (API) traffic. Runtime and backup do not own application objects or assume administrator roles.

Runtime and Backup Privileges

This section explains the database permissions that installation configures automatically. Use it to understand the account separation or investigate a database privilege-check failure. It does not require additional account creation or manual permission grants.

The Policy API uses the runtime database login, such as policy_runtime, to read and update application data. Backup Jobs use a separate login, such as policy_backup, to read data for database dumps. The backup login does not need write access.

PostgreSQL roles can group permissions without serving as login accounts. Policy uses the fixed pmx_app role to group its restricted application permissions. Database provisioning creates this role and assigns membership to the runtime login. Membership lets that login use the role’s permissions. The bootstrap Job configures the grants listed below.

The NOLOGIN setting prevents direct sign-in as pmx_app. This role needs no password or Kubernetes Secret. Installation keeps the backup login outside this role so that it cannot inherit application write permissions. Supply credentials only for the maintenance, runtime, and backup logins described above.

The table compares the resulting permissions of the runtime and backup logins:

Runtime does not have unrestricted create, read, update, and delete access. Its grants preserve protected history while allowing necessary application operations. An allowlist means explicit grants on selected tables or columns, rather than a blanket write grant. For protected records, permitted updates include draft closure, revision supersession, and access-grant revocation metadata. They do not permit rewriting saved authored snapshots.

The derived and compatibility tables with insert, update, and delete grants are:

• policy_versions, policy_decisions, policy_statements, policy_element_refs, and policy_artifacts.
• product_policies, securequery_profiles, securequery_profile_revisions, securequery_capability_manifests, and harmonization_identity.

Bootstrap checks effective privileges, including inherited access. Extra role memberships or public grants can cause startup checks to fail. Do not add broad grants to bypass a failed check.

The postgres identity remains a separate local administration account. Database provisioning clears its network password. Do not expose it or supply it to application workloads.

Naming, Retained Storage, and Rotation

Choose nonempty, distinct usernames of at most 63 bytes. Do not use postgres, pmx_app, or the reserved pg_ prefix. Usernames and passwords must not contain control characters.

Keep the same usernames when reusing database storage. Provisioning rejects changes to the recorded workload names. Changing a Secret name does not migrate database ownership or split a legacy login. Ask the database administrator for a tested ownership-migration procedure before converting an existing database.

Coordinate password rotation across database provisioning and affected workloads. A Secret update alone does not update an existing PostgreSQL password or running environment. Preserve the current credentials and recovery evidence until verification succeeds. Follow configuration changes and backup and restore boundaries.

Dependency Service Users

Create two dedicated regular users in PPC. The following usernames are the documented installation convention. Helm does not create these users or enforce their names. The username in each Secret must match the actual provisioned account. Retain the compatibility identifiers exactly as shown when using this convention.

The following table lists integration users and their required access:

Each dependency Secret contains username and password. Policy supplies these values through the corresponding PIM_* or TRAVERSE_* environment. Both integrations default to the /pty/v1/auth/login/token endpoint. Token login accepts form fields named loginname and password. A successful check returns Hypertext Transfer Protocol (HTTP) 200 and a nonempty pty_access_jwt_token response header. Never print or retain that header in shared logs.

Shared Token-Login Role

The platform administrator creates policy_service_login before installing Policy. Its exact permission set contains only can_create_token. This permission permits token creation and refresh, not dependency access. Keep the role assigned after installation.

Manage this custom role outside the Policy chart’s product configuration. Dependency users do not need the human policy_viewer, policy_author, or policy_admin roles. Do not modify those chart-managed roles to obtain service login. Confirm custom-role support and effective access on the selected platform release.

PIM Permissions and Caller Attribution

The documented workbench_administrator role supplies these permissions:

This bundle grants broader access than a read-only inventory account. workbench_viewer supplies workbench_management_policy_read, not the required writes. Do not substitute that role merely because inventory reads or token login succeed. Before narrowing this mapping, ask the PIM administrator to test inventory reads, publication, and withdrawal with the replacement permissions. See Workbench roles and permissions.

Inventory reads, startup import, and background publication or withdrawal use the service user. Request-driven PIM mutations instead use the calling human’s forwarded token. That human needs their own Workbench permissions for the requested operation. Policy does not silently substitute the worker account after caller authorization fails.

Traverse Permissions and Visibility

The following table summarizes the Traverse roles and their permissions:

Traverse administrator access does not include the automation role’s state-write permission. Keep both dependency roles. Without administrator visibility, login can succeed while the datastore list remains empty. The current integration therefore retains a broad administrator compatibility requirement. Do not share this account with human users or unrelated workloads. Keep both roles until the Traverse integration supports narrower permissions for these operations.

Every Traverse interaction uses the service user, not a human’s forwarded token. Existing installations can use the legacy pmx.discoverx.poller username. Use its actual verified credentials rather than renaming a working account during installation.

Kubernetes and Directory Identities

Kubernetes ServiceAccounts are not PPC users or PostgreSQL logins. The chart creates policy-api, policy-panel, and policy-db by default. They follow the corresponding workload containerName settings. The chart disables service-account token automount for these identities.

Traverse also uses a scanner ServiceAccount for shared identity provider (IdP) metadata. The default scanner is discoverx-discoverx-scanner in the discoverx namespace. Configure idpSecret.writer for the actual scanner identity in your deployment. Policy grants that identity only patch on the named discoverx-idp-connections Secret in the Policy namespace. It does not grant general Secret read, list, create, or delete access. This Kubernetes permission does not replace the poller’s Traverse roles.

Directory bind and provider credentials remain separate, source-specific identities. Policy defines no default directory bind username. Do not reuse database or dependency service passwords for directory access. Registry pull credentials likewise remain platform-owned.