当策略强制执行KMS SSE时,Logstash无法访问S3

时间:2017-08-15 23:10:34

标签: amazon-s3 logstash amazon-iam elastic-stack filebeat

我在许多容器化服务上运行Filebeats来收集日志并将它们发送到logstash(v5.3.1)容器,然后容器将它们上传到aws S3。

我启用了服务器端加密和默认的kms来加密静态日志,它运行正常。但是,当我添加一个拒绝访问的存储桶策略时,如果没有启用kms sse,则logstash会因错误而失败: 错误logstash.outputs.s3 - 验证存储桶写权限时出错! {:message =>“拒绝访问”,:class =>“Aws :: S3 :: Errors :: AccessDenied”}

一旦我从政策中删除拒绝部分,它就会再次运作。

Logstash输出配置如下所示:

 output {
      s3{
        server_side_encryption           => true
        server_side_encryption_algorithm => "aws:kms"
        region => "XXXXXX"
        bucket => "XXXXX"
        prefix => "XXXXXXXX"
      }
    }

S3 Bucket Policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": “Logging bucket",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::XXXXXXXXXXX:root"
                ]
            },
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::bucket_name_12343456/*”
        },
        {
            "Sid": "DenyIncorrectEncryptionHeader",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::bucket_name_12343456/*",
            "Condition": {
                "StringNotEquals": {
                    "s3:x-amz-server-side-encryption": "aws:kms"
                }
            }
        },
        {
            "Sid": "DenyUnEncryptedObjectUploads",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::bucket_name_12343456/*",
            "Condition": {
                "Null": {
                    "s3:x-amz-server-side-encryption": "true"
                }
            }
        }
    ]
}

奇怪的是,当我删除上述策略的拒绝*部分时,它可以工作:文件被写入S3存储桶并标记为: 服务器端加密 AWS-KMS KMS密钥ID XXXXXXXXXXX

最后我做的一个测试是简单地用加密来调用aws cp,这个调用成功完成!

1 个答案:

答案 0 :(得分:0)

我有类似的问题。我相信这是因为在启动期间,logstash尝试通过将测试文件放在存储桶的根目录(忽略加密设置)并随后再次删除它来验证它是否具有足够的权限来写入存储桶。

您可以通过将validate_credentials_on_root_bucket => false添加到输出配置来禁用此行为。对我来说,这解决了这个问题。