当试图以混合中的kms同步到另一个帐户中的另一个桶时，AWS S3同步不一致失败

Question

问题的执行摘要。我有一个桶，让我们称它为桶A，它是用默认的客户KMS键(将调用id: 1111111)在一个帐户中设置的，我们将调用123。在这个桶中有两个对象，它们都在这个桶中相同的路径下。它们具有相同的KMS密钥ID和相同的所有者。当我尝试将它们同步到另一个帐户中的一个新桶B时，让我们使用帐户456，其中一个已经成功同步，但另一个没有同步，相反，我得到了：

An error occurred (AccessDenied) when calling the CopyObject operation: Access Denied

以前有人见过这种前后矛盾的行为吗？我这样说是不一致的，因为它们之间的访问权限绝对没有区别，但其中一个是成功的，另一个则不是。注意:我的总结陈述了两个简单的对象，但我的一个实际情况是，有30个对象正在复制，其余的都失败了，在其他一些路径中，不同的结果是不同的。

以下描述了一些情况--一些为了安全而混淆的数据，但以一致的方式：

桶A (com.mycompany.datalake.us-east-1)桶策略：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAccess",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::123:root",
                    "arn:aws:iam::456:root"
                ]
            },
            "Action": [
                "s3:PutObjectTagging",
                "s3:PutObjectAcl",
                "s3:PutObject",
                "s3:ListBucket",
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::com.mycompany.datalake.us-east-1/security=0/*",
                "arn:aws:s3:::com.mycompany.datalake.us-east-1"
            ]
        },
        {
            "Sid": "DenyIfNotGrantingFullAccess",
            "Effect": "Deny",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::123:root",
                    "arn:aws:iam::456:root"
                ]
            },
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::com.mycompany.datalake.us-east-1/security=0/*",
                "arn:aws:s3:::com.mycompany.datalake.us-east-1"
            ],
            "Condition": {
                "StringNotLike": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        },
        {
            "Sid": "DenyIfNotUsingExpectedKmsKey",
            "Effect": "Deny",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::123:root",
                    "arn:aws:iam::456:root"
                ]
            },
            "Action": "s3:PutObject",
            "Resource": [
                "arn:aws:s3:::com.mycompany.datalake.us-east-1/security=0/*",
                "arn:aws:s3:::com.mycompany.datalake.us-east-1"
            ],
            "Condition": {
                "StringNotLike": {
                    "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-1:123:key/1111111"
                }
            }
        }
    ]
}

同样在源帐户中，我创建了一个假定的角色，我称之为datalake_full_access_role。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::com.mycompany.datalake.us-east-1/security=0/*",
                "arn:aws:s3:::com.mycompany.datalake.us-east-1"
            ]
        }
    ]
}

它与帐户456有可信的关系。还值得一提的是，目前KMS密钥1111111的策略是完全开放的：

{
    "Version": "2012-10-17",
    "Id": "key-default-1",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": [
                "kms:Encrypt*",
                "kms:Decrypt*",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:Describe*"
            ],
            "Resource": "*"
        }
    ]
}

现在，对于帐户456中的目标桶B (mycompany-us-west-2-datalake)，桶策略：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AccountBasedAccess",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::456:root"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::mycompany-us-west-2-datalake",
                "arn:aws:s3:::mycompany-us-west-2-datalake/*"
            ]
        }
    ]
}

为了执行迁移(同步)，我在456个帐户中提供了一个EC2实例，并向它附加了一个实例配置文件，其中附加了以下策略：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::123:role/datalake_full_access_role"
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:DescribeKey",
                "kms:ReEncrypt*",
                "kms:CreateGrant",
                "kms:Decrypt"
            ],
            "Resource": [
                "arn:aws:kms:us-east-1:123:key/1111111"
            ]
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::com.mycompany.datalake.us-east-1",
                "arn:aws:s3:::com.mycompany.datalake.us-east-1/security=0/*"
            ]
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::mycompany-us-west-2-datalake",
                "arn:aws:s3:::mycompany-us-west-2-datalake/*"
            ]
        }
    ]
}

现在，在EC2实例上，我安装了最新的aws版本：

$ aws --version
aws-cli/1.16.297 Python/3.5.2 Linux/4.4.0-1098-aws botocore/1.13.33

然后运行我的同步命令：

aws s3 sync s3://com.mycompany.datalake.us-east-1 s3://mycompany-us-west-2-datalake --source-region us-east-1 --region us-west-2 --acl bucket-owner-full-control --exclude '*' --include '*/zone=raw/Event/*' --no-progress

我相信我已经做了我的家庭作业，这一切都应该是可行的，对于一些对象来说，这是可行的，但不是所有的，而且在这一点上，我没有别的东西可以尝试。注意，我已经100%成功地同步到EC2实例上的本地目录，然后通过以下两个调用从本地目录到新桶：

aws s3 sync s3://com.mycompany.datalake.us-east-1 datalake --source-region us-east-1 --exclude '*' --include '*/zone=raw/Event/*' --no-progress
aws s3 sync datalake s3://mycompany-us-west-2-datalake --region us-west-2 --acl bucket-owner-full-control --exclude '*' --include '*/zone=raw/Event/*' --no-progress

这是完全没有意义的，因为从访问POV没有区别。下面是源桶中两个对象的属性，一个成功，另一个失败：

成功目标：

Owner
Dev.Awsmaster

Last modified
Jan 12, 2019 10:11:48 AM GMT-0800

Etag
12ab34

Storage class
Standard

Server-side encryption
AWS-KMS

KMS key ID
arn:aws:kms:us-east-1:123:key/1111111

Size
9.2 MB

Key
security=0/zone=raw/Event/11_96152d009794494efeeae49ed10da653.avro

失败对象：

Owner
Dev.Awsmaster

Last modified
Jan 12, 2019 10:05:26 AM GMT-0800

Etag
45cd67

Storage class
Standard

Server-side encryption
AWS-KMS

KMS key ID
arn:aws:kms:us-east-1:123:key/1111111

Size
3.2 KB

Key
security=0/zone=raw/Event/05_6913583e47f457e9e25e9ea05cc9c7bb.avro

增编：在浏览了几个案例之后，我开始看到一个模式。我认为当物体太小时，可能会有问题。在所分析的10个目录中，有些对象(而不是所有对象)同步成功，所有成功对象的大小都在8MB或更多，所有失败的对象都在8MB以下。当KMS混合在一起时，这会是aws s3 sync的错误吗？我想知道我是否可以对~/.aws/config进行调整，以便它能够解决这个问题？

Answer 1

我找到了一个解决方案；不过，我仍然认为这是aws s3同步的一个bug。通过在~./aws/config中设置以下内容，成功地同步了所有对象：

[default]
output = json
s3 =
    signature_version = s3v4
    multipart_threshold = 1

我以前有过的signature_version，但我认为我会提供它的完整性，以防有人有类似的需要。新条目是multipart_threshold = 1，这意味着任何大小的对象都将触发多部分上传。我没有指定multipart_chunksize，根据文档，它将默认为5MB。

老实说，这个要求是没有意义的，因为它不应该是重要的，如果该对象被上传到S3之前是否使用多个部分，我知道这并不重要，当KMS不涉及，但显然它是重要的，当它是。