Cloud SSO & Resource Directory
Alibaba Cloud's Resource Directory and Cloud SSO are the two services behind how Cogrion organizes and grants access to its own provider-side Alibaba Cloud accounts — the accounts Cogrion operates itself (ACR EE, PrivateLink, and other infrastructure shared across BYOC tenants), as distinct from the tenant's own BYOC account described in BYOC Model.
Resource Directory: One Provider, Multiple Accounts
Provider-side infrastructure doesn't live in a single Alibaba Cloud account. Resource Directory is Alibaba Cloud's multi-account management service — the AliCloud equivalent of AWS Organizations. One account is designated the management account, and every other provider-side account is created and organized underneath it as a member account, grouped into folders (the equivalent of an AWS Organizational Unit).
This gives the same benefits multi-account structure gives on the AWS side:
- Blast-radius isolation — infrastructure for one purpose (e.g. the shared container registry) lives in its own account, separate from anything else the provider runs.
- Centralized identity and billing — one place to manage who can access which account, and one consolidated bill across all of them.
- Purpose-scoped accounts — accounts are named and organized by what they're for (e.g. a shared-service account for registry infrastructure), the same pattern used for the AWS-side account structure (dev, prod, shared-service, security-tooling).
Cloud SSO: How People Get Into Those Accounts
Cloud SSO is Alibaba Cloud's centralized identity service for a Resource Directory — the equivalent of AWS IAM Identity Center. Rather than each provider-side account having its own separate login and long-lived AccessKeys, Cloud SSO gives every person one identity that can be granted access into any account in the directory, scoped by role.
The building blocks:
- Identity source — Cloud SSO can use its own built-in user directory, or federate against an existing external identity provider.
- Access Configuration — a reusable permission profile (e.g. administrator, read-only) that gets attached to a person or group against a specific account or folder.
- Assignment — the pairing of an identity with an Access Configuration on a specific account, which is what actually grants access.
Logging in through Cloud SSO produces short-lived, auto-refreshing credentials via a browser-based flow — functionally the same experience as aws sso login on the AWS side, using aliyun configure --mode CloudSSO instead of a pasted AccessKey pair.
Why This Matters for BYOC Provider Infrastructure
Provider-side services that BYOC tenants depend on — like the centralized ACR EE registry described in ACR EE Sharing to BYOC Tenants via PrivateLink — run inside this Resource Directory, not in a single undifferentiated account. Cloud SSO is what lets engineers get scoped access into the specific member account a piece of provider infrastructure lives in, without every person needing a standing AccessKey against every account, and without provider infrastructure of different purposes sharing one account's blast radius.
Current state: Resource Directory is already enabled
Resource Directory is already enabled on the provider account — the account that enabled it became the management account automatically, and Alibaba Cloud does not support changing the management account without disabling and re-enabling the whole directory, so treat that as fixed. Enabling it also auto-creates the Root folder; that's not a step anyone takes manually, and any folder count above zero includes it.
The Resource Management → Resource Directory → Overview page tracks progress against Alibaba Cloud's own four-step guide: create members, create folders, create access control policies, enable trusted services. What's left is creating the purpose-scoped folders and member accounts described next, and enabling Unified Identity Management.
Verify: the Overview page's Resource Directory Data panel lists this account as the management account and shows Folders ≥ 1 (Root always counts).
How to: create folders and member accounts
- Console → Resource Directory → Overview → Folders → Add (or the Management page's folder tree), once per purpose-scoped grouping — mirrors the AWS side's OU split, e.g. an Infrastructure folder for shared provider services.
- Console → Resource Directory → Overview → Members → Add, one per member account, or invite an existing account to join. A created member is provisioned as a full account inside the directory directly — no separate signup step the way inviting an existing external account requires.
- From the Management page, move each new member into its target folder.
Verify: the Overview page's Members count reflects each account created, with the expected folder assignment visible under Management.
How to: enable Cloud SSO
Alibaba Cloud's console surfaces this service under Resource Directory → Unified Identity Management rather than a separately-named "Cloud SSO" menu entry — same underlying service (cloudsso in the API), different label in the nav.
- Console → Resource Directory → Unified Identity Management → enable it. Only available from the management account.
- Pick an identity source — the built-in identity repository, or federation against an existing external identity provider, if one is already in use.
- Create an Access Configuration per permission tier needed (e.g. administrator, read-only).
- Create or federate the people/groups who need access, then assign each one an Access Configuration against the specific account or folder they should be able to reach.
Verify: on a developer machine, aliyun configure list shows a profile with credential type CloudSSO after logging in; aliyun sts GetCallerIdentity --profile <profile> resolves to the intended member account, not the management account.
How to: log in as a developer
Once Cloud SSO is enabled and an assignment exists, day-to-day access no longer goes through a pasted AccessKey:
aliyun configure --mode CloudSSO --profile <profile-name>
This opens a browser-based login against the directory's Cloud SSO portal and stores a short-lived, auto-refreshing credential under the named profile. Which account and permission level it resolves into is decided entirely by the Access Configuration assignment from the previous section, not by anything chosen at login time.
Verify: aliyun configure list shows the profile as Valid without ever having entered an AccessKey manually; once the session token expires, the next command against that profile triggers a fresh browser login rather than failing outright.