Known Issues and Workarounds

Use this reference before installation and when a documented limitation matches your symptoms. An issue entry is not a general instruction to replace credentials or relax permissions. Record installed component versions when reporting an occurrence.

Identity Provider Secret Backfill After Traverse

Condition and Reported Behavior

This issue concerns Policy installed after an existing Traverse deployment.

The reported behavior leaves the shared identity provider (IdP) connection Secret unpopulated. Existing Traverse connection details do not automatically backfill it when Policy is installed later. Policy can therefore lack the connection metadata required for member-source provisioning. Workload readiness alone does not establish that this metadata exists.

Workaround

The reported workaround is to save the existing IdP connection details again in Traverse. The connection owner should use their authorized connection-management workflow after Policy installation. Preserve the intended settings and existing credentials. Do not rotate passwords, recreate the connection, or reinstall Policy merely to trigger this update.

If re-saving does not populate the Secret, ask the platform operator to verify the configured scanner identity. The chart’s idpSecret.writer must name the actual scanner ServiceAccount and namespace. Its permission is limited to patching the named Secret in the Policy namespace. Do not grant broad Secret permissions as a workaround.

Verification

Find the configured Secret name in the chart’s idpSecret.name value. The default namespace is pty-policy. Its default data key is sources.json. Set IDP_SECRET_NAME to that Secret name and CTX to the intended Kubernetes context. An authorized operator can check key presence without printing connection values:

kubectl --context "$CTX" --namespace pty-policy get secret \
  "${IDP_SECRET_NAME:?Set IDP_SECRET_NAME to the configured Secret name}" \
  -o go-template='{{if .data}}{{if index .data "sources.json"}}sources.json: present{{else}}sources.json: missing or empty{{end}}{{else}}sources.json: missing or empty{{end}}{{"\n"}}'

Use your configured Secret name, namespace, and key when defaults differ. present confirms only that the key contains bytes. It does not prove valid JavaScript Object Notation (JSON), the expected provider entry, or usable directory credentials.

Have the authorized integration owner verify the expected connection entry through approved tools. Then repeat the operation that previously lacked member-source configuration. Keep Secret values, bind passwords, and tokens out of logs and support attachments. Escalate if the entry remains absent or the original operation still fails.

Refer to shared identity provider metadata and Kubernetes and directory identities. Use the diagnostic handoff for an unresolved occurrence.