锋利 RAM 合集-阿里云开发者社区

浅谈

RAM 一个阿里云产品接入到阿里云的策略验证入口，在访问云产品之前都要经过 RAM 去验证访问者的权限，通过后才能放行。
各产品的语法规则需要遵循 RAM 提供的策略进行规范介入，所以策略限定的内容和要求都是本产品自己来定义。
当出现权限不足的报错时，固定要优先找本产品的策略问题，而不是找 RAM，RAM 提示的权限不足也是遵循云产品的验证要求。

案例：

ECS 实现只读某几个实例，其他实例不能看到。
由于 ECS 不支持控制台上只读某几台实例，所以需要通过标签的方式来做

排查：

进行分组授权

1）通过打标签，将 ECS 的资源进行分组。
例如，将其中 5 台机器打上一对标签，标签键是 team，标签值是 dev。将另外 5 台机器打上另一对标签，标签键是 team，标签值是 ops。

对一台机器打标签的操作如下：
1.1）在 ECS 控制台上选择一个实例，在对应的下拉菜单上选择更多 > 实例设置 > 编辑标签。
1.2）单击新建标签，输入标签键和标签值。这里取标签键为 team，标签值为 dev。

2）创建两个用户组，比如分别是 dev 和 ops。然后为您的员工创建相应的用户账号，将不同的用户账号添加到不同的用户组。

3）创建两个自定义策略，分别授权给不同的用户组。
比如，给 dev 组授权的自定义策略名称是 policyForDevTeam，策略内容如下：

{
    "Statement": [
    {
        "Action": "ecs:*",
        "Effect": "Allow",
        "Resource": "*",
        "Condition": {
            "StringEquals": {
                "ecs:tag/team": "dev"
            }
        }
    },
    {
        "Action": "ecs:DescribeTag*",
        "Effect": "Allow",
        "Resource": "*"
    }
    ],
    "Version": "1"
}

显示被授权实例

1）dev 用户组中的子用户登录到 ECS 控制台。

2）到 ECS 列表页，确认控制台展示的当前地域是期望实例实际所在的地域。如果不是，请到控制台顶端的地域列表中切换到期望地域。

3）在 ECS 列表页，点击标签按钮，系统会展示出标签键的下拉列表，鼠标悬停在标签键上时，在标签键下拉列表的右侧会展示出对应的标签值，点击对应的标签值进行选择，此时系统可以过滤出相应资源。

说明一定要选中标签值之后，系统才可以过滤出相应资源。

案例：

被自己的 OSS 策略限制

排查：

访问 OSS 返回 403 ，出口 IP 被自己定义的策略 deny ，将出口 IP 加白后问题解决。

{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"oss:*"
],
"Resource": [
"acs:oss:*:*:xp-pay-boot-test",
"acs:oss:*:*:xp-pay-boot-test/*"
],
"Condition": {
"IpAddress": {
"acs:SourceIp": [
"14.18.249.98",
"120.241.64.42",
"112.94.160.210",
"202.181.149.26"
]}}}]}

案例：

SLS 管理权限被 deny

{
"Version": "1",
"Statement": [
{
"Action": "log:List*",
"Resource": "acs:log:*:*:project/ps/*",
"Effect": "Allow"
},
{
"Action": "log:*",
"Resource": [
"acs:log:*:*:project/ps/logstore/ls_ams_commmon_task",
"acs:log:*:*:project/ps/logstore/ls_ams_commmon_task/*",
"acs:log:*:*:project/ps/logtailconfig/ls_ams_commmon_task*",
"acs:log:*:*:project/ps/machinegroup/ltg_ams_*"
],
"Effect": "Allow"
},
{
"Action": "log:*",
"Resource": [
"acs:log:*:*:project/ps/logstore/ls_ams_transmit",
"acs:log:*:*:project/ps/logstore/ls_ams_transmit/*",
"acs:log:*:*:project/ps/logtailconfig/ls_ams_transmit*",
"acs:log:*:*:project/ps/machinegroup/ltg_ams_*"
],
"Effect": "Allow"
},
{
"Action": "log:*",
"Resource": [
"acs:log:*:*:project/ps/logstore/ls_ams_balance_batch",
"acs:log:*:*:project/ps/logstore/ls_ams_balance_batch/*",
"acs:log:*:*:project/ps/logtailconfig/ls_ams_balance_batch*",
"acs:log:*:*:project/ps/machinegroup/ltg_ams_*"
],
"Effect": "Allow"

"Effect": "Allow"
}
]
}

