SaaS Runtime overview

SaaS Runtime lets you store, host, manage, and monitor software as a service (SaaS) applications on Google Cloud. SaaS Runtime manages Terraform deployments at scale, allowing you to manage both your SaaS application and the infrastructure that it runs on.

SaaS Runtime can be used in many ways by a variety of stakeholders within the SaaS pipeline. If your work identifies with any of these roles, you may be interested in using SaaS Runtime:

  • Platform administrator
  • Application developer
  • Architect
  • Compliance administrator
  • Platform engineer
  • Finance operations

SaaS Runtime provides the following benefits:

  • Simplify your service management at scale by automating service management tasks (such as deployment, rollouts, and feature flag management) across your SaaS tenants.
  • Expand your observability and control by fine tuning your updates and releases across configurable units to manage your SaaS offering with precision at scale.
  • Build consistency across your Google Cloud ecosystem by managing services across various Google Cloud products including Google Cloud, Google Distributed Cloud, Billing, Observability, and Resource Manager.
  • Use flexible and templatizable architecture that promotes unit-based group updates and deployments for improved efficiency and reusability.

How does SaaS Runtime work?

SaaS Runtime deploys artifacts that define your SaaS offering. These artifacts must have a Terraform configuration. The deployment is organized into distinct units that can be updated with releases containing changes to your offering through a configurable rollout process.

For more information about SaaS Runtime nomenclature, see the Glossary.

Prepare your workload for SaaS Runtime

Before you deploy your SaaS offering, we recommend that you determine the ideal arrangement of your SaaS offering within the SaaS Runtime ecosystem.

Organize parts of your SaaS offering that should be updated or modified together into distinct Terraform configurations. As you plan your SaaS offering, use unit kinds for each grouping of your SaaS offering.

Once you've worked out the ideal structure for your workload on SaaS Runtime, you can create your SaaS offering, unit kinds, and then deploy your units using a rollout.

For an example of the setup for SaaS Runtime, see the quickstart.

SaaS Runtime service accounts

SaaS Runtime uses a combination of Google-managed and user-managed service accounts:

  • SaaS Runtime service account (Google-managed): This account is automatically created after creating the first SaaS offering resource. It is managed by Google. It performs actions on your behalf, such as interacting with other Google Cloud services during unit provisioning.

  • Actuation service account (User-managed): You create and manage this service account. SaaS Runtime (via Infrastructure Manager) uses this account to execute your Terraform configurations when provisioning or updating units. This account acts as the identity for creating and managing the resources defined in your Terraform. The actuation service account permissions are directly tied to the resources your Terraform configuration manages.

    You can have multiple actuation service accounts. We recommend that you should have one actuation service account for each tenant.

  • Optional: Artifact creation service account (User-managed): This service account is used for building and uploading your Terraform packaged into OCI artifacts. This is often a Cloud Build service account, but it can be any service account with appropriate permissions for your SaaS offering.

SaaS Runtime service account (Google-managed)

The SaaS Runtime service account is a Google-managed P4SA service account used by SaaS Runtime to perform operations within your project.

This service account is automatically provisioned when you create your first SaaS Runtime resource. The SaaS Runtime service account is created using this format:

  service-PROJECT_NUMBER@gcp-sa-saasservicemgmt.iam.gserviceaccount.com

Replace:

  • PROJECT_NUMBER: Your project number.

Required Permissions

SaaS Runtime requires specific IAM roles to be granted to this service account:

  • roles/artifactregistry.admin: Grants full control of Artifact Registry
  • roles/storage.admin: Grants full control of Cloud Storage.
  • roles/config.admin: Grants full control of Infrastructure Manager.
  • roles/iam.serviceAccountShortTermTokenMinter: Grants Infrastructure Manager permission to start Cloud Build jobs.
  • roles/iam.serviceAccountUser: Grants SaaS Runtime usage of Infrastructure Manager. Allows Infrastructure Manager to create Terraform resources.

Actuation service account (User-managed)

The actuation service account is a user-managed service account that you must create. SaaS Runtime (via Infra Manager) uses this service account to execute your Terraform configurations. It's the identity that creates, modifies, and deletes the resources defined in your Terraform.

You are responsible for creating this service account within your project, or within your tenant project.

Actuation service account input variables

When you create a unit, you must provide the actuation service account as an key-value pair input variable for the Terraform configuration:

  • Name: actuation_sa
  • Variable type: String

  • Variable value: Actuation service account email address:

    my-actuation-sa@my-identifier.iam.gserviceaccount.com

Required Permissions

The actuation service account requires sufficient permissions to manage the resources defined in your Terraform configuration. At a minimum, it needs:

  • roles/iam.serviceAccountTokenCreator: Allows the service account to generate tokens for authentication.
  • roles/cloudinfrastructuremanager.admin: Grants full control over Infra Manager resources.
  • roles/storage.admin: Grants full control of Cloud Storage.

The actuation service account also needs permissions to create and manage the specific Google Cloud resources used by your application.

For example:

  • If your Terraform creates Google Kubernetes Engine (GKE) clusters, the service account needs appropriate GKE roles (roles/container.admin, for example).
  • If your Terraform creates Compute Engine instances, the service account needs the roles/compute.admin role.
  • If your Terraform creates Cloud SQL instances, the service account needs the appropriate Cloud SQL roles (roles/cloudsql.admin, for example).

Consult the documentation for each Google Cloud resource you use in your Terraform to determine the necessary permissions. Grant the least privilege necessary for your application to function.

Artifact creation service account (User-managed)

The artifact creation service account is a user-managed service account you create to use a build system (such as Cloud Build) to package and upload your Terraform artifacts to Artifact Registry.

This service account is separate from the SaaS Runtime and actuation service accounts, and builds your Terraform code and pushes the resulting artifact to Artifact Registry. Often, this is the Cloud Build service account.

Manual artifact creation

If you manually build and upload your Terraform artifacts (using Docker build and Docker push directly, for example), you don't need a separate artifact creation service account.

Instead, you should authenticate using your own credentials or a service account with the necessary Artifact Registry permissions.

Required Permissions

If you are using Cloud Build, the Cloud Build service account typically needs the following roles:

  • roles/artifactregistry.writer: To push artifacts to Artifact Registry.
  • roles/artifactregistry.repoAdmin: To manage the Artifact Registry repository.
  • roles/storage.admin: To manage the Cloud Storage buckets.
  • roles/developerconnect.admin: Permissions to use Developer Connect.
  • roles/developerconnect.readTokenAccessor: Permissions to get Developer Connect read token.
  • roles/logging.logWriter: Permissions to write logs.
  • If you are deploying your Terraform configuration using Developer Connect: roles/cloudbuild.builds.builder: To execute builds.
  • Any other permissions required by your build process (for example, access to source code repositories).

What's next