OSS细粒度的权限控制

目前子账户控制台登录权限控制,对于bucket级别的权限控制,目前仅能实现:控制台登录能看到所有的bucket,但只对部分bucket有操作权限,其他bucket操作报错;不能实现控制台登录只能看到有权限的bucket;
对于目录级别的权限控制,目前仅能实现: 控制台登录能看到对应目录的所有同级目录及其所有的父目录及父目录的同级目录,但仅对该目录及目录下的资源有对应的操作权限,其他目录点击操作报错;具体实现如下
1.子账户创建
1)进入RAM管理控制台,选择用户管理

短信验证成功后,子账户创建完成
2)创建子账户的Access key

3)为子账户授权策略
点击授权

进行授权

注:用户可以自定义授权策略

自定义的授权策略这边创建完成后,子账户授权中:可授权策略是可以看到该自定义授权策略的;
自定义授权策略创建,参考自定义授权策略创建;
OSS支持的自定义授权权限参考OSS支持的自定义权限;

2.权限控制
1)子用户能够通过OSS控制台操作部分有权限的bucket:目前只能实现控制台能看到所有的bucket,但是只能操作部分有权限的bucket,没权限的bucket操作报错;

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

2)OSS子账户控制台登录只能看到bucket部分子目录,其他目录不能操作:目前只能实现能看到该bucket下的所有目录,但只对部分目录有对应的权限;

{
        "Version": "1",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "oss:ListBuckets",
                    "oss:GetBucketAcl"
                ],
                "Resource": [
                    "acs:oss:::*"
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "oss:*"
                ],
                "Resource": [
                    "acs:oss:::gsdata-img1/gsdata/*"
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "oss:ListObjects"
                ],
                "Resource": [
                    "acs:oss:::gsdata-img1"
                ],
                "Condition": {
                    "StringLike": {
                        "oss:Delimiter": "/",
                        "oss:Prefix": [
                            ""
                        ]
                    }
                }
            },
            {
                "Effect": "Allow",
                "Action": [
                    "oss:ListObjects"
                ],
                "Resource": [
                    "acs:oss:::gsdata-img1"
                ],
                "Condition": {
                    "StringLike": {
                        "oss:Prefix": [
                            "gsdata/*"
                        ]
                    }
                }
            }
        ]
}

3)SDK或者API操作有某个bucket的全部权限;

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

4)SDK或者API操作有bucket部分目录的全部权限;

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "oss:*"
            ],
            "Resource": [
                "acs:oss:*:*:myphotos/hangzhou/2015/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "oss:ListObjects"
            ],
            "Resource": [
                "acs:oss:*:*:myphotos"
            ],
            "Condition":{
                "StringLike":{
                    "oss:Prefix":"hangzhou/2015/*"
                }
            }
        }
    ]
}

时间: 2024-10-30 12:50:20

OSS细粒度的权限控制的相关文章

【springmvc+mybatis项目实战】杰信商贸-15.细粒度的权限控制+业务上报取消

上一篇总结我们完成了购销合同的增删改查业务,这一篇我们首先完成权限控制以及业务的上报取消的设置功能. 先说我们的权限控制 1.细粒度的权限控制 a)日常权限框架: 基于角色权限,用户.角色.权限(URL.主菜单.左侧菜单.按钮) b)数据权限: 纵向的数据权限过滤:对数据进行过滤 1)本人(专责):登录后只能看到自己的信息Where条件 create_by = #{当前登录者id} 2)部门(集团公司):登录后登录人是经理级别A.只能看本部门Where条件 create_dept=#{当前登录者

权限控制要怎么做呢。。

