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

Was this page helpful?

Suggest edits