Azure ARM (16) 基于角色的访问控制 (Role Based Access Control, RBAC) - 使用默认的Role

  《Windows Azure Platform 系列文章目录

  今天上午刚刚和客户沟通过,趁热打铁写一篇Blog。

  熟悉Microsoft Azure平台的读者都知道,在老的Classic Portal里面,我们可以设置共同管理员(Co-admin)。

  参考:Windows Azure Active Directory (3) China Azure AD增加新用户

  

  但是Co-Admin和服务管理员(Service Admin)的权限是一样的。

  比如上图的admin创建的任何资源,是可以被newuser这个用户删除的。这样不能进行权限控制。

  在新的Azure ARM Portal里面,我们是可以根据不同的用户,对资源组(Resource Group)设置基于角色的访问控制 (Role Based Access Control, RBAC)

  在这里笔者进行详细的介绍。

  主要操作有:

  一.创建新的Azure AD Account

  二.创建Azure Resource, 并设置RBAC

  一.创建新的Azure AD Account

  1.我们以服务管理员身份(Admin),登录Azure ARM Portal: https://portal.azure.cn

  2.点击Azure Active Directory

  

  3.创建新的用户,我们这里设置账户名称为:readonly。把下面的密码保存在记事本中。下面登录的时候要用到。

  

  4.创建完Azure AD账户以后,我们再创建一个Azure Resource Group,命名为LeiDemo-RG。图略

  5.我们在LeiDemo-RG里面,创建1个新的存储账户,命名为leidemostorage。图略。

  6.然后我们选择LeiDemo-RG,点击访问控制,添加:

  

  

  7.角色这里我要详细的说明一下:

  

  (1)所有者(Owner)

  如果我把readonly这个账户设置为所有者,则readonly账户可以对LeiDemo-RG进行任何操作,包括删除

  (2)参与者(Contributor)

  如果我把readonly这个账户设置为参与者,则readonly账户可以对LeiDemo-RG进行任何操作,但是不包括权限(Authorization)的删除和写入。

  (3)读者(Reader)

  如果我把readonly这个账户设置为读者,则readonly账户只能对LeiDemo-RG,进行只读操作,但是无法读取访问秘钥。

  有兴趣的读者可以参考微软文档:

  https://docs.microsoft.com/en-us/azure/active-directory/role-based-access-built-in-roles

  (1)所有者Owner

  

  允许的操作是*,表示可以执行任何操作

  

  (2)参与者Contributor

  

  允许的操作是Actions的操作,减去NotActions的操作。这个概念非常非常重要。

  允许的操作是Actions的操作,减去NotActions的操作。这个概念非常非常重要。

  允许的操作是Actions的操作,减去NotActions的操作。这个概念非常非常重要。

  所以上图的操作是允许进行任何操作,但是不包括权限(Authorization)的删除和写入。

  (3)读者(Reader)

  

  允许的的操作是进行只读操作,但是无法读取访问秘钥。

  8.我们首先把readonly账户,设置为参与者(Contributor)。

  

  

  9.保证admin登录的浏览器(比如Chrome)不关闭。换另外一个浏览器(比如IE)。在IE中,以readonly账户登录。

  10.我们以readonly账户登录的IE浏览器里,选择资源组LeiDemo-RG,设置访问控制。

  下图中,我们可以看到,因为readonly账户设置为参与者(Contributor),所以允许进行任何操作,但是不包括权限(Authorization)的删除和写入。

  

  

  11.我们回到Chrome浏览器,以admin身份,把readonly设置为读者(Reader)。图略

  12.然后回到IE浏览器,按F5页面刷新。这时候readonly的权限是读者(Reader)。  

  我们在IE浏览器里,以readonly身份,选择资源leidemostorage,然后点击删除。

  

  请记住:我们在步骤11中,设置的readonly权限为读者(Reader)。所有readonly权限为: 进行只读操作,但是无法读取访问秘钥。

  

  13.我们尝试以readonly身份,删除这个存储账户:leidemostorage。会显示删除失败:

  

  这个是可以理解的,因为读者(Reader)的身份,只能进行只读操作,但是无法读取访问秘钥。

  总结:

  1.掌握如何在Azure AD中,创建新的Account

  2.了解RBAC中默认的三个角色:所有者(Owner),参与者(Contributor),读者(Reader)

  

时间: 2024-10-23 19:02:48

Azure ARM (16) 基于角色的访问控制 (Role Based Access Control, RBAC) - 使用默认的Role的相关文章

Azure ARM (17) 基于角色的访问控制 (Role Based Access Control, RBAC) - 自定义Role

