AWS Transfer service - SFTP - deny ability to list directory is affecting ability to put file to the directory

0

I'm attempting to set up permissions for a user account on AWS Transfer Service with SFTP protocol. I have a use case where a user should be able to add a file to a directory but not list the files in it.

When I tweak the IAM role to deny 's3:ListBucket' for a specific subdirectory the put operation fails as well. Theoretically s3 does allow to Put object without having the ability to list the prefixes. AWS transfer service however seems to be implicitly using the list bucket operation before put. Has anyone managed to deny listing ability while still being able to upload.

IAM policy :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "s3:ListBucket",
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::<my-bucket>"
            ],
            "Sid": "AllowListDirectories",
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "data/partner_2/*"
                    ]
                }
            }
        },
        {
            "Sid": "DenyMkdir",
            "Action": [
                "s3:PutObject"
            ],
            "Effect": "Deny",
            "Resource": "arn:aws:s3:::<my-bucket>/*/"
        },
        {
            "Sid": "DenyListFilesInSubDirectory",
            "Action": [
                "s3:ListBucket"
            ],
            "Effect": "Deny",
            "Resource": "arn:aws:s3:::<my-bucket>",
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "data/partner_2/data/incoming/*"
                    ]
                }
            }
        },
        {
            "Effect": "AllowReadWirteInSubDirectory",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion",
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:PutObjectTagging",
                "s3:PutObjectVersionAcl",
                "s3:PutObjectVersionTagging"
            ],
            "Resource": "arn:aws:s3:::<my-bucket>/data/partner_2/data/incoming/*"
        },
        {
            "Effect": "AllowOnlyReadInADifferentDirectory",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion"
            ],
            "Resource": "arn:aws:s3:::<my-bucket>/data/partner_2/data/outgoing/*"
        }
    ]
}

The output from SFTP client:

sftp> cd data/incoming
sftp> ls
Couldn't read directory: Permission denied
sftp> put /Users/foo/Downloads/test.log
Uploading /Users/foo/Downloads/test.log to /data/incoming/test.log
remote open("/data/incoming/test.log"): Permission denied
sftp> get test-one.txt
Fetching /data/incoming/test-one.txt to test-one.txt
sftp> exit
1개 답변
0

Hi Sharath, thanks for your question. Before we write a new object, we attempt to determine if an object with the same name already exists and, if it does, whether it represents a directory. In a normal filesystem, trying to write file 'XYZ' when directory 'XYZ/' already exists would fail. In S3, it would allow you to create both objects, 'XYZ' and 'XYZ/'. Unfortunately, AWS Transfer Family doesn't have good way to represent this state. We try to avoid this state altogether since either the file or directory would end up masked at SFTP level. We recognize this limitation and are exploring possible solutions, such as "read only" and "write only" flags at the SFTP server level. Please let us know if a feature like this would be useful.

In the meantime, you may be able to achieve this end user experience by using AWS Transfer Family managed workflows. Specifically, workflows allow you to copy incoming files to new directories and delete the original file, resulting in an 'upload only' type experience. You can learn more about managed workflows here.

AWS
전문가
AWS
답변함 일 년 전

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

질문 답변하기에 대한 가이드라인

관련 콘텐츠