[Bug] Developer service account unable to import itself due to invalid `account_access` field

[aevv]

What are you really trying to do?

Use an API key created by a service account with role developer to import itself. Using Temporal Cloud.

Describe the bug

When importing a service account, if the service account is set to the developer role in the UI, the account_access field of temporalcloud_service_account is returned as none, which is an invalid field. Using a developer service account to import itself, it becomes impossible to import as the service account does not have permissions to change the role of itself from none to developer. As none is an invalid field for account_access, it's not possible to import the service account by setting that value.

Attempting to apply the plan gives the error:

Manually adjusting the role of the service account to Global Admin correctly imports account_access as admin. Changing back to developer, results in none being imported again.

Attempting to apply the plan when going from admin to developer results in an error:

Minimal Reproduction

This HCL (with variables + backend set):

terraform {
  required_providers {
    temporalcloud = {
      source  = "temporalio/temporalcloud"
      version = "~> 0.7"
    }
  }
}

provider "temporalcloud" {
  allowed_account_id = var.account_id
  api_key            = var.api_key # API key created by the service account which is being imported. sensitive key retrieved from a keyvault in reality, `var.` used for illustration
}

import {
  to = temporalcloud_service_account.service_account
  id = var.service_account_id # Existing service account ID with `developer` role, which owns the API key above
}

resource "temporalcloud_service_account" "service_account" {
  name           = var.name
  account_access = "developer"

  lifecycle {
    prevent_destroy = true
  }
}

Results in following plan output:

  # temporalcloud_service_account.service_account will be updated in-place
  # (imported from "{redacted}")
  ~ resource "temporalcloud_service_account" "service_account" {
      ~ account_access = "none" -> "developer"
        id             = "{redacted}"
        name           = "sample_name"
        state          = "active"
    }

Environment/Versions

• OS and processor: x64 Windows, Linux
• Temporal Version: Terraform Provider Version 0.7.0, Temporal Cloud

Additional context

[aevv]

A similar issue appears present with the namespace access, where even when present on the identity they're not returned to the provider and so plan/apply are failing due to incompatible changes

[briankassouf]

Hi @aevv thanks for the report. Our APIs do not return access settings of Users or Service Accounts to principals authenticated with the Developer Role.

I'm curious if you can share more about your use case here, why do you need to import the service account? Since you are using a Developer role for your terraform API Key it will be unable to manage the lifecycle of Service Accounts and Users.

[aevv]

Hi @briankassouf

We use this service account to own API keys which our services use to communicate with Temporal Cloud, ensuring they're scoped to the correct namespaces to avoid services starting workflows or accessing data they shouldn't.

Generally, we terraform as much as possible to ensure we can handle any disaster situations, no matter how unlikely. Being able to run pipelines in that situation ensures we have business continuity. By not being able to re-create our terraform setup from scratch we don't achieve this goal.

What would you suggest we do? Should we have an admin service account which can create the other accounts and then use the developer account to restrict API key access?

Either way, the provider shouldn't error out in this way and should handle this or make it clearer that it works this way

Cheers

[gregmankes]

Hey @aevv, if you want to manage other service accounts or permissions you need to use a terraform token with admin privileges.

See:
https://docs.temporal.io/cloud/api-keys#manage-api-keys
https://docs.temporal.io/cloud/users#account-level-roles

Separately, we're looking at the API and seeing if we can improve the error messaging/handling.

[bechols]

We will retest this, but the API has been updated to throw a more accurate “permission denied” error.

Terraform requires an admin role when importing and deleting a service account.