alibaba-live-oss-bucket-policy-guard
Gate OSS bucket ACL and policy mutations — public-read/write ACL exposes data to internet crawlers within seconds; CN-* cross-border replication requires DSL Article 31 assessment.
Install
npx skills add https://github.com/VincentChuWaiChow/vanguard-frontier-agentic/tree/master/skills/alibaba/alibaba-live-oss-bucket-policy-guard
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install vincentchuwaichow-vanguard-frontier-agentic@llmmart
git clone https://github.com/VincentChuWaiChow/vanguard-frontier-agentic.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole vincentchuwaichow/vanguard-frontier-agentic collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Alibaba Cloud Live OSS Bucket Policy Guard
Purpose
Act as the guarded live Alibaba Cloud operator for alibaba-live-oss-bucket-policy-guard work. Gate every OSS bucket ACL and policy mutation with a full impact assessment and explicit operator approval. Treat public-read/write ACL changes as immediate, practically irreversible data exposure events.
When to Use
Use this skill when:
- An OSS bucket ACL is being changed (private → public-read, public-read-write, or any permissive setting)
- An OSS bucket policy is being created, modified, or deleted
- Cross-region replication rules are being configured or modified for CN-* buckets
- Object ownership settings or CORS policies are being changed on production buckets
- A bucket lifecycle policy is being modified in ways that affect object access
- An operator needs to audit current bucket ACL and policy before a mutation
When NOT to Use
Do not use this skill when:
- The task is a read-only OSS bucket audit with no mutation intent
- The task involves object-level operations (upload, download, delete objects) rather than bucket-level policy changes
- The task involves only OSS lifecycle policies that do not affect access control
Key Risk Facts
- OSS ACL
public-read-writeexposes all objects immediately to any internet user. Internet crawlers index publicly exposed OSS buckets within seconds to minutes. Reversing the ACL back to private cannot un-index data that was already crawled. This exposure is practically irreversible in its data-leak consequences. - OSS ACL
public-readmakes all objects readable by the internet. Depending on object sensitivity, this may be acceptable for CDN use cases or catastrophic for PII/business data. - Cross-border replication from CN- to international regions* requires a completed CAC Data Security Law (DSL) Article 31 security assessment. Initiating replication without a completed assessment violates Chinese law.
- Bucket policy deletion removes all fine-grained access controls, potentially expanding access to all authenticated Alibaba Cloud users depending on ACL settings.
- All mutations require the 6-step live-guard gate.
Pre-Flight Checklist
Before executing any OSS bucket ACL or policy mutation, verify all of the following:
- Bucket identity confirmed — confirm the exact bucket name, region, and owner account. Run
aliyun oss stat oss://<BUCKET>or use the OSS Console to confirm bucket metadata. - Current ACL and policy captured — document the current bucket ACL and bucket policy before any change. This is the rollback baseline.
- Object sensitivity assessed — estimate the classification and sensitivity of objects stored in this bucket. Public access to PII, credentials, financial records, or internal business data is a critical incident.
- Cross-border replication check — if the bucket is in a CN-* region and replication targets an international region, DSL Article 31 assessment must be completed first.
- Blast radius assessed — how many objects are in scope? what services or users depend on the current access model? what applications will break if access changes?
- Rollback plan confirmed — document the exact prior ACL and policy for immediate restoration if needed.
Required Confirmation
The operator must explicitly state all of the following before any mutation is executed:
- "I confirm the bucket is
<BUCKET_NAME>in region<REGION>in account<ACCOUNT_ID>." - "I have reviewed the current ACL (
<CURRENT_ACL>) and policy and the proposed change is<SPECIFIC_CHANGE>." - "I have assessed the data sensitivity of objects in this bucket:
<ASSESSMENT>." - "I understand the blast radius of this change:
<DESCRIPTION>." - For public-read or public-read-write ACL: "I understand that internet crawlers may index exposed data within seconds and that this exposure cannot be reversed for already-crawled data. I accept this risk."
- For CN-* cross-border replication: "I confirm a completed DSL Article 31 assessment is on file for this data transfer."
- "I approve this OSS bucket ACL/policy change."
Execution Steps
- Capture pre-change bucket state:
aliyun oss stat oss://<BUCKET>and policy output. - Present the planned change, current ACL/policy, and blast radius to the operator for explicit approval.
- Execute the mutation:
- Set ACL:
aliyun oss set-acl oss://<BUCKET> <ACL>or via OSS Console. - Set bucket policy: via OSS Console > Bucket > Permissions > Bucket Policy, or Alibaba Cloud OSS API.
- Configure replication: via OSS Console > Bucket > Data Replication, with DSL assessment confirmed.
- Set ACL:
- Confirm the new ACL and policy are in effect.
Rollback Procedure
- ACL change (reversible): Restore the previous ACL immediately —
aliyun oss set-acl oss://<BUCKET> private. Note: this stops new exposure but cannot undo data already crawled or accessed. - Bucket policy change (reversible): Restore the prior policy document via OSS Console or API.
- Cross-border replication (reversible): Disable the replication rule via OSS Console; note that objects already replicated to the destination remain there.
Post-Change Verification
- Confirm new ACL is in effect:
aliyun oss stat oss://<BUCKET>. - Confirm bucket policy reflects the intended rules.
- Test access from an unauthorized principal to verify the access model matches intent.
- Check ActionTrail for the bucket mutation event.
- For public exposure: monitor OSS access logs for unexpected crawler traffic.
Response Shape
- Bucket name, region, and account confirmed
- Current ACL and policy captured
- Data sensitivity and blast radius assessment
- Cross-border replication DSL assessment status (if applicable)
- Operator confirmation received
- Execution confirmation
- Post-change verification results
Files (vanguard-frontier-agentic)
-
references
-
official-sources.md 520 B
# Official sources Use this reference only when you need source grounding for Alibaba Cloud OSS service behavior or the detailed source list. ## Alibaba Cloud documentation Use these as starting points, not as proof of the user's live Alibaba Cloud state: - https://www.alibabacloud.com/help/en/oss ## Grounding rule If live Alibaba Cloud tooling is unavailable, say: "I can't query live state here, so I'm falling back to official Alibaba Cloud docs." Then fall back to these sources and sanitized user evidence. -
workflow-and-output.md 1.7 KB
# Workflow and output contract Use this reference only when executing the full live OSS bucket ACL and policy mutation gate. ## OSS bucket guard areas to check - Bucket ACL: current setting (private/public-read/public-read-write); intended change; data sensitivity assessment - Bucket policy: current policy document; intended change; affected principals and resources - Cross-border replication: source region (CN-* or international); destination region; DSL Article 31 assessment status - Blast radius: object count and sensitivity; dependent services and users; rollback baseline (prior ACL and policy captured) - Operator authorization: identity confirmed; explicit written confirmation covering all required statements ## Safe workflow 1. **Frame scope** — confirm bucket identity, current ACL/policy, and the specific mutation requested 2. **Collect evidence** — capture current state before any change; label: `live evidence`, `user-provided`, `documentation-based`, `inference` 3. **Stress-test** — what data is exposed? what is the CN-* replication status? what is the rollback path? 4. **Gate** — require explicit written confirmation from the operator covering all required confirmation statements 5. **Execute and verify** — execute the minimum scoped change; confirm new state; monitor access logs ## Output contract Return this structure: ```markdown # Alibaba Cloud Live OSS Bucket Policy Guard: <scope> ## Bucket identity and current state ## Data sensitivity and blast radius assessment ## Cross-border replication check (if applicable) ## Confirmation received ## Execution result ## Post-change verification ``` Each section must include an evidence level label. Do not proceed past any step without the operator's explicit written confirmation.
-
-
metadata.json 856 B
{ "id": "alibaba-live-oss-bucket-policy-guard", "name": "Alibaba Cloud Live OSS Bucket Policy Guard", "version": "0.1.0", "type": "skill", "provider": "alibaba", "harnesses": ["codex","copilot","claude-code","cursor","gemini","kiro"], "summary": "Gate OSS bucket ACL and policy mutations — public-read/write ACL exposes data to internet crawlers within seconds; CN-* cross-border replication requires DSL Article 31 assessment.", "source_type": "original", "official_docs": [ "https://www.alibabacloud.com/help/en/oss" ], "security_notes": "Public ACL exposure is practically irreversible (data indexed by crawlers). CN-* cross-border replication may violate DSL. 6-step gate required.", "last_verified": "2026-05-08", "path": "skills/alibaba/alibaba-live-oss-bucket-policy-guard", "author": "github: VincentChuWaiChow" } -
SKILL.md 6.1 KB
--- name: alibaba-live-oss-bucket-policy-guard description: Gate OSS bucket ACL and policy mutations — public-read/write ACL exposes data to internet crawlers within seconds; CN-* cross-border replication requires DSL Article 31 assessment. allowed-tools: Read Grep Glob metadata: author: "github: VincentChuWaiChow" version: "0.1.0" updated: "2026-05-08" category: storage --- # Alibaba Cloud Live OSS Bucket Policy Guard ## Purpose Act as the guarded live Alibaba Cloud operator for alibaba-live-oss-bucket-policy-guard work. Gate every OSS bucket ACL and policy mutation with a full impact assessment and explicit operator approval. Treat public-read/write ACL changes as immediate, practically irreversible data exposure events. ## When to Use Use this skill when: - An OSS bucket ACL is being changed (private → public-read, public-read-write, or any permissive setting) - An OSS bucket policy is being created, modified, or deleted - Cross-region replication rules are being configured or modified for CN-* buckets - Object ownership settings or CORS policies are being changed on production buckets - A bucket lifecycle policy is being modified in ways that affect object access - An operator needs to audit current bucket ACL and policy before a mutation ## When NOT to Use Do not use this skill when: - The task is a read-only OSS bucket audit with no mutation intent - The task involves object-level operations (upload, download, delete objects) rather than bucket-level policy changes - The task involves only OSS lifecycle policies that do not affect access control ## Key Risk Facts - **OSS ACL `public-read-write`** exposes all objects immediately to any internet user. Internet crawlers index publicly exposed OSS buckets within seconds to minutes. Reversing the ACL back to private cannot un-index data that was already crawled. This exposure is practically irreversible in its data-leak consequences. - **OSS ACL `public-read`** makes all objects readable by the internet. Depending on object sensitivity, this may be acceptable for CDN use cases or catastrophic for PII/business data. - **Cross-border replication from CN-* to international regions** requires a completed CAC Data Security Law (DSL) Article 31 security assessment. Initiating replication without a completed assessment violates Chinese law. - **Bucket policy deletion** removes all fine-grained access controls, potentially expanding access to all authenticated Alibaba Cloud users depending on ACL settings. - **All mutations** require the 6-step live-guard gate. ## Pre-Flight Checklist Before executing any OSS bucket ACL or policy mutation, verify all of the following: 1. **Bucket identity confirmed** — confirm the exact bucket name, region, and owner account. Run `aliyun oss stat oss://<BUCKET>` or use the OSS Console to confirm bucket metadata. 2. **Current ACL and policy captured** — document the current bucket ACL and bucket policy before any change. This is the rollback baseline. 3. **Object sensitivity assessed** — estimate the classification and sensitivity of objects stored in this bucket. Public access to PII, credentials, financial records, or internal business data is a critical incident. 4. **Cross-border replication check** — if the bucket is in a CN-* region and replication targets an international region, DSL Article 31 assessment must be completed first. 5. **Blast radius assessed** — how many objects are in scope? what services or users depend on the current access model? what applications will break if access changes? 6. **Rollback plan confirmed** — document the exact prior ACL and policy for immediate restoration if needed. ## Required Confirmation The operator must explicitly state all of the following before any mutation is executed: - "I confirm the bucket is `<BUCKET_NAME>` in region `<REGION>` in account `<ACCOUNT_ID>`." - "I have reviewed the current ACL (`<CURRENT_ACL>`) and policy and the proposed change is `<SPECIFIC_CHANGE>`." - "I have assessed the data sensitivity of objects in this bucket: `<ASSESSMENT>`." - "I understand the blast radius of this change: `<DESCRIPTION>`." - For public-read or public-read-write ACL: "I understand that internet crawlers may index exposed data within seconds and that this exposure cannot be reversed for already-crawled data. I accept this risk." - For CN-* cross-border replication: "I confirm a completed DSL Article 31 assessment is on file for this data transfer." - "I approve this OSS bucket ACL/policy change." ## Execution Steps 1. Capture pre-change bucket state: `aliyun oss stat oss://<BUCKET>` and policy output. 2. Present the planned change, current ACL/policy, and blast radius to the operator for explicit approval. 3. Execute the mutation: - Set ACL: `aliyun oss set-acl oss://<BUCKET> <ACL>` or via OSS Console. - Set bucket policy: via OSS Console > Bucket > Permissions > Bucket Policy, or Alibaba Cloud OSS API. - Configure replication: via OSS Console > Bucket > Data Replication, with DSL assessment confirmed. 4. Confirm the new ACL and policy are in effect. ## Rollback Procedure - **ACL change** (reversible): Restore the previous ACL immediately — `aliyun oss set-acl oss://<BUCKET> private`. Note: this stops new exposure but cannot undo data already crawled or accessed. - **Bucket policy change** (reversible): Restore the prior policy document via OSS Console or API. - **Cross-border replication** (reversible): Disable the replication rule via OSS Console; note that objects already replicated to the destination remain there. ## Post-Change Verification 1. Confirm new ACL is in effect: `aliyun oss stat oss://<BUCKET>`. 2. Confirm bucket policy reflects the intended rules. 3. Test access from an unauthorized principal to verify the access model matches intent. 4. Check ActionTrail for the bucket mutation event. 5. For public exposure: monitor OSS access logs for unexpected crawler traffic. ## Response Shape 1. Bucket name, region, and account confirmed 2. Current ACL and policy captured 3. Data sensitivity and blast radius assessment 4. Cross-border replication DSL assessment status (if applicable) 5. Operator confirmation received 6. Execution confirmation 7. Post-change verification results
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.