Terraform providers

No row carries ARM_SUBSCRIPTION_ID, even though azurerm v4+ makes it mandatory: init, plan, apply, and import carry a scope_id, and the sidecar injects it as ARM_SUBSCRIPTION_ID into the engine subprocess for that one command, overriding whatever the container holds.

OIDC rows leave out ARM_OIDC_REQUEST_URL/_TOKEN because the CI runner injects them.

Import discovery (/v1/import/scope-resource-ids) reads the credential variables through azure-identity — the subscription it lists comes from the request’s scope_id, never from the environment. Three exceptions: the az login row has no equivalent (discovery needs a service principal, a managed identity, or a workload identity); the OIDC rows need the assertion itself in ARM_OIDC_TOKEN or ARM_OIDC_TOKEN_FILE_PATH, because the ARM_OIDC_REQUEST_URL exchange the CI runner performs is not reimplemented here; and only the direct ARM_CLIENT_ID/ARM_CLIENT_SECRET forms are read, not the ARM_CLIENT_ID_FILE_PATH/ARM_CLIENT_SECRET_FILE_PATH ones the provider also accepts (see Complete variable reference) — a deployment using those runs every command fine and fails discovery with no Azure credentials configured. ARM_ADO_PIPELINE_SERVICE_CONNECTION_ID is likewise provider-only, and ARM_ENVIRONMENT is ignored: discovery talks to the public cloud only.

AWS_REGION (or AWS_DEFAULT_REGION) is required in every row: the account check below needs it, and it is the default region for generated code.

Account. Do not set TF_VAR_aws_account_id; the sidecar injects scope_id as TF_VAR_aws_account_id for init, plan, apply, and import. The generated code passes it to the provider, which then refuses any other account:

Before those four commands the sidecar also calls STS GetCallerIdentity with the container’s credentials, and ends the command with exit code 1, without starting the engine, when the account is not scope_id. One deployment therefore serves one AWS account; a hub deployment that assumes a role into each target account is refused. For LocalStack the scope_id is its account id, 000000000000.

Region. The region is not part of the scope. The provider takes the first of:

New generated code sets no provider region, so every session that does not name a region lands in the container’s AWS_REGION. A request that names one gets the per-resource region argument (provider v6) or a provider alias. An existing provider region is kept as it is, so with AWS_REGION=us-east-1 on the container:

A region variable the provider block does not reference changes nothing: the provider falls back to AWS_REGION.

Running the code outside Kumoss. Code merged to a repository declares aws_account_id with no default, so a pipeline that runs it needs TF_VAR_aws_account_id=<account id> (and a region) in its own environment.

Import discovery additionally requires AWS Resource Explorer to be enabled for the account, with an aggregator index and a default view. Every row above works for it except LocalStack, which has no Resource Explorer to query, since boto3’s default chain resolves the same credentials the provider does. Two details are discovery’s alone: it reads the region from AWS_REGION/AWS_DEFAULT_REGION only, so the region a profile names does not satisfy it, and it does not select the account either — it calls STS and fails if the resolved account is not the requested scope_id.

GOOGLE_REGION/GOOGLE_ZONE are optional, but leaving them out forces explicit region/zone on many resources.

No row carries GOOGLE_PROJECT either, for the same reason as ARM_SUBSCRIPTION_ID above: the sidecar injects the request’s scope_id under that name for init, plan, apply, and import. It sets GOOGLE_PROJECT specifically, which outranks the GOOGLE_CLOUD_PROJECT/GCLOUD_PROJECT/CLOUDSDK_CORE_PROJECT aliases (see Complete variable reference), so an ambient alias cannot quietly win. Set the credential variables in each row and leave the project to the request.

Import discovery reads the credential variables through google-auth, including GOOGLE_OAUTH_ACCESS_TOKEN and GOOGLE_IMPERSONATE_SERVICE_ACCOUNT, and falls back to application-default credentials exactly as the provider does — so the gcloud auth application-default login row works for it too. The project it lists is the request’s scope_id; the project that application-default credentials name is deliberately discarded. It needs cloudasset.googleapis.com and cloudresourcemanager.googleapis.com enabled on that project.

Do not set TF_VAR_compartment_ocid. For OCI the request’s scope_id is the compartment OCID, and the sidecar injects it as TF_VAR_compartment_ocid for init, plan, apply, and import, overriding the container value. It is not a provider setting: it fills the compartment_ocid input variable the generated code declares.

