- Newest
- Most votes
- Most comments
Note that the permissions you're granting are massively excessive. The s3:*
permission, particularly when granted to the whole bucket, allows reconfiguring the bucket's permissions, destroying all its contents, sharing it with anyone in the world, or anything else imaginable with unlimited permissions.
With practically unlimited permissions, your transfers will certainly work, but so will any number of unintended actions that shouldn't happen.
For the IAM role used by the Transfer service, you should only allow the service principal transfer.amazonaws.com
to assume the role, not the other listed service principals. The role's trust policy should look like this, with the account ID placeholder replaced by your account ID, to prevent other AWS users from configuring their Transfer services to assume your role and accessing your data:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "transfer.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "000000000000" } } } ] }
The permission policy attached to the role should look something like the following. This policy allows reading objects from and writing them to the bucket, as well as listing the objects in the bucket, but not reconfiguring the bucket's permissions, lifecycle policies, encryption or logging settings, or other potentially highly destructive actions.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowBucketAccess", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Effect": "Allow", "Resource": "arn:aws:s3:::test-bucketname" }, { "Sid": "AllowObjectAccess", "Effect": "Allow", "Action": [ "s3:DeleteObject", "s3:GetObject", "s3:GetObjectVersion", "s3:GetObjectACL", "s3:PutObject", "s3:PutObjectACL" ], "Resource": "arn:aws:s3:::test-bucketname/*" }, { "Sid": "GetConnectorSecretValue", "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:ap-southeast-2:000000000000:secret:aws/transfer/SecretName-6RandomCharacters" } ] }
Based on the information provided, there are a few potential reasons why the AWS Transfer connector is failing to download the file and save it to the S3 bucket:
-
S3 Bucket Policy: While the IAM role has permissions to access the S3 bucket, there might be a restrictive bucket policy on the S3 bucket itself that's preventing the Transfer connector from writing to it. Check the bucket policy to ensure it allows the Transfer service to write objects.
-
Encryption: If the S3 bucket is using server-side encryption with AWS KMS, the IAM role might be missing the necessary permissions to use the KMS key. You may need to add KMS permissions to the role policy.
-
Incomplete S3 Permissions: The current policy allows all S3 actions on objects within the bucket, but it doesn't explicitly allow actions on the bucket itself. You might want to add the bucket ARN without the "/*" to ensure full access to the bucket as well as its contents.
-
SFTP Server Connectivity: Ensure that the SFTP connector can successfully connect to the remote SFTP server. Check if the secret in Secrets Manager contains the correct credentials and connection details for the remote server.
-
File Permissions on Remote Server: Verify that the user account used to connect to the remote SFTP server has the necessary permissions to read the file you're trying to download.
To troubleshoot:
- Review the CloudWatch logs for the Transfer connector for more detailed error messages.
- Double-check the S3 bucket policy and ensure it's not restricting access.
- If using KMS encryption, add the necessary KMS permissions to the IAM role.
- Modify the S3 permission in the IAM role to include the bucket ARN without "/*".
- Verify the connection details and credentials for the remote SFTP server in Secrets Manager.
- Test the connection to the remote SFTP server manually to ensure the file is accessible.
If these steps don't resolve the issue, you may need to enable more detailed logging for the Transfer connector to pinpoint the exact cause of the failure.
Sources
Six tips to improve the security of your AWS Transfer Family server | AWS Security Blog
Troubleshooting AWS Transfer Family - AWS Transfer Family
Managing Transfer Family events using Amazon EventBridge - AWS Transfer Family
How to download file from others S3 bucket | AWS re:Post
For anyone wondering this was the issue found by the re:Post Agent:
Incomplete S3 Permissions: The current policy allows all S3 actions on objects within the bucket, but it doesn't explicitly allow actions on the bucket itself. You might want to add the bucket ARN without the "/*" to ensure full access to the bucket as well as its contents.
Relevant content
- asked 10 months ago
- Accepted Answerasked 2 years ago
- asked 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
Many thanks very useful. I have used that as a model.
I had opened the policy as much as possible to try and narrow down the issue, and would have tightened up again when problem solved.
If the "aws:SourceAccount": "000000000000", person associated with this account, was to leave the company and for security reasons their account was removed/disabled, would this break the function and require updating ? The event would be triggered by Eventbridge to download files once a day, and needs to run entirely independently. For this reason, have not left that source account condition in it. What do you suggest ?