AWS Parameter Store IAM 策略无法正常工作

Posted 2023-03-22

【中文标题】AWS Parameter Store IAM 策略无法正常工作

【英文标题】：AWS Parameter Store IAM policies are not working correctly

【发布时间】：2021-10-26 22:53:19

【问题描述】：

我需要一些有关创建 AWS 策略的帮助。

我需要一个链接到 EC2 实例的策略，以便能够只为 AWS SSM 参数存储中的特定参数提供 get-parameters-by-path，而不能更改 Delete、Create 等任何内容，并且应该只能获取值。

此政策的特殊性将通过标签给出。

这是我尝试使用的策略：

    "Version": "2012-10-17",
    "Statement": [
        
            "Effect": "Allow",
            "Action": ["ssm:*"],
            "Resource": ["*"]
        ,
        
            "Effect": "Deny",
            "Action": [
               "ssm:PutParameter",
               "ssm:GetParameter",
               "ssm:GetParameters",
               "ssm:DeleteParameter",
               "ssm:GetParameterHistory",
               "ssm:DeleteParameters",
               "ssm:GetParametersByPath"
             ],
            "Resource": ["*"],
            "Condition": 
                "StringNotEquals": 
                    "ssm:resourceTag/env": "development-1"
                
            
        
    ]

使用AWS Policy Simulator 它会通知您，当尝试使用View、Create、Modify、Delete 参数时，"ssm:resourceTag/env": "development-2" 会通知拒绝消息，而使用"ssm:resourceTag/env": "development-1" 的其他项目会收到通知可以修改、查看等。

但是，当将同一策略绑定到 EC2 实例时，该策略会阻止在拒绝中添加的任何操作。

EC2 通知消息：

/development-1/project-1

aws --region us-east-2 ssm get-parameters-by-path --path /development-1/project-1/ --recursive --with-decryption --output text --query "Parameters[].[Value]"

An error occurred (AccessDeniedException) when calling the GetParametersByPath operation: User: arn:aws:sts::111111111:assumed-role/rule-ec2/i-11111111111 is not authorized to perform: ssm:GetParametersByPath on resource: arn:aws:ssm:us-east-2:11111111111:parameter/development-1/project-1/ with an explicit deny

/development-2/project-2

aws --region us-east-2 ssm get-parameters-by-path --path /development-2/project-2/ --recursive --with-decryption --output text --query "Parameters[].[Value]"
    
An error occurred (AccessDeniedException) when calling the GetParametersByPath operation: User: arn:aws:sts::11111111111:assumed-role/rule-ec2/i-11111111111 is not authorized to perform: ssm:GetParametersByPath on resource: arn:aws:ssm:us-east-2:11111111111:parameter/development-2/project-2/ with an explicit deny

使用的标签：

键=值

/development-1/project-1:

env=development-1

/development-2/project-2:

env=development-2

我做错了什么？

【问题讨论】：

您关于您的策略应该“仅将 get-parameters-by-path 提供给特定 Parameter Store [路径]”的声明与您在显示的策略中实施的内容不匹配我们。实施一个在相关资源路径上简单地允许 ssm:GetParametersByPath 的策略不是更合适吗？

【参考方案1】：

您正在使用Deny 到ssm:GetParametersByPath，所以它会总是被拒绝。拒绝总是优先于任何允许。

但在您的情况下，由于它的实例配置文件，您的策略不必那么复杂。默认情况下，所有内容都隐式拒绝，因此您只需要显式允许：

    "Version": "2012-10-17",
    "Statement": [
        
            "Effect": "Allow",
            "Action": ["ssm:GetParametersByPath"],
            "Resource": ["*"]
        
    ]

对于Resource，您只能添加您希望允许访问的 ssm 参数，而不是全部。

【参考方案2】：

您不能根据参数标签为任何ssm:GetParameter* IAM actions because the API doesn't (currently) support condition keys设置条件键。

相反，您可以通过参数的 ARN 进行限制，一般而言，使用 SSM 参数存储的做法是使用参数的分层路径，以允许您通过 IAM 限制访问，然后可以选择通配符来满足您的需求在该路径下拥有任何东西。

所以一个常见的模式可能是有一些看起来像这样的结构：

/production/foo-service/database/password
/production/foo-service/bar-service/api-key
/production/bar-service/database/password
/production/bar-service/foo-service/api-key
/development/foo-service/database/password
/development/foo-service/bar-service/api-key
/development/bar-service/database/password
/development/bar-service/foo-service/api-key

然后，对于在生产中运行的 foo 服务，您可以为其授予具有以下权限的 IAM 角色：

    "Version": "2012-10-17",
    "Statement": [
        
            "Effect": "Allow",
            "Action": ["ssm:GetParameter*"],
            "Resource": ["arn:aws:ssm:$data.aws_region.current.name:$data.aws_caller_identity.current.account_id:parameter/production/foo-service/*"]
        
    ]

这将允许生产中的 foo 服务访问 /production/foo-service/database/password 和 /production/foo-service/bar-service/api-key，但不允许访问任何其他参数或修改或删除参数的能力。

正如@Marcin 的answer 中所述，您无需在此处向您的 IAM 策略添加拒绝语句，因为 IAM 的默认设置是拒绝，除非已明确给出允许语句。

例外情况是，如果您正在做非常复杂的事情，您希望主要访问范围广泛的事情，然后阻止一小部分事情。 This blog post 谈到默认的 ReadOnlyAccess 策略对他们的组织来说过于宽松，因此他们通过拒绝声明来限制访问，以拒绝他们不想给予如此开放的访问权限。他们也可以反其道而行之，从不使用 AWS 托管策略，而必须在自己的许多服务中维护一套非常广泛的操作，这可能被认为更安全，但也可能需要大量工作。