Security Architecture

This page describes how Infracast authenticates users, enforces authorization, isolates tenant data, and protects data at rest and in transit.

Authentication

Infracast supports two authentication mechanisms:

JWT Tokens (User Sessions)

Users authenticate via the login page or REST API and receive a short-lived session token.

• Signed using a configurable secret (JWT_SECRET)
• Default expiry: 8 hours
• Include in all API requests: Authorization: Bearer <token>

API Keys (Machine Access)

For automation, integrations, and CI/CD pipelines:

API keys are created from Settings → API Keys in the UI or via the REST API.

• API keys are tenant-scoped and role-bound
• Secrets are stored as bcrypt hashes — the plaintext is shown once at creation
• Keys can be revoked instantly from Settings → API Keys
• Include in requests: Authorization: Bearer sk_...

Agent Enrollment and JWT

Agents use a two-step authentication flow:

1. Enrollment token (single-use, time-limited) — generated from UI
2. On first connection, agent exchanges enrollment token for a long-lived agent credential
3. Agent JWT is revocable from the Agents page at any time

Role-Based Access Control (RBAC)

Infracast enforces a five-tier RBAC model. Roles are assigned per-user per-tenant (a user can be a security-analyst in Tenant A and read-only in Tenant B).

Roles

Role	Description
system-admin	Full platform access — manages tenants, billing, system settings
tenant-admin	Full access within a tenant — users, credentials, jobs, findings
security-analyst	Run discovery jobs, view and manage findings, read asset graph
auditor	Read-only access to findings and audit logs — for GRC/compliance teams
read-only	View asset graph nodes and edges only

Permission Matrix

Permission	system-admin	tenant-admin	security-analyst	auditor	read-only
Tenant create/delete	✅	❌	❌	❌	❌
Users manage	✅	✅	❌	❌	❌
Credentials manage	✅	✅	❌	❌	❌
Discovery jobs	✅	✅	✅	❌	❌
Nodes/edges read	✅	✅	✅	✅	✅
Nodes/edges write	✅	✅	✅	❌	❌
Findings read	✅	✅	✅	✅	❌
Audit run	✅	✅	✅	❌	❌
Evidence read	✅	✅	✅	✅	❌
Evidence write	✅	✅	✅	❌	❌
POA&M read	✅	✅	✅	✅	❌
POA&M write	✅	✅	✅	❌	❌
Audit logs read	✅	✅	❌	✅	❌
System admin	✅	❌	❌	❌	❌

Tenant Isolation

Multi-tenant isolation is enforced at the storage layer, not just at the API layer:

• Every database row carries a tenant_id column
• All queries include a WHERE tenant_id = ? clause generated by the ORM — no query can omit this
• Foreign key constraints prevent cross-tenant node/edge references
• There is no shared mutable state between tenants

warning

No Infracast API endpoint allows cross-tenant data access, even for system-admin users. Admins manage tenants but cannot read tenant data without explicitly being assigned a role within that tenant.

Encryption

At Rest

Component	Encryption
RDS PostgreSQL	AES-256 (AWS-managed KMS key)
Documents & artifacts (export files today)	Per-tenant envelope encryption (AES-256-GCM per file, per-tenant key) — see below; bucket default encryption as a second layer on SaaS
Credential secrets	AES-256-GCM, application-layer encryption before storage
Agent tokens (stored)	bcrypt hash

Per-tenant artifact encryption

Infracast provides per-tenant encryption of documents and artifacts. Today this applies to export files; other generated documents and uploaded evidence are being moved onto the same store. It does not cover the database, which is encrypted as shown in the table above.

