Huawei Cloud IAM migration and access control on STACKIT

The access migration in eight steps

1. 01

   1. Inventory identities beyond the Terraform

   StackToIT reads the Terraform and connects to no account. Users, keys and agencies created in the console are not in the result, so export that list separately and compare.

2. 02

   2. Assess

   Run stacktoit assess on the IAM module. Expect MANUAL_REVIEW across the board; the value is the inventory: which identity, which setting, which dependency, and a wave order that puts the groups, users, roles, agency and provider first and the membership after them.

3. 03

   3. Split people from machines

   A user such as alice.platform is a person. A user such as ci-deployer is a pipeline. They end up in different STACKIT constructs, so tag each identity before you design anything.

4. 04

   4. Design the hierarchy before the roles

   Role bindings sit on organizations, folders and projects and inherit downward. The documentation states that access cannot be restricted by a binding on a child, so bind at the lowest level that works and shape folders and projects around who may see what.

5. 05

   5. Connect your identity provider

   STACKIT user accounts live in an identity provider; the STACKIT IdP connects external providers over OIDC or SAML 2.0 and provisions users and groups with SCIM. People then sign in with the credentials they already have, and no Huawei password is carried over.

6. 06

   6. Create service accounts for machines

   Pipelines and servers get service accounts. Prefer OIDC workload federation, which exchanges a short-lived token from your CI issuer, over long-lived keys. The run’s own README gives the same advice for provider authentication.

7. 07

   7. Translate policies into roles

   Start from the predefined roles Owner, Editor and Reader and the product roles, and write a custom role only where they do not fit. A custom role is a named list of permissions, so each Action of a Huawei policy is rewritten as one or more STACKIT permissions.

8. 08

   8. Test, cut over, retire

   Sign in as each kind of user and run the tasks it needs. Remove Huawei identities after cutover, and rotate any secret that ever sat in Terraform variables or state. The run states the rollback for these steps is for the person who carries them out to record.

Users, groups and a custom role, assessed

A small Huawei Cloud IAM estate with eight resources, written for this page and assessed by StackToIT on 4 November 2026. Left: three blocks of the input. Right: the result the run recorded for them, an excerpt of assessment.json with the values as the run wrote them.

resource "huaweicloud_identity_user" "alice" {
  name        = "alice.platform"
  description = "Platform engineer"
  password    = var.initial_password
}

resource "huaweicloud_identity_group" "platform" {
  name        = "platform-admins"
  description = "Platform engineering"
}

resource "huaweicloud_identity_role" "bucket_reader" {
  name        = "custom-obs-bucket-reader"
  description = "Read bucket ACLs"
  type        = "AX"
  policy      = <<EOT
{
  "Version": "1.1",
  "Statement": [
    {
      "Action": ["obs:bucket:GetBucketAcl"],
      "Effect": "Allow"
    }
  ]
}
EOT
}

[
  {
    "id": "huaweicloud_identity_user.alice",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "IAM policies have no document-level counterpart on STACKIT. Map people and workloads to STACKIT roles and service accounts in a reviewed design."
    }
  },
  {
    "id": "huaweicloud_identity_group.platform",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "IAM policies have no document-level counterpart on STACKIT. Map people and workloads to STACKIT roles and service accounts in a reviewed design."
    }
  },
  {
    "id": "huaweicloud_identity_role.bucket_reader",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "IAM policies have no document-level counterpart on STACKIT. Map people and workloads to STACKIT roles and service accounts in a reviewed design."
    }
  }
]

• No target by design

  The run names no STACKIT service for these units. Its reason asks you to map people and workloads to STACKIT roles and service accounts in a reviewed design.

• Settings named for review

  The user lists description, name and password, the group description and name, the role description, name, policy and type, each as a critical setting left to you. The policy document is not interpreted.

• Passwords are not a migration item

  The password of a Terraform-managed IAM user belongs to the old system. Plan sign-in through your identity provider instead of copying it.

An agency, an identity provider and a membership

The three resource types in the same run that the knowledge base of this build does not catalogue.

resource "huaweicloud_identity_agency" "backup" {
  name                  = "backup-agency"
  description           = "Lets a partner account run backups"
  delegated_domain_name = "partner-backup-domain"

  domain_roles = ["OBS Administrator"]
}

