Policy Security Settings

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:

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:

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:

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:

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.