Skip to main content

Security model - Temporal Cloud

What kind of security does Temporal Cloud provide?

The security model of Temporal Cloud encompasses applications, data, and the Temporal Cloud platform itself.

General platform security

For information about the general security features of Temporal, see our Platform security page.

Application and data​

What is the security model for applications and data in Temporal Cloud?

Code execution boundaries​

Temporal Cloud provides the capabilities of Temporal Server as a managed service; it does not manage your applications or Workers. Applications and services written using Temporal SDKs run in your computing environment, such as containers (Docker, Kubernetes) or virtual machines (in any hosting environment). You have full control over how you secure your applications and services.

Data Converter: Client-side encryption​

The optional Data Conversion capability of the Temporal Platform lets you transparently encrypt data before it's sent to Temporal Cloud and decrypt it when it comes out.

Data Conversion runs on your Temporal Workers and Clients; Temporal Cloud cannot see or decrypt your data. If you use this feature, data stored in Temporal Cloud remains encrypted even if the service itself is compromised.

By deploying a Codec Server you can securely decrypt data in the Temporal Web UI without sharing encryption keys with Temporal.

The platform​

What is the security model for the Temporal Cloud platform?

Namespace isolation​

The base unit of isolation in a Temporal environment is a Namespace. Each Temporal Cloud account can have multiple Namespaces. A Namespace (regardless of account) cannot interact with other Namespaces. Each Namespace is available through a secure gRPC (mTLS) endpoint and an HTTPS (TLS) endpoint. You can make these endpoints more secure by routing all communication through AWS PrivateLink.

Temporal Cloud is a multi-tenant service. Namespaces in the same environment are logically segregated. Namespaces do not share data processing or data storage across regional boundaries.

AWS PrivateLink allows you to open a path to Temporal without opening a public egress. It establishes a private connection between your Amazon Virtual Private Cloud (VPC) and Temporal Cloud. This one-way connection means Temporal cannot establish a connection back to your service. This is useful if normally you block traffic egress as part of your security protocols. If you use a private environment that does not allow external connectivity, you will remain isolated.

note

If you are interested in leveraging AWS PrivateLink in your Namespaces, create a support ticket that includes the following information:

  • AWS Region: The Region in which your connection will go through.
  • AWS Account Id: The account which contains the permissions to enable AWS PrivateLink.
  • Temporal Cloud Namespace names: The name of the Namespaces you want to enable AWS PrivateLink with.

Set up PrivateLink connectivity with Temporal Cloud with these steps:

  1. Open the AWS console with the region you want to use to establish the PrivateLink.

  2. Search for "VPC" in Services and select the option.

    AWS console showing services, features, resources

  3. Select Virtual private cloud > Endpoints from the left menu bar.

  4. Click the Create endpoint button to the right of the Actions pulldown menu.

  5. Under Service category, select Other endpoint services. This option lets you find services shared with you by service name.

  6. Under Service settings, fill in the Service name with the PrivateLink Service Name for the region you’re trying to connect from:

    RegionPrivateLink Service Name
    ap-northeast-1com.amazonaws.vpce.ap-northeast-1.vpce-svc-08f34c33f9fb8a48a
    ap-northeast-2com.amazonaws.vpce.ap-northeast-2.vpce-svc-08c4d5445a5aad308
    ap-south-1com.amazonaws.vpce.ap-south-1.vpce-svc-0ad4f8ed56db15662
    ap-south-2com.amazonaws.vpce.ap-south-2.vpce-svc-08bcf602b646c69c1
    ap-southeast-1com.amazonaws.vpce.ap-southeast-1.vpce-svc-05c24096fa89b0ccd
    ap-southeast-2com.amazonaws.vpce.ap-southeast-2.vpce-svc-0634f9628e3c15b08
    ca-central-1com.amazonaws.vpce.ca-central-1.vpce-svc-080a781925d0b1d9d
    eu-central-1com.amazonaws.vpce.eu-central-1.vpce-svc-073a419b36663a0f3
    eu-west-1com.amazonaws.vpce.eu-west-1.vpce-svc-04388e89f3479b739
    eu-west-2com.amazonaws.vpce.eu-west-2.vpce-svc-0ac7f9f07e7fb5695
    sa-east-1com.amazonaws.vpce.sa-east-1.vpce-svc-0ca67a102f3ce525a
    us-east-1com.amazonaws.vpce.us-east-1.vpce-svc-0822256b6575ea37f
    us-east-2com.amazonaws.vpce.us-east-2.vpce-svc-01b8dccfc6660d9d4
    us-west-2com.amazonaws.vpce.us-west-2.vpce-svc-0f44b3d7302816b94

  7. Confirm your service by clicking on the Verify service button. AWS should respond "Service name verified."

    The service name field is filled out and the Verify service button is shown

  8. Select the VPC and subnets to peer with the Temporal Cloud service endpoint.

  9. Select the security group that will control traffic sources for this VPC endpoint. The security group must accept TCP ingress traffic to port 7233 for gRPC communication with Temporal Cloud.

  10. Click the Create endpoint button at the bottom of the screen. If successful, AWS reports "Successfully created VPC endpoint." and lists the new endpoint. The new endpoint appears in the Endpoints list, along with its ID.

    The created endpoint appears in the Endpoints list

  11. Click on the VPC endpoint ID in the Endpoints list to check its status. Wait for the status to be “Available”. This can take up to 10 minutes.

  12. Once available, you can use AWS PrivateLink. Use the first value under “DNS names” as your hostname to connect to Temporal Cloud using port 7233. To establish a valid mTLS session, you must override the TLS server name used for the connection to <namespace>.<account>.tmprl.cloud.

    Highlighted DNS names section shows your hostname

