Skip to content

Compliance

Compliance combines configuration, process, and evidence. This page covers launch hardening, MLPS and SOC 2 control mappings, supply-chain integrity, and vulnerability response.
Compliance combines configuration, process, and evidence. This page covers launch hardening, MLPS and SOC 2 control mappings, supply-chain integrity, and vulnerability response.

Compliance is not a product you can buy. It is a state that must be demonstrated continuously through three elements:

  • Configuration: whether security controls are enabled. Pigsty directly provides this part.
  • Process: access approval, change management, recovery exercises, and related procedures. The organization must establish these.
  • Evidence: records showing that configuration and process remain effective. Pigsty’s inventory, runtime logs, and monitoring system can provide part of this evidence.

This page begins with a pre-launch hardening checklist and then maps Pigsty security capabilities to common compliance frameworks. The mappings support architecture and gap analysis; they are not an MLPS assessment conclusion, a SOC 2 audit opinion, or legal advice.

Default Credentials Checklist

Pigsty default credentials are public in the documentation and source code. They are intended only for demonstrations and local development. Change every applicable default before any production or network-exposed deployment goes live:

Scope Example Default configure -g
Grafana administrator and viewer pigsty, DBUser.Viewer Yes
HAProxy administration interface pigsty Yes
PostgreSQL administration, monitoring, and replication users DBUser.DBA, DBUser.Monitor, DBUser.Replicator Yes
Patroni REST API Patroni.API Yes
etcd root Etcd.Root Yes
MINIO module object-storage root S3User.MinIO Yes
Object-storage backup and example application users S3User.Backup, S3User.Meta, S3User.Data Yes
Example database users DBUser.Meta, DBUser.Supa, Vibe.Coding Yes
pgBackRest encryption passphrase cipher_pass: pgBackRest No
Silo users and pgBR.${pg_cluster} in ha/safe Template example values No
User-defined credentials Custom values No

Use -g while generating configuration to randomize built-in parameters and example strings recognized by the configuration wizard:

./configure -g     # Generate the inventory and randomize recognized default credentials

The wizard prints generated passwords to the terminal, so protect terminal history and automation logs as sensitive data. After generation, inspect the configuration and replace pgBackRest cipher_pass, MINIO module example values in ha/safe that were not covered, and all custom credentials.

Launch Hardening Checklist

Before deployment:

After deployment:

  • Confirm that credentials covered by configure -g and uncovered backup, object-storage, and custom credentials have all been changed
  • Review the effective HBA rules in /pg/data/pg_hba.conf against the declaration and intended boundary
  • Query effective users, roles, default privileges, and database CONNECT grants, and compare them with the inventory
  • Run one full backup and a recovery exercise to validate the backup path
  • Confirm log collection, monitoring alerts, and notification channels

Periodically:

  • Audit privileges: compare pg_users declarations with effective grants, and remove expired or departed-user accounts
  • Rotate credentials and certificates
  • Exercise recovery and failover
  • Track security updates for Pigsty and upstream components

Compliance Evidence

Declarative configuration provides a stable starting point for audit evidence. Retain runtime state as well to show that the configuration was applied and remains effective.

Evidence Source
Security baseline and change history The pigsty.yml inventory and Git history
Access-control matrix pg_default_roles, pg_users, and pg_hba_rules declarations
Effective authentication policy Rendered pg_hba.conf on each instance, compared with declarations to detect drift
Effective users and privileges PostgreSQL catalogs, database ACLs, \du+, and \ddp+
Operation and connection logs PostgreSQL DDL, slow-query, and connection logs retained in VictoriaLogs
Backup records pgBackRest information and monitoring dashboards
Security incidents and alerts Monitoring alert history
Certificate inventory files/pki/ and deployed component certificates

MLPS Level 3 Mapping

The following maps database-related Pigsty capabilities to controls in the “secure computing environment” section of GB/T 22239-2019 Level 3:

Control Pigsty Capability Additional Requirement
Unique identity Independent accounts and SCRAM-SHA-256 password storage Real-name account management process
Password complexity and rotation passwordcheck, credcheck, and expire_in Enable extensions and establish a rotation process
Login failure handling Can be implemented with credcheck and related extensions Enable and configure as required
Access control and least privilege Four-tier roles, default privileges, and database isolation Privilege approval workflow
Security audit DDL, connection, and slow-query logs; pgaudit; centralized retention CRIT or manual connection logging; required retention period
Communication confidentiality Local CA and TLS; HBA-enforced ssl or cert Enforce TLS, client verify-full, and certificate rotation
Data integrity Page checksums by default and strict synchronous replication with CRIT Storage protection, defined failure model, and exercises
Data confidentiality AES-encrypted backup plus TDE and column-encryption options Enable as required
Backup and recovery pgBackRest, PITR, and a remote S3-compatible repository Recovery exercise process
Residual information protection — Media destruction and erasure process

MLPS also covers physical security, communication networks, and management systems beyond the scope of a database distribution. Pigsty can support database-related technical controls in a secure computing environment; facilities, network devices, and governance must be addressed in the overall system.

SOC 2 Mapping

Database-related controls in the SOC 2 Trust Services Criteria (TSC) include:

Criterion Pigsty Capability Additional Requirement
CC6.1 Logical access security HBA, RBAC, default privileges, and database isolation Privilege design, approval, and periodic review
CC6.2 User registration and authorization Declarative users, roles, and expiration Joiner, mover, leaver, and identity-verification process
CC6.3 Access changes and revocation pg_users, role changes, REVOKE, and expiration Tickets, approval evidence, and timely revocation
CC6.6 External boundary threats Firewalls, listen addresses, HBA, and restricted management ingress Network architecture, boundary devices, and continuous validation
CC6.7 Information transmission and movement TLS, client verification, and backup encryption Policies for exports, media, and third-party transfer
CC7.2 System monitoring Victoria observability stack with extensive metrics and alerts Alert-response process
CC7.3 Incident traceability Centralized logs and audit extensions Log-review process
A1.2 Availability and recovery High Availability and PITR Exercise records and RTO/RPO objectives

Supply Chain and Vulnerability Response

Compliance reviews increasingly cover the software supply chain. Pigsty provides the following distribution and response controls:

Package integrity: RPM and DEB packages in the Pigsty repositories (repo.pigsty.io and repo.pigsty.cc) are GPG-signed. The public-key fingerprint is 9592 A7BC 7A68 2E73 3337 6E09 E793 5D8D B9BD 8B20 (B9BD8B20) and can be verified before trust is established. Repository definitions written during deployment and the local repository on the INFRA node do not enforce signature verification for every package by default; review package-manager repository trust and signature settings in production.

Vulnerability response: report security issues privately through GitHub private vulnerability reporting or email, as documented in SECURITY.md. The project targets acknowledgment within three business days and an initial assessment within seven days.

Version support: security fixes ship with the latest stable release. Staying current is the standard way to receive them. Users who must remain on a version for longer can obtain extended support through subscription services.

Next