Workflows security overview

Because a workflow contains no code or library dependencies, it does not require security patches. Once you deploy a workflow, you can expect it to reliably execute without maintenance. In addition, Workflows offers several security features and takes specific compliance measures to satisfy enterprise security requirements.

Data encryption

By default, Google Cloud uses several layers of encryption to protect user data that's stored in Google production data centers. This default encryption occurs at the application or storage infrastructure layer. Traffic between your devices and the Google Front End (GFE) is encrypted using strong encryption protocols such as Transport Layer Security (TLS). Your data in use is protected, and confidentiality for workloads in a multi-tenant cloud environment is maintained, by performing computation in cryptographic isolation. For more information about the main security controls that Google Cloud uses to help protect your data, see Google security overview.

Identity and access management

Since every workflow execution requires an authenticated call, you can mitigate the risk of accidental or malicious calls by using Workflows. Workflows manages access and authentication using Identity and Access Management (IAM) roles and permissions. You can simplify interactions with other Google Cloud APIs by using IAM-based service accounts. For details, see Grant a workflow permission to access Google Cloud resources and Make authenticated requests from a workflow.

Private endpoints

Workflows can invoke a private on‑premises, Compute Engine, Google Kubernetes Engine (GKE), or other Google Cloud endpoint through an HTTP request. You must enable Identity-Aware Proxy (IAP) for the private endpoint so that Workflows can invoke the endpoint. For more information, see Invoke a private on‑prem, Compute Engine, GKE, or other endpoint.

Workflows can also invoke Cloud Functions or Cloud Run services in the same Google Cloud project that have ingress restricted to internal traffic. With this configuration, your services are unreachable from the internet but can be reached from Workflows. To apply these restrictions, you must adjust the ingress settings of your service or function. Note that the Cloud Run service must be reached on its run.app URL and not at a custom domain. For more information, see Restricting ingress (for Cloud Run) and Configuring network settings (for Cloud Functions). No other changes are needed to your workflow.

Customer-managed encryption keys (CMEK)

If you have specific compliance or regulatory requirements related to the keys that protect your data, you can use customer-managed encryption keys (CMEK) for Workflows. Your workflow and associated data at rest are protected using an encryption key that only you can access, and that you can control and manage using Cloud Key Management Service (Cloud KMS). For more information, see Use customer-managed encryption keys.

VPC Service Controls (VPC SC) support

VPC Service Controls is a mechanism to mitigate data exfiltration risks. You can use VPC Service Controls with Workflows to help protect your services. For more information, see Set up a service perimeter using VPC Service Controls.

Secret Manager to store and secure sensitive data

Secret Manager is a secure and convenient storage system for API keys, passwords, certificates, and other sensitive data. You can use a Workflows connector to access Secret Manager within a workflow. This simplifies the integration for you, because the connector handles the formatting of requests, and provides methods and arguments so that you don't need to know the details of the Secret Manager API. For more information, see Secure and store sensitive data using the Secret Manager connector.

Integration with Cloud Logging, Cloud Monitoring, and Cloud Audit Logs

Logs are a primary source of diagnostic information about the health of your workflows. Logging allows you to store, view, search, analyze, and alert on log data and events.

Workflows is integrated with Logging and automatically generates execution logs for workflow executions. Because of the streaming nature of Logging, you can view the logs that any workflow emits immediately, and you can use Logging to centralize logs from all your workflows. You can also control when logs are sent to Logging during a workflow execution through call logging or custom logs. For details, see Send logs to Logging.

In addition to consuming logs, you typically need to monitor other aspects of your services to ensure reliable operation. Use Monitoring to get visibility into the performance, uptime, and overall health of your workflows.

To track and maintain details of interactions with your Google Cloud resources, you can use Cloud Audit Logs to help capture activity such as data access. Use IAM controls to limit who can view audit logs. For more information, see Workflows audit logging information.

Compliance with standards

To confirm Workflows' compliance with various standards, see Compliance controls.

What's next