CloudTruth Documentation
Sign InAPIIntegrationsGitHubVisit our website
  • Overview
  • Getting Started
  • Architecture
    • 🔒Security Overview
  • Copilot
  • 🏢Org management
    • Account Setup
    • Access Control
      • 🔑API Tokens
      • 🌐Protecting Projects and Environments
      • 👥Users
    • Audit Log
  • 🛠️Config Management
    • Projects
    • Parameters
      • Sharing Config Data
      • Parameter Management
        • Internal Values
          • Dynamic Values
        • External Values
          • Terraform Remote State Files
        • Parameter Override
        • Environment Value Override
      • Parameter and Parameter Value Inheritance
      • Value Comparison
      • Value History
      • Value Validation
      • Value Expiration
    • Environments and Tags
    • Templates
      • 📒Sample Templates
    • Actions
      • Import Actions
      • Push Actions
    • CLI & API
      • CloudTruth CLI
      • Rest API
    • Integrations
      • Argo CD
      • Atlassian Compass
      • AWS
        • AWS Connection
        • AWS Role
          • CloudFormation
          • Terrraform
          • AWS Console
        • Parameter Store (SSM)
        • S3
        • Secrets Manager
      • Azure Key Vault
      • Bitbucket Pipelines
      • Docker
      • Docker Compose
      • GitHub
      • GitHub Actions
      • GitLab
      • Harness
      • Jenkins
      • Kubernetes
      • Pulumi
      • Terraform
      • Terragrunt
      • Explorer
      • Circle CI
    • Events, Notifications, Webhooks
    • Types
  • 🔎REPORTING
    • Compare
    • History
    • Expirations
  • 🚀PRODUCT
    • What is CloudTruth?
    • Interactive Demo
    • Kubernetes
    • Terraform
    • CI/CD Pipeline Configuration
    • Cloud CMDB
    • Secrets Management
    • GitOps
    • Our Manifesto
    • Open Source
    • FAQs
    • Our Mission
  • 📚Reference
    • 🎓Quick Start Videos
      • What is CloudTruth?
      • CloudTruth in Action
      • Environments and Projects
      • Secrets, Parameters, ENV variables
      • Audit Logs, RBAC, SSO
      • Containers - Kubernetes, Docker
      • Infrastructure as Code (IaC) - Terraform, Cloudformation, CDK, Azure Bicep, Pulumi
      • CICD Pipelines - GitHub Actions, ArgoCD, Jenkins, CircleCI, Harness, GitLab Pipelines
      • AWS Videos - Secret Manager, Parameter Store, S3, IAM
      • Azure Videos - Azure DevOps, Azure Bicep, PowerShell
    • Knowledge Base
      • Best Practices
        • Versioned Releases
      • CLI
        • History comparison of deleted parameters with null values
      • Integrations
        • Advanced AWS IAM policy permissions
        • K8s pull image from private Docker registry
        • S3 Region Selection
      • Templates
        • Templates render quotations in key values as quot
    • Roadmap and New Features
    • JMESPath Reference
    • REST API
Powered by GitBook

Copyright© 2023 CloudTruth

On this page
  • Philosophy
  • Infrastructure
  • User Data
  • Authentication
  • Authorization
  • Audit
  • Encryption
  • Availability
  • Backups
  • Code Security
  • Admin Access

Was this helpful?

  1. Architecture

Security Overview

Philosophy

Take every precaution to prevent a compromise and limit the blast radius:

  • A compromised customer account should not allow CloudTruth or other customers' data access.

  • A compromised CloudTruth account should not allow access to customer secrets.

  • No CloudTruth service shall ever have direct public network access. Access to any service must be via a load balancer.

  • Secrets must be encrypted at rest and in transit.

  • Limit the amount of code that has access to cleartext secrets. This includes third-party libraries.

  • CloudTruth employees should not have access to customer secrets in plaintext without customer approval. All secret access must be audited.

Infrastructure

Our multitenant infrastructure runs in AWS spread across 3 availability zones in the us-east-2 region. Our service is split into 2 ECS clusters, with strict security group configurations on each. We strongly follow the principle of least privilege on all security groups and IAM policies.

The 2 clusters:

  1. The main app: api, docs, and web service

  2. Internal vault: CloudTruth's main vault, used to manage certificates and JWT validation

All ECS clusters are in a private VPC, with the only public access being from the Application Load Balancers to the API, docs, and Web App endpoints. We also use a Bastion host for admin access.

User Data

Non-secret data

Non-secret parameters and other non-secret data are stored in a multitenant Postgresql database hosted by AWS RDS. All queries are scoped by the organization id of the user performing the operation. The scoping is performed on the backend and is not dependent on the user's information. The organization id is fetched from the user's JWT, which is created and signed by Auth0.

