> ## Documentation Index
> Fetch the complete documentation index at: https://docs.strata.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Compliance and Audit
By the end of this guide, you will have a Maverics Orchestrator with comprehensive audit logging -- capturing authentication events, authorization decisions, configuration changes, and administrative actions for compliance reporting.
**Console terminology:** In the Maverics Console, Orchestrator instances and
configuration delivery are managed through **Deployments**. When working directly
with YAML, configuration is managed as files delivered via the `-config` flag or
`MAVERICS_CONFIG` environment variable.
Compliance configurations use features documented across multiple reference pages. Each section below links to the detailed guide and reference for the specific feature being configured.
## What Is Compliance and Audit Logging?
Compliance means demonstrating that your identity system operates according to your organization's policies and applicable regulations. Audit logging is how you produce the evidence. Every time a user authenticates, every time a policy allows or denies access, and every time an administrator changes the configuration -- these events form an audit trail that tells the story of who did what, when, and whether the system allowed it.
The Maverics Orchestrator generates detailed audit events for every significant action it processes. A SIEM (Security Information and Event Management) system -- such as Splunk, Datadog, or Elastic -- collects and analyzes these events, giving your security team a centralized view of identity activity across your infrastructure. Compliance frameworks like SOC2 (Service Organization Control 2, a standard for service providers), HIPAA (Health Insurance Portability and Accountability Act, for healthcare data), and GDPR (General Data Protection Regulation, for EU personal data) each require specific types of audit evidence, and the Orchestrator's logging covers the identity-related requirements for all of them.
## FIPS 140-3 Compliance
FIPS 140-3 builds are an experimental feature. See [FIPS 140-3 Builds](/reference/orchestrator/experimental/fips) for who needs FIPS, current validation status, feature parity details, and contact information.
## Prerequisites
* **A running Maverics Orchestrator** -- If you have not installed it yet, follow the [Quick Start guide](/guides/getting-started/quick-start) first.
* **A log aggregation system** -- You need somewhere to send audit logs for analysis and long-term retention. This can be a SIEM like Splunk, Datadog, or Elastic, a cloud logging service like AWS CloudWatch or Azure Monitor, or even a file-based log management system for smaller deployments.
## Configure Security Features for Compliance
TLS encryption is a baseline requirement for all compliance frameworks. It ensures that authentication tokens, user credentials, and personal data are encrypted in transit.
**Console UI documentation is coming soon.** This section will walk you
through configuring this component using the Maverics Console's visual
interface, including step-by-step screenshots and field descriptions.
Define a TLS profile and bind it to the HTTP listener:
```yaml maverics.yaml theme={null}
tls:
"default":
certFile: "/etc/maverics/certs/server.pem"
keyFile: "/etc/maverics/certs/server-key.pem"
minVersion: "1.2"
http:
address: "0.0.0.0:9443"
tls: "default"
```
For compliance, set `minVersion: "1.2"` to disable older, vulnerable TLS versions. For the highest security, use `"1.3"`.
See the [Configure TLS guide](/guides/security/tls) for complete setup instructions and the [Transport Layer Security (TLS) Reference](/reference/orchestrator/tls-security) for all profile fields.
Compliance frameworks require that secrets (API keys, credentials, certificates) are stored securely with access controls and audit trails. External secret providers satisfy these requirements by centralizing secret storage with rotation, access logging, and fine-grained policies.
**Console UI documentation is coming soon.** This section will walk you
through configuring this component using the Maverics Console's visual
interface, including step-by-step screenshots and field descriptions.
Configure a secret provider via environment variable (not YAML):
```bash theme={null}
export MAVERICS_SECRET_PROVIDER="hashivault://vault.example.com:8200/secret/data/maverics?token="
```
Then reference secrets in YAML using angle bracket syntax:
```yaml maverics.yaml theme={null}
connectors:
- name: my-idp
type: oidc
oauthClientSecret:
```
This ensures no plaintext secrets appear in configuration files -- a common audit finding and compliance requirement.
See the [Manage Secrets guide](/guides/security/secrets-management) for setup instructions and the [Secret Providers Reference](/reference/orchestrator/configuration/secret-providers) for all 7 provider types.
Authorization policies provide the access control evidence that compliance auditors look for. Every policy evaluation is logged, creating an audit trail of who was allowed or denied access to each resource.
**Console UI documentation is coming soon.** This section will walk you
through configuring this component using the Maverics Console's visual
interface, including step-by-step screenshots and field descriptions.
Define authorization policies on your apps:
```yaml maverics.yaml theme={null}
apps:
- name: my-app
type: proxy
upstream: https://backend.example.com
routePatterns:
- "app.example.com"
policies:
- location: "/"
authentication:
idps: ["my-idp"]
authorization:
rules:
- and:
- contains: ["{{ my-idp.groups }}", "authorized-users"]
```
Each policy evaluation generates a log entry recording the user, resource, decision (allow/deny), and the policy rule that was evaluated. These entries form the authorization audit trail required by SOC2, HIPAA, and GDPR.
See the [Authorization Policies guide](/guides/security/policies) for access control configuration -- RBAC, ABAC, PBAC, and external PDP integration, and the [Applications Reference](/reference/orchestrator/applications) for rule syntax.
The Orchestrator captures authentication and authorization events through its structured logging system. Configure the logger for production audit logging and export logs to your SIEM for centralized analysis and long-term retention.
**Console UI documentation is coming soon.** This section will walk you
through configuring this component using the Maverics Console's visual
interface, including step-by-step screenshots and field descriptions.
Configure structured logging with session correlation for audit trails:
```yaml maverics.yaml theme={null}
logger:
level: "info"
jsonOutput: true
logSessionID: true
http:
accessLog:
disabled: false
level: "info"
```
Key settings for compliance logging:
* `jsonOutput: true` -- Structured JSON logs for SIEM ingestion
* `logSessionID: true` -- Correlate events across a user's session for complete audit trails
* `accessLog.disabled: false` -- Record every HTTP request for access auditing
The Orchestrator's structured logs capture authentication events (login, logout, failures), authorization decisions (policy allow/deny), and request metadata. Events are viewable in the Maverics Console and can be exported to external SIEM systems via your log shipper.
See the [Monitor and Observe guide](/guides/operations/monitor) for complete observability setup and the [Telemetry Reference](/reference/orchestrator/telemetry) for all logging fields.
Start by enabling all event categories. You can always reduce the logging
level later if the volume is too high, but it is much harder to
retroactively generate events that were not captured. For compliance, it
is better to log too much than too little.
Session security settings control cookie protection and session lifetimes. Compliance frameworks require that sessions are protected against hijacking and have appropriate timeout policies.
**Console UI documentation is coming soon.** This section will walk you
through configuring this component using the Maverics Console's visual
interface, including step-by-step screenshots and field descriptions.
Configure session cookies and lifetimes for compliance:
```yaml maverics.yaml theme={null}
session:
cookie:
name: "maverics_session"
domain: ".example.com"
disableHTTPOnly: false
disableSecure: false
lifetime:
maxTimeout: "8h"
idleTimeout: "30m"
```
Key security settings:
* `disableHTTPOnly: false` -- Keeps HTTPOnly flag enabled, preventing client-side script access to the session cookie
* `disableSecure: false` -- Keeps Secure flag enabled, ensuring cookies are only sent over HTTPS
* `maxTimeout` -- Maximum session duration before forced re-authentication
* `idleTimeout` -- Inactivity timeout before session expires
See the [Sessions Reference](/reference/orchestrator/sessions) for all session configuration fields.
With TLS, secret management, authorization policies, audit logging, and session security configured, map the Orchestrator's security features to your compliance framework requirements.
**SOC2** -- Requires evidence of access controls, change management, and system monitoring. The Orchestrator provides: authentication/authorization policy enforcement (access controls), structured audit logs (system monitoring), and configuration-as-code with secret management (change management).
**HIPAA** -- Requires audit trails for access to systems handling protected health information (PHI). The Orchestrator provides: per-request authentication and authorization logging, session ID correlation across events, and policy enforcement logs showing access decisions for PHI-containing applications.
**GDPR** -- Requires records of data processing activities and access to personal data. The Orchestrator provides: authentication event logs (tracking access to personal data), session management with appropriate timeouts, and TLS encryption for data in transit.
**Success!** Your Orchestrator is configured with comprehensive security
features for compliance. TLS encrypts all connections, secrets are
managed externally, authorization policies control access, structured
audit logs capture every significant event, and session security
prevents hijacking.
## Troubleshooting
If expected events are not appearing in the Orchestrator's logs, verify that
the log level is set to `"info"` or lower. Events at the `"info"` level
include authentication and authorization decisions. If you need more detail,
temporarily set the level to `"debug"` to see all internal events. Also confirm
that `jsonOutput: true` is set so your SIEM can parse the structured log format.
If audit logs are generated locally but not appearing in your SIEM, check
the log shipper configuration between the Orchestrator and your SIEM. Common
issues include incorrect endpoint URLs, authentication failures with the
SIEM's ingestion API, network connectivity issues (firewalls blocking the
export traffic), and format mismatches (the SIEM expects JSON but receives
plain text). Test the log path independently to isolate the issue.
If your compliance reports show gaps -- periods where no events were
recorded -- investigate whether the Orchestrator was running during those
periods and whether the log export was functioning. Gaps can also occur if
the SIEM dropped events due to ingestion rate limits or storage capacity.
For critical compliance requirements, configure redundant log export
destinations so that a single export failure does not create gaps in your
audit trail.
## Related Pages
Return to the Security guides hub for TLS, secrets, policies, and compliance
Complete configuration reference for logging, monitoring, and observability
Define the access control policies whose enforcement is captured in audit logs
Monitor and operate the Orchestrator in production -- including log management