【问题标题】:AWS IAM Policies: How do I alter the AWSLambdaFullAccess policy to only allow access to one S3 bucket?AWS IAM 策略:如何更改 AWSLambdaFullAccess 策略以仅允许访问一个 S3 存储桶?
【发布时间】:2016-03-02 15:39:01
【问题描述】:

我正在与我的 IT 团队合作,以限制我的用户帐户(在根帐户下),使其无法访问我不想访问的 S3 存储桶。启用 AWSLambdaFullAccess 策略时,它可以完全访问许多 AWS 功能,包括所有 S3。这是 AWSLambdaFullAccess 政策:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:*",
        "cognito-identity:ListIdentityPools",
        "cognito-sync:GetCognitoEvents",
        "cognito-sync:SetCognitoEvents",
        "dynamodb:*",
        "events:*",
        "iam:ListAttachedRolePolicies",
        "iam:ListRolePolicies",
        "iam:ListRoles",
        "iam:PassRole",
        "kinesis:DescribeStream",
        "kinesis:ListStreams",
        "kinesis:PutRecord",
        "lambda:*",
        "logs:*",
        "s3:*",
        "sns:ListSubscriptions",
        "sns:ListSubscriptionsByTopic",
        "sns:ListTopics",
        "sns:Subscribe",
        "sns:Unsubscribe"
      ],
      "Resource": "*"
    }
  ]
}

大部分都很好。我如何将其更改为新策略,以便我只能访问“arn:aws:s3:::lambda-scripts”存储桶?

【问题讨论】:

    标签: amazon-web-services amazon-s3 aws-lambda


    【解决方案1】:

    我能想到的最直接的修改是从您拥有的语句中删除“s3:*”操作,并添加第二条语句,授予 S3 访问该存储桶的权限。

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "cloudwatch:*",
            "cognito-identity:ListIdentityPools",
            "cognito-sync:GetCognitoEvents",
            "cognito-sync:SetCognitoEvents",
            "dynamodb:*",
            "events:*",
            "iam:ListAttachedRolePolicies",
            "iam:ListRolePolicies",
            "iam:ListRoles",
            "iam:PassRole",
            "kinesis:DescribeStream",
            "kinesis:ListStreams",
            "kinesis:PutRecord",
            "lambda:*",
            "logs:*",
            "sns:ListSubscriptions",
            "sns:ListSubscriptionsByTopic",
            "sns:ListTopics",
            "sns:Subscribe",
            "sns:Unsubscribe"
          ],
          "Resource": "*"
        },
        {
            "Sid": "S3LambdaScripts",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::lambda-scripts*"
            ]
        }
      ]
    }
    

    更好的答案是您确实不应该使用预定义的 AWSLambdaFullAccess 权限。相反,使用针对您真正需要的服务和资源的多个语句构建您自己的。例如,您真的在使用 Dynamo、Kinesis、Cognito 等吗?是的,这很乏味。但是,如果您将较小的增量保存为 IAM 中的用户定义策略,则可以更轻松地从自定义和预定义的内容中拼凑出合理的策略。

    【讨论】:

    • 我会采用这个解决方案。确实,AWSLambdaFullAccess 策略提供了比我需要的更多的访问权限。我会制定一个新的政策来减少所有的脂肪。
    【解决方案2】:

    将 S3 权限拆分为单独的语句,并修改这些语句的资源设置。像这样的:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "cloudwatch:*",
            "cognito-identity:ListIdentityPools",
            "cognito-sync:GetCognitoEvents",
            "cognito-sync:SetCognitoEvents",
            "dynamodb:*",
            "events:*",
            "iam:ListAttachedRolePolicies",
            "iam:ListRolePolicies",
            "iam:ListRoles",
            "iam:PassRole",
            "kinesis:DescribeStream",
            "kinesis:ListStreams",
            "kinesis:PutRecord",
            "lambda:*",
            "logs:*",
            "sns:ListSubscriptions",
            "sns:ListSubscriptionsByTopic",
            "sns:ListTopics",
            "sns:Subscribe",
            "sns:Unsubscribe"
          ],
          "Resource": "*"
        },
        {
           "Effect":"Allow",
           "Action":[
              "s3:ListBucket",
              "s3:GetBucketLocation"
           ],
           "Resource":"arn:aws:s3:::lambda-scripts"
          },
        {
         "Effect": "Allow",
         "Action": [        
           "s3:PutObject",
           "s3:GetObject",
           "s3:DeleteObject"
         ],
         "Resource": "arn:aws:s3:::lambda-scripts/*"
        }
      ]
    }
    

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2012-11-23
      • 2020-03-26
      • 2020-12-18
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多