Secrets

In addition to the guardrails provided for non-secret data, an additional level of encryption is used to store Secrets in our Postgresql database. The encryption keys for this come from a unique data key generated for each customer organization using AWS KMS (the Envelope Encryption Method). The capability for a customer to provide their own KMS keys is available for our Enterprise subscription level. Doing so grants an additional level of insurance by allowing customers to revoke our access to their KMS key, immediately removing our ability to decrypt their secrets without needing us in the loop.

Data Locations

CloudTruth offers several operating modes that control how customer data is stored.

  1. Import into CloudTruth

    1. In this mode, your config data is stored in a CloudTruth managed AWS RDS instance.

  2. Integrate with an external parameter or secret store

    1. In this mode, your config data remains in a location you control. This could be AWS Parameter Store, Secrets Manager, Azure Key Vault, HC Vault, or Git repos.

    2. CloudTruth makes a "symlink" to the external location and passes the values through the platform encrypted. The customer ultimately enforces the security controls and grants CloudTruth access to the locations.

Authentication

We use Auth0 as our Authentication provider. They allow users to authenticate with a username/password or with various social identity providers, such as Google, Microsoft, GitHub, etc. It also means we never have access to user passwords - that is only ever known by Auth0 (when using username/password auth) or the identity provider (Google, Microsoft, GitHub, etc.)

When a user logs into the system (via Auth0), we get a JSON Web Token (JWT) in return with the user's id and their organization membership. All operations in the system require the JWT and are restricted to the organization contained in the JWT. The only exceptions are access to documentation (no auth required) and API-key authentication.

API keys

API Keys provide a convenient mechanism for authenticating automation systems, such as scripts and CI/CD pipelines. Any user with owner or admin permissions can create an API key. The user cannot create an API key with permissions greater than their own permissions, but they can reduce the access of the API key. Behind the scenes, the system will exchange the API key for a JWT from Auth0. The JWT is then used in all other operations. We'll cover more about how this exchange happens in another post.

Authorization

We have 2 different authorization systems:

  1. Org membership, determined by the JWT

  2. Role-based access controls (RBAC)

Org membership

The org membership authorization is performed early in the lifecycle of the request. You'll notice that our APIs don't ask for an organization id in any calls because the organization id is part of the JWT. This makes it impossible to query for things outside your currently active org. This carries all the way down to secret access.

Role-based Access Controls

We have implemented 4 roles as described below:

  1. Owner - the org owner(s). Full permissions in the account.

  2. Admin - Full permissions to the account except for account management (subscription changes, org deletion, etc.)

  3. Contributor - Full permissions on projects, environments, parameters, and secrets. Cannot perform system operations like account management, user management, add/remove integrations, or view audit logs.

  4. Viewer - read-only access to parameters.

Audit

All operations are logged with the user who performed the operation and when it occurred. Some operations have more detail logged, such as whether a push integration was successful. This immutable log records all operations regardless of source (UI, CLI, or API). The audit log is available to owners and admins and can be exported in JSON format.

Encryption

We take advantage of AWS encryption services for all supported products. For example, all EBS volumes and all S3 buckets are encrypted. In addition, we also maintain a chain of certs and keys used for TLS encryption. Our internal Vault service rotates the certs and keys frequently and rolls out automatically.

Network encryption

All network communications are encrypted with TLS v1.2 or later. All certificates are verified. This includes all internal service-to-service communications. There are no exceptions.

Data at rest

All customer data is encrypted at rest. This includes our main Postgresql database, all assets stored in S3, and all node-local storage to EBS volumes.

Availability

Our multitenant infrastructure runs in the us-east-2 region, is redundant across 3 availability zones and is configured for autoscaling via Spot by NetApp.

Backups

We take regular, automated snapshots of our database and additional snapshots preceding any admin operation.

Code Security

Our repositories require SSO from our corporate identity provider to access our internal repositories. Our code is scanned for viruses and vulnerabilities on every build, a process baked into our build automation. We also use multiple static code analysis tools to ensure we adhere to best practices. We measure code coverage on all components and maintain a high level of coverage. We use dependabot to keep all of our dependencies up to date.

Admin Access

We have no "God" accounts, but we have admins with privileged access to various systems. Access is achieved via a bastion host, which is limited to a whitelist of IP addresses of our admins. We also require MFA for admins. This includes running any out-of-cycle deploy code.

All privileged account access is audited using a combination of tools, notifications, and scheduled procedures.

PreviousArchitectureNextCopilot

Last updated 1 year ago

Was this helpful?

🔒