同样的策略写法下面新增的 ls_ams_balance_batch logstore 就无法访问

排查：

经过测试 SLS 目前针对所有的增删改查操作，在 RAM 上都是有一定的延迟时间，也就是当你修改了当前策略后，实际使用的还是老版本的策略，缓存时间最长小时级别，目前对应产品正在优化中。

案例：

高速通道管理权权限被 deny

排查：

授权了高速通道产品 admin 权限但是访问被 deny ，如果是新版控制台，可以切换到老版控制台测试下。

案例：

控制子账号访问指定的目录

排查：

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:GetBucketAcl",
        "oss:List*"
      ],
      "Resource": [
        "acs:oss:*:*:*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "oss:GetObject",
        "oss:GetObjectAcl",
        "oss:List*"
      ],
      "Resource": [
        "acs:oss:*:*:bear/test/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "oss:ListObjects",
        "oss:Delete*"
      ],
      "Resource": [
        "acs:oss:*:*:bear"
      ],
      "Condition": {
        "StringLike": {
          "oss:Delimiter": "/",
          "oss:Prefix": [
            "",
            "bear/",
            "bear/test/*"
          ]
        }
      }
    }
  ]
}

案例：

授权子帐号管理员权限访问 OSS 日志服务报错

排查：

OSS 控制台上的日志服务没有接入子账后，会出现这种问题，已经在优化中，很快可以上线。

案例：

控制台无法看到授权的 bucket

排查：

在控制台上看到 bucket ，不能只显示指定的 bucket，需要先 list 所有的 bucket，然后再针对指定的 bucket 授权，正确语法

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "oss:ListBuckets",
      "Resource": "acs:oss:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "acs:oss:*:*:test-p"
    },
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "acs:oss:*:*:test-p/*"
    }
  ]
}

案例：

You are forbidden to list buckets.

排查：

出现这种问题一定要提供下 oss requestID 才能排查原因
RequestId:5BAE0D30678B8EDC05EDB21F

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "oss:GetService",
                "oss:ListBuckets"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "oss:GetObject",
                "oss:ListObjects"
            ],
            "Resource": [
                "acs:oss:*:*:okdevopshk",
                "acs:oss:*:*:okdevopshk/*"
            ],
            "Condition": {}
        }
    ]
}

案例：

DTS 控制台访问失败

排查：

先看下主账号 UID 是否具备 DTSDefaultRole 的角色，如果主账号有但是子账号还是没有权限登陆 DTS 控制台操作，在继续看下子账号的登陆 DTS 的时间。
如果是 16 年或者以前的，那可能是由于主账号和子账哈还没有关联所以角色没有生效。

案例：

域名控制台管理策略

{
  "Version": "1",
  "Statement": [
    {
      "Action": [
      "domain:DomainInfoModification",
      "domain:DomainTransferInOperation",
      "domain:DnsModification",
      "domain:SecuritySetting",
      ]
      "Resource": ["acs:domain:*:*:domain/speiyou.com","acs:domain:*:*:domain/speiyou.cn","acs:domain:*:*:domain/huabeisai.com"],
      "Effect": "Allow"
    },
    {
      "Action":
      "domain:QueryCommonInfo",
      "Resource": "acs:domain:*:*:*",
      "Effect": "Allow"
    }
  ]
}

案例：

SDK.InvalidRegionId : Can not find endpoint to access.

