OSS Cross-Account Authorization Diagnosis

Diagnose Alibaba Cloud OSS cross-account authorization problems: "another account gets AccessDenied reading my bucket", "cross-account replication keeps failing with NoPermission", "the replication role trust policy errors out", "AssumeRole returns not authorized when my peer tries to access OSS", "cross-account migration is blocked by authorization".

Core approach: verify the caller identity, compare the caller UID with the bucket owner UID via the read-only GetBucketInfo control-plane query to establish same-account vs cross-account, check the bucket's Bucket Policy existence and content with GetBucketPolicy (a 404 NoSuchBucketPolicy is the measured "not configured" fact, not an error), run pure-function attribution over the evidence - trust-policy gap vs RAM-policy resource-granularity mistake vs the Bucket-Policy + RAM dual-grant requirement vs AssumeRole failure routing - and emit ready-to-apply authorization templates (trust policy with the oss.aliyuncs.com service principal, cross-account RAM policy, replication Bucket Policy). Conclude with evidence-based findings only; this skill never changes anything.

Absolute Rules

1. ABSOLUTE PROHIBITION (no authorization changes): Under NO circumstances may you generate, write, or execute any command/script that APPLIES an authorization change - e.g. PutBucketPolicy, RAM CreatePolicy / AttachPolicyToRole / UpdateRole (trust-policy edit), PutBucketReplication, ossutil/console equivalents, or any AssumeRole used to mutate resources. This includes commands "for the user to run" issued from the scripts. Fixes are emitted as JSON TEMPLATES in the report and in references/auth-config-templates.md, described in words, and applied by the user manually. If the user asks to apply an authorization, only output the template + manual steps and declare this skill is read-only.
2. MANDATORY entry-point enforcement: All OSS diagnostics MUST be performed by running the scripts under scripts/ (oss_cross_account_auth_diagnosis.py as the entry, sts_token.py for identity). The Agent is forbidden from assembling its own ossutil / SDK / curl commands against the OSS control plane or bypassing the scripts - the scripts embed timeout, error degradation, and observability guarantees that ad-hoc commands lack. Read the script output, interpret it, and compose the report; do not re-implement the queries.
3. ABSOLUTE PROHIBITION (credential handling): Never read, print, or pass AK/SK/STS tokens explicitly. The OSS SDK resolves credentials exclusively from the environment variables of the default credential chain; the identity check uses the aliyun CLI default credential chain. Never accept AK/SK from the user or from another script.
4. NO FABRICATION: Every conclusion must be grounded in data actually returned by GetBucketInfo / GetBucketPolicy / ListBuckets / GetCallerIdentity. If a query fails or returns empty, record it and state the limitation - never invent an owner UID, a policy document, or an attribution. When the STS-RequestId evidence is not collected, say the attribution is inconclusive rather than picking a branch.
5. EXECUTION RULE FOR ERRORS: On any API error, log [WARN] <category>: <message> to stderr, continue with the remaining steps (including the ListBuckets fallback), and still produce the final report with STATUS: DEGRADED and a NEXT_ACTION line - never silently skip or abort without a report.
6. SCOPE BOUNDARY: This skill only answers cross-account access / replication / migration authorization attribution and template output. It does NOT handle: upload/download transfer error codes or RequestTimeout (use alibabacloud-oss-transfer-error-code-diagnosis); endpoint/region or internal-network endpoint errors (use alibabacloud-oss-endpoint-internal-diagnosis); CRR rule health/status checks or copy-rule health checks (use alibabacloud-oss-crr-config-check); ossfs mount failures (use alibabacloud-oss-ossfs-mount-diagnosis); direct object-link 403 (use alibabacloud-oss-direct-access-link-diagnosis); signed/expired URL 403 (use alibabacloud-oss-presigned-url-v4-diagnosis); SAME-account RAM user/sub-account permission errors (use alibabacloud-oss-security-incident-forensics for identity-visibility forensics); or actually applying any authorization. Colloquial Chinese ticket synonyms for these boundaries (and for the positive triggers) are embedded in scripts/_doc_lookup.py (SKILL_TOPICS + VOCAB_MAP), so the doc-verification layer still routes real-ticket wording correctly.

Official Doc Verification

MANDATORY: For configuration or usage questions, the entry script MUST be invoked with --question "". The script first matches embedded knowledge, then verifies against official OSS docs (doc_verification, llms-index). The final answer MUST cite the URLs from doc_verification.docs. If doc_verification.note starts with DEGRADED, state explicitly: "Unable to verify against online official docs (offline)." Never fabricate doc URLs; only URLs returned by the script may be cited.