1 - Policy Security Settings
Reference human authority, workload identities, credential handling, signing keys, and network trust.
Policy separates authenticated users, command capabilities, resource grants,
and integration identities. Each controls a different boundary.
Successful network access does not establish permission to approve or repair policies.
The application programming interface (API) and Policy Integration Manager (PIM)
also enforce different authority boundaries.
Security Controls
The chart uses non-root workloads, restricted container contexts, dropped Linux
capabilities, and read-only filesystems where applicable.
It disables privilege escalation and limits network paths.
These settings do not replace gateway authentication or cluster network enforcement.
Keep local mode and fake dependencies disabled in customer deployments.
Keep certificate verification enabled with the correct trust material.
Do not treat authentication failures as reasons to bypass the gateway.
Roles and Authorization
With authorization.enabled: true, the chart registers human application roles
and gateway authorization resources.
Policy derives actors from trusted platform identity.
Callers must not forge identity headers or send another user’s audit identity.
The following table summarizes each built-in role and its authority boundary:
| Role | Authority and Boundary |
|---|
policy_viewer | View permitted policy information. Do not submit, request changes, or approve. |
policy_author | Add authoring, compilation, preview, and rollback capabilities. Require applicable resource grants for protected commands. |
policy_admin | Add broad review, approval, archive, audit, system-configuration, and observability capabilities. Reserve for approved administration. |
Reviewer and approver describe responsibilities, not a fictional reviewer role.
Different authenticated people can author, review, and approve.
Policy command checks do not themselves require different people.
Apply your deployment’s approved separation-of-duties requirements.
Never share credentials to demonstrate a handoff.
Use this table to match common tasks with their required command authority:
| Task | Required Command Authority |
|---|
| Create, edit, or submit | Require policy:edit and applicable policy owner/editor authority. |
| Request changes or inspect saved validation | Require policy:review. |
| Approve | Require policy:approve. |
| Archive or retry withdrawal | Require policy:archive. |
| Retry publication | Require policy:approve. |
| Inspect restricted operations or validation diagnostics | Require policy:audit. |
| Read metrics | Require policy:observability. |
| Change runtime log settings or reconcile ownership | Require policy:system-configure. Also require archive authority for reconciliation withdrawal. |
Owner/editor grants do not supply review or approval capability.
Author capability alone does not permit reviewer decisions.
Audit read access does not authorize recovery mutations.
Do not grant the broad administrator role merely to satisfy one task.
Identity owners assign the chart-registered roles to the appropriate human accounts.
Gateway policy-library-read, policy-library-edit, and policy-library-admin
permissions map to different capability bundles.
The Library administrator permission does not include every system or observability permission.
Unknown authorities grant no capability.
Refer to roles and permissions and
API authentication for shared contracts.
Consumer Evidence
The empty-string default for GUARDRAILS_CONSUMER_USERNAME accepts anonymous-only pull evidence.
Only requests with absent or empty identity qualify in this compatibility mode.
Named requests do not qualify under the empty-string default.
A nonempty value permits receipts only for an exact gateway-verified service username.
Qualifying 200 and 304 retrievals can both record receipts.
With a nonempty setting, anonymous reads and diagnostics under another identity do not qualify.
A matching receipt does not prove Federated Guardrails activation.
A receipt records a qualifying read of a particular product artifact.
Activation means the consumer actually applies that configuration. Read evidence alone cannot establish it.
The setting does not authenticate that user.
The gateway must validate identity and reject caller-supplied identity headers.
Network policies alone cannot establish trusted identity.
Keep the Guardrails consumer’s credentials separate from human, PIM, and Traverse credentials.
The chart maps apiService.environment.GUARDRAILS_CONSUMER_USERNAME through the API ConfigMap into the environment.
Credential Handling
Keep the following credentials separate.
Database usernames below are examples, not defaults. Dependency usernames are documented conventions.
The following table summarizes credential identities and their boundaries:
| Credential | Username or Identity | Permissions and Boundary | Credential Reference |
|---|
| Database maintenance | Choose a login such as policy_maintenance | Own the Policy database and schema. Perform migrations and approved restores, never ordinary API work. | Use policy-db-maintenance by default |
| Database runtime | Choose a login such as policy_runtime | Inherit pmx_app for reads and allowlisted writes. Do not own schema or rewrite protected history. | Use policy-db-runtime by default |
| Database backup | Choose a login such as policy_backup | Read tables and sequence values for dumps. Do not write or inherit runtime grants. | Use policy-db-backup by default |
| PIM worker account | Use the provisioned account, conventionally pmx.pim.service | Permit inventory, background writes, and token login. Do not substitute for the interactive caller. | Use pim-credentials by default |
| Traverse service account | Use the provisioned account, conventionally pmx.traverse.poller | Permit all-datastore visibility, protection-state writes, and token login. | Use traverse-credentials by default |
| Registry pull credential | Use the platform-owned registry identity | Pull approved workload images. Retain platform ownership. | Reference the platform-named pull Secret |
| Human token | Use the individual authenticated user | Attribute commands and authorize caller-driven dependency mutations. | Obtain the user’s own gateway token |
pmx_app is an automatically created PostgreSQL NOLOGIN permission role, not a credentialed account.
The database reference
defines its grants and the runtime/backup boundary.
For database and service credential Secret names and keys, refer to the installation
steps for database credentials
and PPC service credentials.
For exact account names, dependency roles, database grants, and Kubernetes identities,
refer to accounts and permissions.
Do not store secrets in values files, --set arguments, tickets, or log excerpts.
Treat logs and diagnostics as sensitive even where credential redaction applies.
The platform-owned login-only policy_service_login role contains
can_create_token. Combine it with the dependency’s required access.
Do not modify chart-managed human roles to obtain worker login.
PIM background publication and withdrawal need policy-write access.
Read-only Workbench permission is insufficient.
Grant only the required dependency access through approved mappings.
The documented PIM account uses workbench_administrator plus policy_service_login.
The documented Traverse account uses discoverx-automation-client, discoverx-admin,
and policy_service_login.
Traverse administrator visibility does not grant the automation role’s state writes.
Its current administrator requirement is a compatibility exception, not a read-only role.
Do not replace either assignment with a guessed least-privilege bundle.
A Policy administrator role does not grant Workbench permission to a human.
Interactive PIM mutations require the caller’s forwarded credential and dependency authority.
They do not silently fall back to the worker account.
Platform account changes do not automatically update Kubernetes Secrets.
For registry access, the chart references the platform-named Secret already
present in the release namespace. It does not create, copy, or rotate it.
Coordinate renewal with the platform owner.
For managed database credentials, inspect external secret reconciliation and
deletion policies before rotating or removing anything.
Changing a Secret alone does not necessarily change an existing database login.
External Resources After Uninstallation
Helm removal does not revoke external accounts or erase every backup.
The uninstallation procedure
separates retained-data removal from irreversible cleanup.
Use these ownership boundaries when preparing that cleanup:
| Resource | Owner and Cleanup Boundary |
|---|
| Live database claims and volumes | Have the storage owner confirm the selected claim, reclaim policy, and remaining volume. |
| Dump claim and remote backup copies | Apply the agreed retention period through the backup owner. Verify required copies before disposal. |
| Velero resources and external storage | Have the backup owner check off-namespace records, snapshots, copied data, and storage-provider deletion. |
| Database and integration credentials | Preserve recovery identities when retaining data. Have identity owners disable obsolete dedicated accounts and revoke tokens. |
| Registry credentials | Retain platform ownership. Remove only release-scoped copies through their provisioner, never revoke shared source credentials. |
| Shared identity provider (IdP) connection document | Expect chart-owned Secret removal. Have the connection owner preserve required settings and repopulate them during recovery. |
| External secret resources | Have the provider owner check deletion policies and stop obsolete reconciliation before removing generated Secrets. |
| Platform accounts and native policies | Have the relevant product owners verify account revocation and intended target protection or withdrawal independently. |
Deleting a Kubernetes Secret does not invalidate its underlying password or token.
For final removal, the identity owner disables the dedicated PIM and Traverse users
and revokes their active tokens through platform administration.
Shared users require a dependency review rather than automatic deletion.
The secret-provider owner removes obsolete remote credentials and synchronization rules.
The change record should identify each owner and their verification result, without secret values.
For retained-data recovery, required database identities and usable dependency credentials remain necessary.
Rotate the Policy Signing Key
Policy signs ownership markers on managed PIM objects.
This privileged operation changes persisted signing identity and native markers.
It is not a routine password rotation.
Use an approved change window, recoverable signing state, and working PIM access.
Complete the explicit cluster-context setup
in this operator session before running signing commands.
Confirm that the reported cluster and selected namespace identify the intended Policy deployment.
Stop if either differs from the approved change target.
The packaged operator command supports status, rotate, and re-sign.
For an authorized operator, status inspection uses:
kubectl --context "${CTX:?Set CTX}" --namespace pty-policy exec deployment/policy-api \
--container policy-api -- \
/app/.venv/bin/python -m pmx.api.signing_key status
The command reports fingerprints, not key material.
After approving rotation, use the same command with rotate instead of status.
Rotation re-signs managed markers and requires no pod restart.
If PIM becomes unavailable, restore access and run re-sign.
Inspect status again before declaring completion.
The previous key’s default seven-day grace period starts only after successful re-signing.
Markers still needing the previous key can suspend that grace period.
The drop-previous command stops accepting the previous key immediately.
Reserve it for an approved compromise response. Dependent markers will stop verifying.
Do not use it to bypass incomplete re-signing.
Network Policy Integration
The chart provides default-deny policies and selected allow paths.
These policies require a container network interface (CNI) that enforces Kubernetes network policies.
Gateway routes protect API and Panel access.
Health probes access the Service directly and do not prove gateway protection.
Direct diagnostic access can bypass gateway authentication.
The apiConsumers list permits selected direct consumers.
Each entry must specify a namespace and a nonempty pod selector.
Use actual workload labels and set apiConsumers: [] when no direct consumer needs access.
Namespace-only consumer access is not a supported replacement.
Network reachability does not replace caller authentication and authorization.
Procedure
Refer to configuration workflow
for deployment controls.
Coordinate role changes with identity owners and credential rotation with dependency owners.
Do not print Secret values or assign broad roles as troubleshooting shortcuts.
Chart-Managed Security
The chart configures workload security settings, network policies, and gateway authorization resources.
It registers the built-in roles and their permission mappings automatically.
Installers do not need to inspect these resources or retest the built-in role boundaries.
Platform administrators provide gateway authentication and a CNI that enforces network policies.
Protegrity Provisioned Cluster (PPC) users with administrator permissions assign user access and manage external dependency credentials.