You are ready to start using Private Link with Temporal Cloud.

tip

PrivateLink endpoint services are regional. Individual Namespaces do not use separate services.

Once set up, you can test your PrivateLink connectivity using the following methods. When connecting, you must override the TLS server name to target your Namespace’s individual hostname (<namespace>.<account>.tmprl.cloud) to establish a valid mTLS session:

  • The Temporal CLI, using the --tls-server-name parameter to override the TLS server name. For example:

    temporal workflow count \
        --address <DNS associated with VPC endpoint>:7233 \
        --tls-cert-path /path/to/client.pem \
        --tls-key-path /path/to/client.key \
        --tls-server-name <namespace>.<account>.tmprl.cloud \
        --namespace <namespace>

  • Non-Temporal tools like grpcURL, useful for testing from environments that restrict tool usage, using the -servername parameter to override the TLS server name. For example:

    grpcurl \
        -servername <name>.<account>.tmprl.cloud \
        -cert /path/to/client.pem \
        -key /path/to/client.key \
        vpce-XXXXXXXXX.vpce.amazonaws.com:7233 \
        temporal.api.workflowservice.v1.WorkflowService/GetSystemInfo

  • Temporal SDKs, by setting the endpoint server address argument to the PrivateLink endpoint (<DNS associated with VPC endpoint>:7233) and using the TLS configuration options to override the TLS server name.

Encryption​

Communication into and out of Namespaces is over TLS. All communication within our production environments is over TLS 1.3. Data is stored in two separate locations: an Elasticsearch instance (used when filtering Workflows in SDK clients, the CLI, or the Web UI) and the core Temporal Cloud persistence layer. Both are encrypted at rest with AES-256-GCM.

For more information, see Requirements for CA certificates in Temporal Cloud.

Identity​

Authentication to gRPC endpoints is provided by mTLS per Namespace.

For more information, see How to manage SAML authentication with Temporal Cloud.

Access​

Authorization is managed at the account and Namespace level. Users and systems are assigned one or more preconfigured roles. Users hold account-level Roles of administrators, developers, and read-only users. Systems and applications processes hold their own distinct roles.

Monitoring​

In addition to extensive system monitoring for operational and availability requirements, we collect and monitor audit logs from the AWS environment and all calls to the gRPC API (which is used by the SDKs, CLI, and Web UI). These audit logs can be made available for ingestion into your security monitoring system.

Testing​

We contract with a third party to perform a full-scope pentest (with the exception of social engineering) annually. Additionally, we perform targeted third-party and internal testing on an as-needed basis, such as when a significant feature is being released.

Internal Temporal access​

We restrict access to production systems to the small team of employees who maintain our production infrastructure. We log all access to production systems; shared accounts are not allowed. Access to all production systems is through SSO, with MFA enabled.

Access to AWS is granted only for limited periods of time, with a maximum of 8 hours. (For more information, see the blog post Rolling out access hours at Temporal.)

All Temporal engineering systems are secured by GitHub credentials, which require both membership in the Temporal GitHub organization and MFA. Access grants are reviewed quarterly.

Compliance​

Temporal Technologies is SOC 2 Type 2 certified and compliant with GDPR and HIPAA regulations. Compliance audits are available by request through our Contact page.