升级 STS 的 jar 包版本到最新版即可。

案例：

OSS listbucket 权限

排查：

{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "rds:Describe*",
"Resource": "acs:rds:*:*:*"
},
{
"Effect": "Allow",
"Action": "oss:List*",
"Resource": "acs:oss:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"oss:PutBucket",
"oss:PutObject",
"oss:GetObject",
"oss.ListObjects",
"oss:PutBucketLifecycle",
"oss:GetBucketLifecycle"
],
"Resource": [
"acs:oss:*:*:backup",
"acs:oss:*:*:backup/*"
]
}
]
}

案例：

The OSS Access Key Id you provided does not exist in our records.

排查：

这个问题一般出现在客户端使用 STS 访问 OSS，或者直接用调用子账号的 Accesskey 和 AccesskeySecret 发起访问会遇到类似问题。出现问题和以下两个原因有关。

检查下客户端发起的 AK 是否填写错误。
客户端请求携带的 STS 信息写错了。
客户端请求时携带 Accesskey 或者 STS 信息没有发到 OSS 上。

案例：

给予某个 bucket 控制台上的管理权限

排查

{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "oss:ListBuckets",
"Resource": "acs:oss:::*"
},
{
"Effect": "Allow",
"Action": "*",
"Resource": "acs:oss:*:*:<bucket>"
},
{
"Effect": "Allow",
"Action": "*",
"Resource": "acs:oss:*:*:<bucket>/*"
}
]
}

案例：

给予某个 bucket API SDK 管理权限

排查：

{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "acs:oss:*:*:<bucket>"
},
{
"Effect": "Allow",
"Action": "*",
"Resource": "acs:oss:*:*:<bucket>/*"
}
]
}

案例：

给某个表格实例授权

{
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "ots:List*",
                "ots:Get*",
                "ots:Describe*"
            ],
            "Resource": "acs:ots:cn-hangzhou:*:instance/*",
            "Effect": "Allow"
        },
        {
            "Action": "ots:*",
            "Resource": [
                "acs:ots:cn-hangzhou:*:instance/xd",
                "acs:ots:cn-hangzhou:*:instance/xd/table/*"
            ],
            "Effect": "Allow"
        }
    ]
}

案例：

如果在控制台上实现只读某个目录的内容

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [   
        "oss:GetObject",
        "oss:GetObjectAcl",
        "oss:ListObjects",
        "oss:ListParts",
        "oss:RestoreObject",
        "oss:GetVodPlaylist"

      ],
      "Resource": [
        "acs:oss:*:*:test-beijing-2018/oss-accesslog/001/*"
      ],
      "Condition": {}
    },
    {
      "Effect": "Allow",                    //需要额外针对bucket设置listobject权限。
      "Action": [
        "oss:ListObjects"
      ],
      "Resource": [
        "acs:oss:*:*:test-beijing-2018"
      ],
      "Condition": {
        "StringLike": {
          "oss:Prefix": [
            "oss-accesslog/001/*"
          ]
        }
      }
    }
  ]
}

带有读写效果的看下面这个

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [   
"oss:GetObject",
"oss:PutObject",
"oss:GetObjectAcl",
"oss:PutObjectAcl",
"oss:ListObjects",
"oss:AbortMultipartUpload",
"oss:ListParts",
"oss:RestoreObject",
"oss:GetVodPlaylist",
"oss:PostVodPlaylist",
"oss:PublishRtmpStream"

      ],
      "Resource": [
        "acs:oss:*:*:test-beijing-2018/oss-accesslog/001/*"
      ],
      "Condition": {}
    },
    {
      "Effect": "Allow",                    //需要额外针对bucket设置listobject权限。
      "Action": [
        "oss:ListObjects"
      ],
      "Resource": [
        "acs:oss:*:*:test-beijing-2018"
      ],
      "Condition": {
        "StringLike": {
          "oss:Prefix": [
            "oss-accesslog/001/*"
          ]
        }
      }
    }
  ]
}

