new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Temporal · all subjects

authentication/best-practices

19 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Audit Logging

Audit Logging is a feature that provides forensic access information for accounts, users, and Namespaces.

End-to-end credential rotation process

The high-level end-to-end rotation process consists of five steps: (1) Generate new credentials by creating new certificates or API keys before current ones expire, (2) Support dual credentials by updating Temporal Cloud to support both old and new credentials, (3) Migrate Workers by transitioning Worker applications from old to new credentials, (4) Validate connectivity by confirming all Workers can authenticate and business processes operate normally, (5) Remove old credentials from secrets provider after confirming successful migration.

Credential rotation enables near-zero-downtime updates

The end-to-end rotation process ensures near-zero-downtime rotation and prevents authentication failures that could impact running workflows.

Default authentication method recommendation

By default, teams should use API keys with service accounts for both client connections and automation. API keys are generally easier to set up and rotate than mTLS certificates, and service accounts allow assignment of account-level and namespace-level roles.

When to use mTLS vs API keys

If your organization requires mutual authentication and stronger cryptographic guarantees, use mTLS certificates to authenticate Temporal clients to Temporal Cloud and use API keys for automation, because the Temporal Cloud Operations API and Terraform provider only support API key authentication.

Align access boundaries with Namespace boundaries

The way you partition Namespaces should usually match the way you partition machine identities. If multiple services share a Namespace, you may still want one Service Account per service so each deployment can rotate credentials independently. If you split workloads into separate Namespaces, those Namespaces should usually have separate Service Accounts and API keys as well.

Namespace-per-tenant credential and RBAC model

If you use Namespace-per-tenant isolation, expect your credential model and RBAC model to become correspondingly more granular.

Credential rotation sequence for API keys

For API keys, create the new valid key while the old key still works, then roll your Workers and clients to use the new key.

Certificate rotation staging for client certificates

For client certificates, stage the new certificate before removing the old one when your deployment process supports that transition.

Validate connectivity after credential rotation

Validate connectivity and normal Workflow execution using the new credential before removing the old credential.

Remove old credentials only after successful migration

Remove the old credential only after all clients and Workers have switched to the new credential.

Temporal Cloud manages server-side updates while SDKs require manual updates

Temporal Cloud server-side updates are handled by the vendor, but Temporal SDKs (in application code) should be kept up-to-date. Subscribe to Temporal's security updates on the Temporal Trust Portal to be aware of any patches or CVEs that may affect your SDKs.

Enable SAML Single Sign-On for Temporal Cloud access

Integrate Temporal Cloud with your organization's identity provider via SAML 2.0 for centralized authentication. This allows you to enforce your corporate login policies such as MFA and password complexity. When SAML is configured with Temporal Cloud, you can disable social logins (Microsoft, Google) by opening a support ticket.

Use least-privilege roles for Temporal Cloud users

Temporal Cloud provides preconfigured account-level roles (Account Owner, Finance Admin, Global Admin, Developer, Read-Only) and Namespace-level permissions. Assign users the lowest level of access they need. For example, give developers access only to the Namespaces they work on, and use read-only roles for auditors or reviewers. Regularly review user roles and remove or downgrade accounts that are no longer needed.

Use Service Accounts for non-human access in Temporal Cloud

For non-human access such as CI/CD pipelines and backend services, use Temporal Cloud Service Accounts instead of shared user logins. Service Accounts are machine identities that can be granted specific permissions without ties to an individual. Create separate Service Accounts with unique API keys for different applications or microservices, and apply least privilege to each—for example, a service account that only has access to one Namespace.

Best practices for handling Temporal Cloud API keys

If using API keys for authentication of SDKs, CLI, and automation, handle them with strict care: keep them secret in a secrets manager (never in code or Git); rotate at least every 90 days (create a new key, swap it in, then delete the old one); use one key per service/person with no sharing or reuse; monitor usage and revoke on anomalies by feeding Temporal audit logs to SIEM; optionally, admins can disable all user API keys if the policy is 'mTLS only'.

Use private connectivity for Temporal Cloud

Temporal Cloud supports private connectivity options such as AWS PrivateLink and Google Cloud Private Service Connect. If your infrastructure is in AWS or GCP, configure a PrivateLink or Private Service Connect endpoint for Temporal Cloud. This allows your workers and applications to reach Temporal Cloud over a private network path, avoiding traversal of the public internet. Private connectivity reduces the surface for man-in-the-middle attacks and can meet stringent network security policies.

Leverage SCIM or automated user provisioning for Temporal Cloud

Use SCIM or the Temporal Cloud user management API to automate adding and removing user accounts. This ensures timely removal of access when people change roles or leave the organization.

Separate environments by Namespace for security isolation

Use Temporal Namespaces to isolate workflows for different environments or teams (such as development, staging, production). Each Namespace is logically segregated and cannot interact with others by default, providing a security boundary. Ensure that your production Namespace uses stricter network controls (for example, only accessible from the prod network) and that credentials for it are separate from non-prod Namespaces. This limits the impact of any compromise in a lower environment.

Give your agent this brain