RAM Policy That Grants Too Much
An engineer needs a CI/CD pipeline to upload build artifacts to one OSS bucket and read one secret from a secrets store. Under time pressure, the engineer attached the built-in AliyunOSSFullAccess policy plus a broad read policy to the pipeline's RAM user, and stored the AccessKey in a plaintext CI variable. Three months later, a security review finds: the key is used from an unexpected IP range, the pipeline can read every bucket in the account, and the key has never been rotated. The pipeline must keep working during remediation. The team asks how to fix this without a multi-day outage.
1. Identify the specific failures in least-privilege and credential hygiene, and rank them by risk.
Read the worked answer
Failures:
- Over-broad permissions:
AliyunOSSFullAccessgrants read/write/delete across all buckets, far beyond one artifact bucket. Highest blast radius. - Long-lived static key in plaintext: No rotation, exposed to anyone with CI config access. High risk.
- No source restriction: The key works from any IP, which matches the unexpected-IP finding.
- No audit trail review: The anomaly was caught late, suggesting logging/alerting gaps.
Ranking: the static, unrestricted, over-privileged key is the top risk because it combines broad permissions with no containment. Fix containment (scope + IP restriction) and rotation first, then improve detection.
2. Design a least-privilege replacement policy and a migration path that avoids pipeline downtime.
Read the worked answer
Policy: Replace the full-access policy with a custom policy scoped to the specific bucket and prefix for the artifact actions the pipeline actually uses (e.g., put/get/list on bucket/artifacts/*), plus read on the single secret resource. Add an IP condition restricting use to the CI runner's egress range.
Migration without downtime:
- Create a new RAM user (or role) with the scoped policy and a fresh key.
- Add the new credentials to CI as a separate, encrypted secret store entry.
- Switch the pipeline to the new credentials and verify a full run.
- Revoke and delete the old key and detach the broad policies.
- Keep the old user disabled but present for a short rollback window, then remove.
This is a parallel-change migration: the old path stays live until the new one is proven, so there is no outage window.
3. Recommend a longer-term improvement over static AccessKeys for this pipeline.
Read the worked answer
Move to RAM roles with temporary credentials rather than long-lived AccessKeys. If the CI runs on Alibaba Cloud compute (ECS, ACK, Function Compute), attach a RAM role to the workload so credentials are issued and rotated automatically by the platform. For external CI, use role assumption with STS to obtain short-lived tokens scoped to the job. Benefits: no static secret to leak or rotate manually, permissions bound to the workload identity, and automatic expiry limits the value of any leaked token. Combine with audit logging and alerts on anomalous source IPs so future drift is detected quickly.