问题描述 我现在只是一个小的BBS项目,怎么自己写代码来控制权限呢(可以通过springsecurity来控制权限,不过现在不想去搞那个,那个打算以后去研究),想通过资源,角色,用户他们来管理,它们之间的关系我懂,只是资源这部份怎么写呢?最好能贴出点代码 解决方案 解决方案二:详细的一大堆.我给你比较流行的表结构巴.解决方案三:CREATETABLE`systemprivilege`(`model`varchar(255)NOTNULL,`privilegeValue`varchar(255)N

SQL Server使用视图做权限控制

问题引入 这天老鸟火急火燎的跑到菜鸟旁边,想必是遇到什么难题了:"现在有这么一个场景,假如有三种角色,并且存在层级关系,他们需要访问同一个数据源表,但是需要做权限控制,使得每种角色只能看到自己及以下层级的数据.比如:公司有CEO,Manger和普通的employee三种角色,CEO可以查看CEO.Manager和employee层级的数据:Manger只能查看Manger和employee的数据,不能查看CEO层级:而employee只能查看employee的数据,不能查看CEO和Manager

CRM权限控制笔记

此CRM包括三个方面 客户管理系统:客户的信息 预约 生日提醒 进销存系统:进货 入库 销售 OA管理系统:比如日程安排 **************************************************************************************************************************************** 约定大约配置!!!!!!!!!!!!!!!!!!!!!!得好好看看  ruby的纯面向对象 比如 取绝对

【OSS 最佳实践】OSS 操作权限控制

用户操作 OSS 时是需要根据账号的 AccessKeyId 和 AccessKeySecret (后续简称 AK 和 SK )进行权限验证的,这里的 AK 和 SK 包括有多种类型:主账号的 AK 和 SK .子账号的 AK 和 SK 以及 STS 生成的临时 AK . SK 和 Token .那么他们之间有什么区别呢?具体应该如何配置使用呢?本文将带大家一起认识相关概念. 1. 概念区别 主账号的 AK 和 SK 是主账号对应的权限标识,也就是说主账号的每对 AK和 SK 是拥有账号下的所有

Bucket权限控制

  Bucket权限控制 OSS提供Bucket级别的权限访问控制,Bucket目前有三种访问权限:public-read-write,public-read和private,它们的含义如下: ◆ public-read-write:任何人(包括匿名访问)都可以对该bucket中的object进行PUT,Get和Delete操作;所有这些操作产生的费用由该bucket的创建者承担,请慎用该权限. ◆ public-read:只有该bucket的创建者可以对该bucket内的Object进行写操作

认证鉴权与API权限控制在微服务架构中的设计与实现(一)

作者: [Aoho's Blog] 引言: 本文系<认证鉴权与API权限控制在微服务架构中的设计与实现>系列的第一篇,本系列预计四篇文章讲解微服务下的认证鉴权与API权限控制的实现. 1. 背景 最近在做权限相关服务的开发,在系统微服务化后,原有的单体应用是基于session的安全权限方式,不能满足现有的微服务架构的认证与鉴权需求.微服务架构下,一个应用会被拆分成若干个微应用,每个微应用都需要对访问进行鉴权,每个微应用都需要明确当前访问用户以及其权限.尤其当访问来源不只是浏览器,还包括其他服务

集中权限管理系统-java 跨域单点登录结合集中权限管理 权限控制采用shiro

问题描述 java 跨域单点登录结合集中权限管理 权限控制采用shiro 这种需求的系统谁做过 之前 参考了 网上博客的 oauth2 但是发现不太符合我这个需求 因为oauth2只是授权 并不能解决 登录集中权限系统后 登录其他网站的问题 现在的需求是 用户权限系统只需要一个系统来 维护其他系统 没有用户系统 统一先通过集中权限系统登录后进行用户角色权限维护 如果先登录其他系统这跳转到集中权限系统进行先登录 而且也不能解决集中权限管理的问题 我想过可能需要redis来 实现这功能 但是 总感觉

用ASP实现分级权限控制

控制 本文实现的是一个帐务管理系统中分级权限的控制,程序使用ASP和JavaScript编写,在装有IIS4.0的win NT服务器上运行,速度快,易维护. 权限级别划分如下: ①.院长和财务科长:不能输入,可以无限制查询.统计: ②.副院长:不能输入,可以查询.统计其分管部门的帐务: ③.部门领导:不能输入,可以查询.统计本部门的帐务: ④.会计:能输入各部门的帐务(一个会计有时要做几个部门的帐),只能查询.统计自己输入的帐务. 涉及的数据库和字段如下 ①.JK_USER数据库及字段:id(序