<Windows Azure Platform 系列文章目录> 在上面一篇博客中,笔者介绍了如何在RBAC里面,设置默认的Role. 这里笔者将介绍如何使用自定的Role. 主要内容有: 一.了解Role中的Action和NotAction 二.通过PowerShell,查看相应的Action 三.编辑json Template,自定义Role 四.设置相应的Role 五.删除自定义Role 一.了解Role中的Action和NotAction 比如SQL DB Contributor这个Ro

RBAC (基于角色的访问控制)

基于角色的访问控制(Role-Based Access Control)作为传统访问控制(自主访问,强制访问)的有前景的代替受到广泛的关注.在RBAC中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限.这就极大地简化了权限的管理.在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以很容易地从一个角色被指派到另一个角色.角色可依新的需求和系统的合并而赋予新的权限,而权限也可根据需要而从某角色中回收.角色与角色的关系可以建立起来以囊括更广

RBAC: 基于角色的访问控制(Role-Based Access Control)

本文只讨论两种基于角色的访问控制的不同点,不涉及权限设计的数据库设计. 基于角色的访问控制(Role-Based Access Control)可分为隐式角色访问控制和显式角色访问控制. 隐式角色访问控制:没有明确定义一个角色到底包含了哪些可执行的行为. 显式角色访问控制:也称为"基于资源的访问控制",因为这种权限设计的粒度细化到了资源层面,资源有很多种,比如数据库表的增删查改.url.菜单.按钮等等. 来看一个隐式角色访问控制的例子: if (user.hasRole("P

基于角色的访问控制RBAC

------------------------------------------------------------------------------------------------------- RBAC(Role Based Access Control),意为基于角色的访问控制,这里用户不再拥有单独权限,而是与角色相关联,通过赋予角色权限,那么该用户也就拥有了这个角色的权限; 这里的角色可以也理解为用户组. 权限控制位置:在公共的控制器类的构造方法内,这样子类均需进行权限验证; 

RBAC 基于角色的访问控制演示

RBAC rbac:Role Based Access Controll,基于角色的访问控制. 今天理一理RBAC,话不多说,直接切入主题 功能需求: 权限管理(无限极) 角色管理(可以分配权限) 管理员管理(管理员属于哪些角色) 后台左侧显示当前登录用户所拥有的权限 超级管理员拥有所有权限 实现 建表(我们需要三个表,管理员表.角色表.权限表,tip:也可用其它建表方式) 管理员表 权限表 角色表 我制作完的三张表的CRUD,后台首页效果展示(具体的增删改查就不列步骤了): 管理员表 权限表

WCF技术实现基于角色的访问控制

第一次写,小紧张! 即将毕业了,现在将我毕业设计中用到的小的编程技术以及自己的一些理解分享出来,希望可以做点小贡献. 首先要感谢网上各路大神无私的分享,没有你们,就没有我的收获. 在大四之前,对于编程只是学习过简单的C语言,从来没有接触过工程实践.最后的毕业设计肯定要开发程序,于是认真学习了一段时间. 我的毕业设计是开发一个信息管理系统,希望简单实现对学生信息的管理.系统的前端决定使用MVC模式(当下比较流行,但是好难学!),后台的管理用到了WCF技术,体现一种SOA思想. 今天主要讲讲WCF技

Yii2.0中文开发向导——RBAC(基于角色的访问控制权限)表结构原理分析

这里有几个概念很重要,我简单用大白话说一下;权限:就是指用户是否可以执行哪些操作.如:小张可以发帖.回帖.浏览,小红只能回帖.浏览角色:就是上面说的一组操作的集合.如:高级会员有发帖.回帖.删贴.浏览的权限,普通会员只有回帖.浏览的权限.比如小张是高级会员,那么他就可以执行发帖.回帖.删贴.浏览.而小红是普通会员,所以它就只能回帖.浏览.另外角色还可以继承,中级会员除了普通会员的回帖.浏览功能外,还可以发帖.也就是说在普通会员的基础上又增加了一个发帖的权限.在Yii2.0中 yii\rbac:

ETCD:基于角色的访问控制

原文地址:Role-based access control 总览 身份验证已添加到etcd 2.1中. etcd v3 API略微修改了身份验证功能的API和用户界面,以更好地适应新的数据模型.本指南旨在帮助用户在etcd v3中设置基本身份验证和基于角色的访问控制. 特殊用户和角色 有一个特殊用户root,一个特殊角色root. 用户root 在激活身份验证之前,必须创建对etcd具有完全访问权限的root用户. root用户的想法是出于管理目的:管理角色和普通用户. root用户必须具有r

RBAC 基于角色的访问控制

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成"用户-角色-权限"的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数量的权限的集合,权限的载体.例如:一个论坛系统,"超级管理员"."版主"都是角色.版主可管理版内的帖子.可管理版内的用户等,