Security and Networking Guide

Security Posture

Paridity is designed to run inside the customer's trust boundary. The standard deployment keeps credentials, object names, data system metadata, proof results, and field-level evidence inside the customer's cloud or private platform.

Identity and Authentication

Paridity uses the customer's identity provider for user authentication.

Supported patterns:

• OIDC/JWT
• SAML, where configured

Production requirements:

• No local development auth bypass
• TLS on all browser-facing endpoints
• IdP groups mapped to Paridity roles
• Break-glass admin access documented and audited
• Access reviews owned by the customer

Main roles:

Role	Typical access
platform_admin	Full deployment-wide administration
tenant_admin	Tenant administration
operator	Configure systems, mappings, schedules, and runs
analyst	Investigate reconciliation evidence
auditor	Read audit records and evidence

Secrets

Paridity must not store source, target, or replication credentials in its own database.

Correct pattern:

Paridity cfg.systems.connection_ref
    |
    v
Customer secret manager
    |
    v
Actual credential

The connection_ref is a pointer. The actual credential lives in AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Vault, or Infisical.

Production requirements:

• Use cloud workload identity where possible.
• Do not store static cloud keys in Kubernetes secrets.
• Use a preflight canary secret to verify access during install.
• Rotate credentials in the customer's secret manager, not in Paridity tables.

Network Boundaries

Only the UI/API should be reachable by users. Worker pods should not be exposed publicly.

Inbound:

Source	Destination	Purpose
Customer users/browser	Paridity ingress	UI and API access
IdP browser redirects	Paridity ingress	Login callback where applicable
Customer monitoring	Health endpoints	Optional health checks

Outbound:

Source	Destination	Purpose
API	PostgreSQL	Config, run, evidence metadata
API	IdP/JWKS endpoint	Token validation
API/workers	Secret manager	Resolve connection references
API/workers	Temporal	Workflow dispatch and execution
Workers	PostgreSQL	Run state and evidence writes
SQL/readiness workers	Source systems	Proof, key extraction, metadata, readiness
SQL/diff workers	Target systems	Proof, key extraction, metadata, diff
Readiness workers	Replication tools	CDC/watermark/lag state
API/workers	OTel/SIEM endpoints	Optional telemetry export

Egress Control

Production deployments should use two layers of egress control:

1. Cloud network controls: security groups, firewall rules, NSGs, private endpoints, routing tables.
2. Kubernetes NetworkPolicy: default-deny with explicit allowed destinations.

The approved destination list should include only:

• Source database endpoints
• Target database/warehouse endpoints
• Replication metadata endpoints
• Secret manager endpoints
• IdP/JWKS endpoints
• PostgreSQL and Temporal endpoints
• Approved telemetry/SIEM endpoints

Data Handling

Paridity handles several classes of sensitive data:

Data class	Stored where	Notes
Credentials	Customer secret manager	Paridity stores only references
Object/schema/column names	Paridity PostgreSQL	Sensitive customer metadata
Resolved config snapshots	Paridity PostgreSQL	Sensitive because they reference systems and fields
Proof results	Paridity PostgreSQL ev.*	Append-only evidence
Mismatch keys	Paridity PostgreSQL ev.*	Append-only evidence
Field-level diffs	Paridity PostgreSQL ev.*	May contain sensitive values; masking policy applies
Audit log	Paridity PostgreSQL cfg.audit_log	Administrative and lifecycle evidence

Field-level evidence must respect masking and raw-value storage policy. If raw values are not permitted, evidence records should preserve the fact of mismatch without storing sensitive values.

Audit and Compliance

Production requirements:

• Administrative actions are written to cfg.audit_log.
• Terminal run status transitions are audited.
• Evidence records are append-only.
• Retention purge actions are logged before deletion.
• Audit logs can be exported to the customer's SIEM.
• compare_started_at is immutable and serves as an audit anchor for runs.

Backup and Recovery

Customer operations owns backup and restore, with Paridity guidance.

Minimum expectations:

• Managed PostgreSQL automated backups
• Point-in-time recovery for production
• Temporal persistence backup
• Quarterly restore validation for regulated use
• Restore runbook reviewed before go-live

Temporal is internal to Paridity, but it is still production infrastructure. The customer operations team must be able to monitor it, restart it, collect logs, patch it, upgrade it within Paridity's supported version range, and restore its persistence backend during DR.

Production Security Checklist

Before go-live, verify:

• APP_ENV=production
• No development auth bypass enabled
• Images pinned by digest
• TLS configured
• Customer IdP configured
• Customer secret backend configured
• Workload identity configured
• Network egress allow-list applied
• PostgreSQL private and encrypted
• Backups and PITR enabled
• Temporal persistence backup and restore path validated
• Temporal operations owner assigned
• Logs reviewed for secret leakage
• Audit log retention configured
• SIEM export configured if required