• Storage. Files are kept in object storage — S3, or any S3-compatible store with a custom endpoint (for example Ceph or RustFS) — on SaaS, or on the local filesystem for air-gapped installs. The backend is chosen by explicit configuration; there is no silent fallback between backends, and file contents are not stored in the database.
• Envelope encryption. Infracast encrypts each file itself. Every file gets its own data key (AES-256-GCM), and that data key is protected by a per-tenant key. The ciphertext is bound to the tenant and the object path, so a file moved or copied to another tenant's path cannot be decrypted.
• SaaS. Each tenant gets its own AWS KMS key, created automatically when the tenant's first file is stored, with automatic annual rotation. Storage access uses short-lived credentials tagged with the tenant ID, so AWS itself refuses cross-tenant reads of files and keys — this is enforced by IAM, not only by application code. Bucket default encryption is also enabled as a second layer.
• Air-gapped. An operator-supplied master key file protects each tenant's key. See Air-Gapped Deployment.
• Tenant deletion. Deleting a tenant destroys its key (crypto-shredding) and deletes its files. On SaaS the KMS key is disabled and then scheduled for deletion with a 30-day window.

Air-gapped: back up the master key

If the master key file is lost, every stored artifact becomes permanently unrecoverable. Back it up separately from the data.

In Transit

Connection	Encryption
Browser → CloudFront/ALB	TLS 1.2+ (enforced by ALB policy)
ALB → ECS Fargate	TLS (ALB terminates externally; internal traffic within VPC)
Agent → API Server	TLS 1.2+, certificate validation mandatory
Relay → API Server	WSS (WebSocket Secure), TLS 1.2+
Relay mTLS (optional)	Mutual TLS with client certificates for IL4+ environments

Relay mTLS

For high-assurance environments, relays can be configured with mutual TLS:

docker run -d --name infracast-relay \
  -e RELAY_TOKEN="your-token" \
  -e RELAY_ID="your-id" \
  -e RELAY_CLIENT_CERT="/certs/client.crt" \
  -e RELAY_CLIENT_KEY="/certs/client.key" \
  -e RELAY_CA_CERT="/certs/ca.crt" \
  -v /path/to/certs:/certs \
  ghcr.io/azgardtek/infracast-relay:latest

Ed25519 Evidence Signing

All evidence artifacts collected by Infracast's compliance engine are signed with Ed25519 (EdDSA) cryptographic signatures.

Signing Flow

1. Evidence artifact collected (API response, config snapshot, screenshot)
2. SHA-256 hash of artifact computed
3. Hash signed with Ed25519 private key
4. Artifact + signature + public key fingerprint stored together

Verification

Evidence artifacts can be independently verified using standard Ed25519 verification tools. Contact support for verification tooling.

FIPS 140-2 Support

For FedRAMP High, IL4, and IL5 environments, Infracast provides FIPS 140-2 validated builds using BoringCrypto:

• All cryptographic operations route through FIPS-validated BoringCrypto module
• TLS limited to FIPS-approved cipher suites (AES-GCM, ECDHE)
• SHA-3 and legacy ciphers (RC4, 3DES) are disabled

FIPS Builds

FIPS builds are available as separate container images:

ghcr.io/azgardtek/infracast:latest-fips
ghcr.io/azgardtek/infracast-relay:latest-fips

Credential Storage

Credentials (cloud keys, SSH passwords, SNMP community strings) are protected with multiple layers:

1. Encrypted at rest — AES-256-GCM with a per-installation master key
2. Never logged — credential values are redacted from all log lines
3. Never sent to plugins in plaintext — plugin configs carry credential IDs; the plugin host resolves secrets at runtime
4. Never written to relay disk — relay holds credentials in memory only during task execution
5. Audited — all credential access events appear in the audit log

Security Headers

The API server sets standard security headers on all responses:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'

Audit Logging

All security-relevant events are recorded in the immutable audit log:

Event Category	Examples
Authentication	Login success/failure, token revocation, API key usage
Authorization	Permission denied events
Credential access	Credential created, deleted, used by job
Discovery	Job started, completed, failed
User management	User created, role changed, tenant membership
Evidence	Artifact collected, signature verified

Audit logs are append-only. Roles with logs:read permission (system-admin, tenant-admin, auditor) can view them.

Penetration Testing

tip

If you are planning a penetration test of your Infracast self-hosted deployment, please review our security policy first. For SaaS, coordinate through your account team.

Reporting Security Issues

Report security vulnerabilities privately to security@infracast.io. We maintain a responsible disclosure program and aim to respond within 48 hours.