Because nothing confines the provider to a compartment, the core also reads every OCI plan and fails validation when it creates a resource in a compartment other than scope_id. The generator then rewrites the code:

A compartment the same plan creates is accepted, and so are resources created in the tenancy (root compartment). Only plain creations are checked: an update or replacement that moves an existing resource to another compartment is not caught. Code merged to a repository declares compartment_ocid with no default, so a pipeline that runs it outside Kumoss needs TF_VAR_compartment_ocid.

TF_VAR_tenancy_ocid stays in the container, because it belongs to the credential and one deployment serves one tenancy. The API key row already requires it. Add it to the other rows too when requests touch identity resources: the generated code reads it for resources that live in the root compartment (dynamic groups, tenancy-level policies, top-level compartments) and for the home-region lookup behind every identity write (compartments, policies, dynamic groups, groups, tag namespaces), including a compartment nested under the request’s compartment. Other requests do not need it; availability-domain lookups use the request’s compartment.

Variable names below are the Terraform kubernetes provider’s own, as documented in its registry page; the helm provider accepts the same set.

No scope variable exists for this provider. The sidecar’s scope overlay covers azure and gcp only, so the value the wizard collects as scope_id is stored with the session and hashed into the state project id, but never reaches the engine environment: every command runs against whatever cluster the variables above select. A mounted kubeconfig must be readable by the unprivileged user the image runs as (kumoss, uid and gid 10001), and any paths inside it must resolve inside the container.

Import discovery (/v1/import/scope-resource-ids) has no Kubernetes implementation: it answers exit code 2 with no scope discovery for provider 'kubernetes', so an import round on kubernetes ends with a report that says so and imports nothing.

Variable names below are the vmware/vsphere provider’s own (formerly published as hashicorp/vsphere); the shipped prompt seeds pin version = "~> 2.10", and the provider runs under both OpenTofu and Terraform.

Leave VSPHERE_ALLOW_UNVERIFIED_SSL unset in any other environment. Use a dedicated vCenter service account in an SSO group, holding a custom role scoped to the folders, resource pools, datastores, and networks Kumoss manages; never administrator@vsphere.local.

No scope variable exists for this provider. The value the wizard collects as scope_id is the vSphere datacenter name, which the generated code reads through a data "vsphere_datacenter" data source argument rather than a provider setting. The sidecar’s scope overlay covers azure and gcp only, so every command runs against whatever vCenter the variables above point at; the deployment must make that vCenter and the session’s datacenter agree. There is no vSphere state backend: state stays in whichever backend the repository already declares.

Import discovery (/v1/import/scope-resource-ids) has no vSphere implementation: it answers exit code 2 with no scope discovery for provider 'vmware', so an import round on vmware ends with a report that says so and imports nothing.

These are the sets for this service. The scope variable is deliberately absent: ARM_SUBSCRIPTION_ID and GOOGLE_PROJECT arrive with each request’s scope_id. Add them only when the engine runs outside this service.

The shipped prompt seeds pin these majors in new workspaces:

A workspace that already pins a provider keeps its pin, and the code generated for it uses that version’s syntax. The engine runs init without -upgrade, so rewriting the pin would fail against the workspace’s .terraform.lock.hcl. For example, a repository on ~> 5.0 of hashicorp/aws keeps ~> 5.0 and gets the v5 forms (data.aws_region.current.name, not .region); moving it to v6 is an upgrade to plan by hand. Pins can be changed in the prompt seeds.

Azure needs the most variables by a wide margin. AWS and GCP collapse to one or two variables in keyless CI because their SDKs auto-discover identity and the account or project is either implicit or a single value. Azure always needs tenant plus client plus subscription explicitly — though under this service the subscription arrives with the request rather than from the environment.

Backend environment variables are usually a subset of provider ones — with ARM_ACCESS_KEY and GOOGLE_BACKEND_CREDENTIALS being the deliberate exceptions for splitting identities. If the full provider set is configured, init almost always works too; the reverse is not true.

The scope this service injects reaches the azurerm backend as well, because the provider and the backend read the same ARM_SUBSCRIPTION_ID. Split state — a state account outside the managed subscription — therefore needs subscription_id in the backend config, not just provider credentials. GCP has no equivalent problem: the gcs backend needs no project.