resource "huaweicloud_identity_provider" "corp" {
  name     = "corp-idp"
  protocol = "oidc"
  status   = true
}

resource "huaweicloud_identity_group_membership" "platform" {
  group = huaweicloud_identity_group.platform.id
  users = [huaweicloud_identity_user.alice.id, huaweicloud_identity_user.ci.id]
}

[
  {
    "id": "huaweicloud_identity_agency.backup",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "huaweicloud_identity_agency is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  },
  {
    "id": "huaweicloud_identity_provider.corp",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "huaweicloud_identity_provider is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  },
  {
    "id": "huaweicloud_identity_group_membership.platform",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "huaweicloud_identity_group_membership is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  }
]

• Unknown types stay visible

  Each is MANUAL_REVIEW with LOW confidence and nothing of it is assessed or drafted. They still appear as units, with dependencies, so the group membership is ordered after the group and both users.

• The provider is not read as one

  The identity-transition file of this run says no unit is an OIDC provider or a federated trust, although the example declares an OIDC identity provider. Treat that file as silent on this resource and list the provider yourself.

How Huawei Cloud IAM concepts map to STACKIT

Huawei Cloud concepts from the IAM basic concepts, policy syntax and identity provider overview pages, STACKIT side from the roles and permissions, custom roles, service account and STACKIT IdP pages, as of November 2026. Whether a given Huawei policy is reproducible depends on the policy, which the run does not interpret.

What the run says about identity and provider access

Left: the limits block of assurance/identity-transition.md. Right: the provider authentication row of terraform/README.md. Both are lines as the run wrote them.

## Limits

- Workload identity federation is not assessed as an option for any workload. A row states an OIDC issuer where the source names one, as a fact of the source, and never that federation can replace a key.
- A static credential is named only where the knowledge base reads a machine user with access keys on the unit. A scan that finds no key cannot say a workload has none, so the absence of a credential is never written.
- Privilege delta, break-glass access and human identity are not assessed for any row.
- A workload that names no identity in the source has no row, and a run whose draft held no identity intents lists only the units that are an identity themselves.
- The block states what the identity plan holds open. It does not attach, grant or federate anything.

| Check | Result |
|---|---|
| Provider authentication | Authenticate the provider with Workload Identity Federation (`use_oidc = true` and `service_account_email`, a short-lived OIDC token exchanged for a STACKIT access token) instead of a long-lived service account key: the provider documents it as the way that "eliminates the need for long-lived secrets" in CI/CD (the STACKIT provider documentation, index page, section "Workload Identity Federation", and its guide "Workload Identity Federation"; knowledge-base evidence, not in this folder). |

• Honest about what it does not see

  Federation as an option, privilege delta, break-glass access and human identity are not assessed. They are the review you run with your security team.

• A short-lived token for the provider

  For the STACKIT Terraform provider itself, the run points at Workload Identity Federation with a service account instead of a long-lived key.

Differences that bite in practice

• Bindings only add access

  On STACKIT, access is granted by a new binding and not removed by a later one, and a binding on a child cannot deny what a parent grants. A Huawei policy that relies on a deny needs a different structure.

• Bindings sit on the hierarchy

  Role bindings work on organizations, folders and projects, not on one bucket or one VM. Fine-grained separation moves into the project layout.

• Access tokens are being retired

  As of November 2026, the service account page gives 16 December 2025 as the deprecation date of service account access tokens and says the Service Account Access Token Admin role is to be removed by the end of Q2 2026. Use key flow or federation.

• Keys are secrets

  A service account key is a credential for the key flow. The documentation says to treat it like a password and never embed it in source code.

• Three permissions can escalate

  iam.role.edit, iam.role.add and iam.member.add let a subject change roles or its own bindings. The custom roles page asks for caution.

• Terraform for roles may change

  The STACKIT provider 0.121.0 marks its role assignment resources as part of an opt-in feature that may still change significantly or be removed. Pin the provider version and review plans.

Questions security teams ask

Sources

• STACKIT service accounts
• STACKIT roles and permissions
• STACKIT custom roles
• STACKIT IdP overview
• Huawei Cloud IAM basic concepts
• Huawei Cloud IAM: Policy syntax
• Huawei Cloud IAM: Identity providers overview