Troubleshooting: S3 Bucket Permissions required for Successful ingestion / protection of buckets
Scenario: You connected your AWS account to the Clumio portal, but are not able to view all the buckets in your environment.
or
You can see the bucket in the environment, but the backups fail due to an unauthorized error:
Bucket-Level Policy errors
This may be due to the explicit "Deny" permissions on the bucket-level policy. To resolve this issue, please add the below "NotPrincipals" to your "Deny" bucket policy (to ensure that these principals have appropriate access to the bucket):
"NotPrincipal": {
"AWS": [
"arn:aws:iam::<aws_acct_number>:root",
"arn:aws:iam::<aws_acct_number>:role/clumio/<Clumio_role_id>",
"arn:aws:sts::<aws_acct_number>:assumed-role/<Clumio_role_id>/daebaksrv-createS3CustomerSession",
"arn:aws:sts::<aws_acct_number>:assumed-role/<Clumio_role_id>/Ingestion-ingesttool",
"arn:aws:sts::<aws_acct_number>:assumed-role/<Clumio_role_id>/daebaksrv-RestoreTargetCheck",
"arn:aws:sts::<aws_acct_number>:assumed-role/<Clumio_role_id>/daebaksrv-S3Backup"
]
}
Please replace the '<aws_acct_number>' and '<Clumio_role_id>' with appropriate values.
(The Clumio_role_id is of the format ClumioRole-<aws_account_region>-<token>; The token can be found in the environment details on the Clumio portal. Please see the below screenshot)
For example, if you have a policy similar to the one below that limits access to one VPC
{ "Version": "2012-10-17", "Id": "Policy1415115909153", "Statement": [ { "Sid": "Access-to-specific-VPC-only", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": [ "arn:aws:s3:::hd-test", "arn:aws:s3:::hd-test/*" ], "Condition": { "StringNotEquals": { "aws:SourceVpc": "vpc-5680e03d" } } } ] }
Please change it to,
{ "Version": "2012-10-17", "Id": "Policy1415115909153", "Statement": [ { "Sid": "Access-to-specific-VPC-only", "Effect": "Deny", "NotPrincipal": { "AWS": [ "arn:aws:iam::123456789011:root", "arn:aws:sts::123456789011:assumed-role/ClumioRole-us-west-2-831e8db1-7a77-4550-b2a4-838aa526b8df/daebaksrv-createS3CustomerSession", "arn:aws:sts::123456789011:assumed-role/ClumioRole-us-west-2-831e8db1-7a77-4550-b2a4-838aa526b8df/Ingestion-ingesttool", "arn:aws:sts::123456789011:assumed-role/ClumioRole-us-west-2-831e8db1-7a77-4550-b2a4-838aa526b8df/daebaksrv-RestoreTargetCheck", "arn:aws:iam::123456789011:role/clumio/ClumioRole-us-west-2-831e8db1-7a77-4550-b2a4-838aa526b8df", "arn:aws:sts::123456789011:assumed-role/ClumioRole-us-west-2-831e8db1-7a77-4550-b2a4-838aa526b8df/daebaksrv-S3Backup" ] }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::hd-test", "arn:aws:s3:::hd-test/*" ], "Condition": { "StringNotEquals": { "aws:SourceVpc": "vpc-5680e03d" } } } ] }
Object and Bucket owner mismatch
Another possible issue that you may be encountering is an 'Object and Bucket Owner Mismatch' error. If the bucket owner does not have ownership of the objects, then backups would continue to fail with the 'Access Denied status code: 403' message followed with skipped objects during the backup operation. The most likely cause is due to an ACL that is applied to the bucket, and to easily avoid failing backups would be to remove the ACL as recommended by AWS in the following excerpt.
- Bucket owner enforced (recommended)– ACLs are disabled, and the bucket owner automatically owns and has full control over every object in the bucket. ACLs no longer affect permissions to data in the S3 bucket. The bucket uses policies to define access control.
- Bucket owner preferred– The bucket owner owns and has full control over new objects that other accounts write to the bucket with the
bucket-owner-full-control
canned ACL. - Object writer (default)– The Amazon Web Services account that uploads an object owns the object, has full control over it, and can grant other users access to it through ACLs.
If you are still experiencing backup failures after using this article as a guide, please feel free to contact support@clumio.com for assistance.
Comments
0 comments
Please sign in to leave a comment.