What security controls and protocols are implemented by Ternary?

Ternary’s operations require controlled access to customer cloud environments to support cost analysis and reporting. As a result, security and access management are designed to meet the expectations of enterprise-grade security standards.

Ternary implements a comprehensive set of controls across data access, identity management, and infrastructure to ensure customer environments remain secure. These controls are aligned with industry best practices and are designed to support strict security and compliance requirements.

Internal IT controls

• Customer data stored in Ternary’s cloud environment is maintained in datasets and storage buckets with public access disabled. IAM policies restrict access to authorized personnel only.
• Access to production systems and customer data is limited to a subset of Ternary employees based on role requirements. Access is managed through group-based controls rather than individual assignments, with IAM policies defined and maintained using Terraform.
• Role-based access follows a least-privilege model. Different employee groups are granted only the permissions required for their responsibilities. For example, engineering roles may have read-write access, while customer-facing roles have read-only access.
• Audit logs are generated and retained for all authorized operations across both Google Cloud and the Ternary platform. Any access to customer data is logged for traceability.
• All employee devices are managed through a mobile device management (MDM) solution that enforces security policies such as password requirements, screen locks, location tracking, and remote wipe capabilities.

Production controls

• Ternary production infrastructure is organized into three Google Cloud projects:
  1. ternary-prod: Hosts the web application, task runner, APIs, and core infrastructure.
  2. ternary-prod-cacc: Dedicated to service accounts used for customer cloud access (cacc stands for customer access). No direct employee access is granted by default. Access can only be provisioned by Organization Administrators when required.
• Data processing, compute, and storage are hosted in the Google Cloud US multi-region where available, and in the us-central1 region when a specific region is required. If source data is located outside these regions, it is copied securely using Cloud Storage.
• The Ternary web application operates using a dedicated service account: [email protected] This account has access to the internal data model in Firestore to support application functionality.
• Background data processing is handled by a separate service account: [email protected] This account is triggered by Cloud Scheduler and Cloud Tasks to run periodic jobs that keep customer data up to date.
• The apiserver and taskrunner service accounts can impersonate tenant-specific service accounts that are granted access to customer environments. These accounts do not have default access to customer data and only inherit permissions during the active impersonation session.
• Web-based access to BigQuery data is managed through our private Analytics API. Access is restricted using user-scoped tokens, ensuring queries are limited to the datasets that the customer is allowed to access. This service account cannot impersonate customer service accounts and only accesses data already stored within Ternary.

Customer data model

A dedicated BigQuery dataset is created for each customer within ternary-prod. This dataset is used to store customer-specific data. The dataset includes:

• Copies of billing exports from connected cloud providers
• Copies of developer metrics (for example, Stackdriver and CloudWatch)
• Cloud resource metadata and manifests, where applicable
• Processed information from BigQuery INFORMATION_SCHEMA (GCP only)

Customer data is isolated at the dataset level. All sensitive billing and usage data resides within this dataset.

User data, access controls, and non-sensitive metadata are stored in Google Cloud Firestore. This data is logically scoped to each tenant, though not physically isolated across separate environments.

Data stored in BigQuery is retained for one year by default. Retention periods can be adjusted on a per-tenant basis.

Service account

• A unique service account is created for each customer to manage access to their cloud environment. This ensures that no single service account has direct access to multiple customers.
• Access to customer environments is performed using this tenant-specific service account. Other internal service accounts and authorized personnel may impersonate this account on-demand. All impersonation activity is logged and available for audit.
• Service account identifiers follow the format: [email protected] The suffix is randomly generated, is not related to the other tenant identifiers, and cannot be mapped back to a specific customer.

Customer access controls - Principles

The following principles define how Ternary accesses and interacts with customer cloud environments:

• The user-facing application does not directly access customer cloud environments. All analysis is performed on data that has been securely copied and ingested into Ternary’s data store.
• Access to customer cloud environments is performed using a tenant-specific service account. Each service account is scoped to a single customer and is not shared across environments.
• Cloud access is executed through a separate runtime and security context from the web application. This separation ensures that vulnerabilities in the application layer cannot be used to directly access customer cloud resources.
• Access to customer environments is performed through controlled, asynchronous processes that assume the tenant-specific service account only for the duration of the required operation.
• No service account keys, access keys, or secret keys are generated, stored, or exchanged. Authentication is implemented using secure, cloud-native identity mechanisms. Integrations that rely on static credentials are not supported.

Customer access controls - Implementation by cloud provider

Subsequent sections describe how access is configured for each supported cloud provider, including the required permissions and their purpose.

Google Cloud

Access is granted by assigning IAM roles to the Ternary tenant service account. Since Ternary is deployed on Google Cloud itself, no additional identity federation or cross-cloud indirection is required.

Permissions can be applied at the project, folder, or organization level, depending on the required scope.

Permissions The following roles are assigned to the Ternary service account, along with their intended use cases:

Amazon Web Services

Ternary uses a Federated identity approach to access customer environments in Amazon Web Services.

AWS recognizes Google Cloud as a federated identity provider. Ternary uses Google service account tokens with AssumeRoleWithWebIdentity to access AWS resources. This approach essentially allows us to use your tenant specific GCP service account to access AWS. It does not require static credentials, keys, or secrets to be generated, stored, or transmitted, nor does the IAM role configured in AWS grant access to any other service account but your private tenant service account.

For more information on these approaches, refer to AWS onboarding documentation.

Permissions

The following permissions are required to support data ingestion, monitoring, and optimization:

• Amazon S3: Used to collect storage usage and optimization data. s3:ListAllMyBuckets, s3:GetLifecycleConfiguration
• CloudWatch: Used to collect operational and usage metrics across AWS services.
  GetMetricData, cloudwatch:ListMetricStreams, cloudwatch:ListTagsForResource, cloudwatch:GetMetricStatistics, cloudwatch:ListMetrics
• Compute Optimizer: Used to retrieve AWS-generated optimization recommendations. compute-optimizer:GetEC2InstanceRecommendations, compute-optimizer:GetAutoScalingGroupRecommendations, compute-optimizer:GetEBSVolumeRecommendations, compute-optimizer:GetLambdaFunctionRecommendations
• RDS: Used to retrieve AWS-generated recommendations for RDS. rds:DescribeReservedDBInstancesOfferings
• Cost Explorer: Used to retrieve cost optimization recommendations. ce:GetReservationPurchaseRecommendation, ce:GetSavingsPlansPurchaseRecommendation, ce:GetRightsizingRecommendation
• EC2 and Lambda: Used to collect compute resource metadata and usage information. EC2:DescribeVolumes, EC2:DescribeInstances, lambda:ListFunctions, lambda:ListProvisionedConcurrencyConfigs

The most current list of permissions can be found here.

Microsoft Azure

Access to Azure customer data is configured using a tenant-specific client certificate. Each certificate is uniquely generated per customer and signed by a Ternary-managed root authority.

The root authority is self-signed and available through Ternary’s official documentation. The public certificate is shared with the customer and used to grant access to Azure resources.

The certificate’s private key is not exposed in plain text. It is securely stored in Google Cloud Secret Manager and retrieved only when required by controlled background processes. The public key remains accessible to the customer for validation and access configuration.

Additional details on certificate validation and setup are available in the Azure onboarding documentation.

Permissions

Access is limited to billing data ingestion. Read permissions are granted to the storage container that contains Azure billing data, and access is performed using the client certificate identity.