Security and compliance overview

This document outlines the security features and compliance posture of the software system. It is intended to provide customers and stakeholders with a clear understanding of the security mechanisms in place and the standards to which the system adheres.

Encryption

In Transit

• All inter-service communication within the Kubernetes cluster is encrypted using mutual TLS (mTLS) via Istio service mesh.
• All ingress and egress communication uses TLS 1.2 or higher.

At Rest

• Data stored in blob storage is encrypted at rest using cloud-native encryption mechanisms (e.g., Azure Storage Service Encryption, AWS S3 Server-Side Encryption).
• Encryption keys are managed by the underlying cloud provider and rotated according to provider best practices.

Secrets management

• Secrets are securely managed using the CSI (Container Storage Interface) driver with support for:

  • Azure Key Vault
  • AWS Secrets Manager
  • Google Secret Manager

• Secrets are mounted into pods at runtime and are never stored in plaintext in the cluster.

• Access to secrets is controlled through fine-grained identity and access management (IAM) policies, tied to the workload identity.

• Rotation of secrets is handled externally and reflected immediately via CSI mounts.

Authentication and authorization

• End-user authentication is managed through Keycloak, which supports integration with external identity providers such as Azure Active Directory and Google Identity.

• Authentication follows the OAuth2 and OpenID Connect standards.

• Role-based access control (RBAC) is applied across the system.

• Roles and Permissions:

  • Super Admin
  • General Developer
  • Billing

CI/CD and software supply chain security

• Continuous integration and delivery (CI/CD) pipelines include:

  • Static code analysis
  • Automated testing
  • Software Bill of Materials (SBOM) creation
  • Vulnerability scanning using Grype

• All container images are built from hardened, minimal base images and scanned prior to release.

Logging and monitoring

• Logs are emitted to standard output and error streams (stdout/stderr) following container logging best practices.
• Logs can be collected by pluggable logging agents (e.g., Elastic Agent) deployed into the Kubernetes cluster.
• Centralized logging enables customers to integrate with their own observability solutions and meet internal audit requirements.
• Metrics are emitted to an Otel Collector which can be configured to ship to various observability solutions.

Compliance

The system is designed and operated in accordance with industry-recognized security and data protection standards:

• SOC 2 Type II: Controls are implemented and audited for security, availability, and confidentiality.
• ISO 27001: Operational processes align with the ISO 27001 framework for information security management.
• GDPR: Data handling practices conform to the General Data Protection Regulation (GDPR) for protection of personal data.
• FedRAMP: The system meets the security requirements of the Federal Risk and Authorization Management Program (FedRAMP) for U.S. government systems.

Additional protections

• Each workflow job runs in an isolated, ephemeral Kubernetes namespace to ensure strong runtime separation.
• Namespaced service isolation within the Kubernetes cluster

Assistant

Responses are generated using AI and may contain mistakes.