案例：

控制台无法删除 RAM 账户，通过浏览器 F12 功能看到提示 MFA 账户绑定不能直接删除，但实际上 MFA 没有任何绑定

排查：

出现这种问题，是因为客户之前的账号中绑定过 MFA ，但是 RAM 子账号的命名中出现了一些特殊字符导致了无法进行删除操作。

解决办法：

RAM 访问控制概览 -> 切换旧版 -> 用户管理 -> 点击某个用户 -> 编辑基本信息 -> 修改用户名为普通简单字符串(不含@符号)

案例：

OSS RAM 访问控制策略配置了限制 IP 访问，实际测试没有限制住。

"Version": "1",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "*",
            "Resource": [
                "acs:oss:*:*:shenzhen-output",
                "acs:oss:*:*:shenzhen-output/*"
            ],
            "Condition": {
                "NotIpAddress": {
                    "acs:SourceIp": [
                        "42.120.75.146/32"
                    ]
                }
            }
        }
    ]
}

排查：

遇到类似情况先了解一个背景，OSS 2018-11 月升级后，支持控制台上的授权，控制台授权的规则和 RAM 访问控制配置的 policy 是或的关系。

1）先查看 OSS 控制台上是否单独授权过访问控制策略，如果单独配置了策略是否和 RAM 的出现冲突。
2）如果控制台授权的是公开的读写权限，或者 oss bucket 是公开权限，那 RAM 的访问控制授权就是不生效的。
3） OSS RAM 的访问控制策略修改完后可能会有 5-10 分钟的缓存，如果限制 IP 的策略发生切换后发现没生效，可以间隔几分钟再测试。
4）遇到解决不了的问题，请务必提供 OSS 返回的 requestID（5 开头的一串字符）升级阿里云工单解决。

案例

子账号访问 OSS 报权限错误 ”The Bucket your visit is not belong to you " ，授权策略如下：

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "oss:List*"
            ],
            "Resource": [
                "acs:oss:*:*:*"
            ]
        },
        {
            "Action": "oss:*",
            "Effect": "Allow",
            "Resource": [
                "acs:oss:*:*:xxq/",
                "acs:oss:*:*:xxq/*"
            ]
        }
    ]
}

排查：

出现类似问题可以先看下客户要发起的是什么 OSS 操作，然后核对客户的操作 action 是否在 policy 允许的范围内。
核对下自己 resource 是否写错，上面的客户 policy 就是一个错误的示范，resource 没有 "acs:oss:*:*:xxq/" 写法，bucket 后面要么是 /* 要么什么都么有，所以上面的策略是错误的，正确的是 "acs:oss:*:*:xxq","acs:oss:*:*:xxq/*"
如果修改后还是不对的话，再看下 bucket 所属的 UserID (UID) 和子账号所属的 UserID（ID）是否一致，不一致也会报错。
如果上面几步还是搞不定，请提供 OSS 返回的 requestID（ 5xx 开头的一串字符）升级阿里云。

案例：

企业控制台的访问控制，发现一个账户下出现了多个重复授权，如下图：

排查：

1）类似问题，可以查下用户是否在企业控制台加入了某个资源组，这个资源组内有重复授权。
2）看下 RAM 访问控制台上是否重复授权，如果 RAM 控制台做个授权也会在企业控制台显示。
如果确定都没有的话，再提供子账号的 UID 升级到阿里云处理。

锋利 RAM 合集

浅谈

案例：

排查：

显示被授权实例

案例：

排查：

案例：

排查：

案例：

排查：

案例：

排查：

案例：

排查：

案例：

排查：

案例：

排查：

案例：

排查：

案例：

案例：

案例：

排查：

案例：

排查：

案例：

排查

案例：

排查：

案例：

案例：

案例：

排查：

案例：

排查：

案例

排查：

案例：

排查：

阿里云支持与服务

热门文章

最新文章

相关课程

相关电子书

相关实验场景