The issue is clear - your bucket policy is blocking the PolarDB service. Let me walk you through the proper configuration.
First, your RAM role trust policy looks correct. The role trusts the PolarDB service principal, which is good. However, you should create a custom policy instead of using OSSFullAccess for better security. Here’s a minimal permission policy for PolarDB backups:
{
"Version": "1",
"Statement": [{
"Effect": "Allow",
"Action": ["oss:PutObject", "oss:GetObject", "oss:DeleteObject"],
"Resource": ["acs:oss:*:*:prod-db-backups/polardb-backups/*"]
}]
}
Now for the bucket policy fix - you need to modify your existing bucket policy to allow access from the RAM role. Replace your current bucket policy with this:
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Principal": {"RAM": ["acs:ram::YOUR_ACCOUNT_ID:role/AliyunPolarDBBackupRole"]},
"Action": ["oss:PutObject", "oss:GetObject"],
"Resource": ["acs:oss:*:*:prod-db-backups/polardb-backups/*"]
},
{
"Effect": "Deny",
"Principal": "*",
"Action": "oss:*",
"Resource": ["acs:oss:*:*:prod-db-backups/*"],
"Condition": {
"IpAddress": {"acs:SourceIp": ["!YOUR_OFFICE_IP_RANGE"]},
"StringNotEquals": {"acs:PrincipalARN": ["acs:ram::YOUR_ACCOUNT_ID:role/AliyunPolarDBBackupRole"]}
}
}
]
}
Key points about this configuration:
-
RAM Role Permissions: The first statement explicitly allows the PolarDB backup RAM role to write and read objects in the polardb-backups prefix. This ensures PolarDB service can perform backup operations.
-
Bucket Policy Security: The second statement maintains your security team’s IP restriction for regular users while creating an exception for the PolarDB RAM role. The condition uses StringNotEquals to exclude the role from the IP restriction.
-
Principle of Least Privilege: Both policies grant only the necessary permissions (PutObject, GetObject) rather than full access. For backups, you don’t need ListBucket or other administrative permissions.
-
Resource Scoping: Notice we’re using a specific prefix (polardb-backups/*) to limit where PolarDB can write. This prevents accidental overwrites of other data in the bucket.
Implementation steps:
- Go to RAM Console > Roles > AliyunPolarDBBackupRole
- Remove AliyunOSSFullAccess and add the custom policy above
- Go to OSS Console > prod-db-backups > Access Control > Bucket Policy
- Replace the current policy with the one above (update YOUR_ACCOUNT_ID and YOUR_OFFICE_IP_RANGE)
- In PolarDB Console, verify the RAM role is still attached to your cluster
- Trigger a manual backup to test
For database recovery scenarios, this configuration ensures you can restore from OSS backups while maintaining security controls. The RAM role approach is much more secure than using IP whitelisting alone because it provides identity-based access control that works regardless of where the PolarDB service IPs originate.
After applying these changes, your scheduled backups should resume successfully. Monitor the first few backup jobs to confirm everything works as expected.