Integrity Service Operations
Operational expectations for Integrity Service in customer deployments.
Integrity Service should be monitored as part of the full Guardian Platform deployment. It supports user-facing lineage, manifest, certificate, and credential-status workflows.
Required Configuration Areas
- Auth Service integration when authentication is enabled.
- Platform database connection for durable records.
- Blob storage provider for stored artifacts.
- Signing keys, which Integrity Service does not hold itself: through Auth Service, it signs declaration and review statements with the caller’s key, and certificates and status-list credentials with the platform key, so Auth Service key management must be healthy.
Supported blob storage providers include Azure Blob Storage, AWS S3, Google Cloud Storage, and local filesystem storage for non-production use.
Configuration Reference
Integrity Service reads layered JSON config files, chosen by RUST_ENVIRONMENT, then applies environment variable overrides. The chart sets these for you; the reference below is for reading a rendered deployment or running the service directly.
RUST_ENVIRONMENT | Files merged, in order |
|---|---|
production (default) | config.base.json, config.json |
staging | config.base.json, config.json, config.staging.json |
development | the staging files, then config.development.json |
| any other name | config.base.json, config.<name>.json |
Any variable named INTEGRITY_APP__<path> overrides a config key, with __ separating nested keys: INTEGRITY_APP__db__password sets db.password.
| Key | Values |
|---|---|
port | 3050 |
auth.type | auth_service (with auth.url) or no_auth |
blob_store.type | azure_blob (account, key, container), aws_s3 (region, bucket, folder), gcs (bucket, folder), or local_fs (path) |
db.* | user, password, host, db_name, port, ssl_mode, ssl_root_cert |
logging.log_level | Log levels per target; RUST_LOG overrides them |
AWS S3 reads AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY or the default credential chain, and Google Cloud Storage reads Application Default Credentials (GOOGLE_APPLICATION_CREDENTIALS). Logs are exported over OTLP when a standard OTEL_* exporter variable such as OTEL_EXPORTER_OTLP_ENDPOINT is set; OTEL_LOGS_EXPORTER=none turns export off.
Operational Checks
- Service health.
- Connectivity to Auth Service when authentication is enabled.
- Database and blob storage availability.
- Signing and credential-status workflow health.
- Guardian lineage and credential views after deployment or upgrade.
The health endpoint reports that the process is running; it does not check the database or blob storage:
curl https://guardian.example.com/integrityService/health/v1{
"status": "healthy",
"service": "integrity-service",
"timestamp": "2026-10-16T12:00:00Z",
"version": "1.2.1",
"uptime_seconds": 3600
}Backup and Restore
Back up Integrity Service data with the rest of the Guardian Platform. Restore database records, blob storage, secrets, and platform configuration together so lineage and credential workflows remain consistent.
Related
- Integrity Service Troubleshooting — first-line checks when lineage, certificates, or blob storage fail
- Key Configuration — the Auth Service signing keys certificates depend on
- Backup and Restore — the integrity database and rootstore backups, and the restore order
- Chart Values — where the blob storage provider is set in values.yaml
- Observability — platform-wide signals to monitor