cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Min Chen <min.c...@citrix.com>
Subject Re: my two cents on RBAC/authorization
Date Mon, 30 Sep 2013 04:32:24 GMT
Commands.properties will stay as it is for now, acl_api_permission will be
auto-populated based on this commands.properties file. So developers do
not need to update the DB when they add a new api.

-min

On 9/29/13 6:10 PM, "Darren Shepherd" <darren.s.shepherd@gmail.com> wrote:

>So this will replace the commands.properties.  If one adds a new api,
>will they need to update the DB?
>
>Darren
>
>On Sep 29, 2013, at 5:15 PM, Min Chen <min.chen@citrix.com> wrote:
>
>>> 
>>> 
>>> 
>>> One random question, I'm interested in knowing what the relationship
>>> between commands.props and this new rbac thing will be.
>> 
>> We have categorized two types of permission, one is API level permission
>> to work with current ApiChecker (what kind of APIs are allowed to be
>> accessed by a particular role), the other is entity level permission
>>(what
>> access type we want to grant to a group on a particular entity
>>instance).
>> Previous commands.properties will be stored in acl_api_permission table
>>to
>> indicate what APIs can be accessed by a particular role. Out-of-box, we
>> have Admin, DomainAdmin, and User roles to match with current
>>Account_type.
>> 
>> Thanks
>> -min
>> 
>> 
>>> 
>>> Darren
>>> 
>>>> On Sep 29, 2013, at 4:28 PM, Darren Shepherd
>>>> <darren.s.shepherd@gmail.com> wrote:
>>>> 
>>>> I look forward to the proposal.  Based on your short comments and the
>>>> artifacts I've seen so, I'll warn you that I'll probably disagree
>>>> strongly with the implement
>>>> 
>>>> Darren
>>>> 
>>>>> On Sep 29, 2013, at 12:04 PM, Min Chen <min.chen@citrix.com> wrote:
>>>>> 
>>>>> RBAC branch was created by Prachi and me to do some quick prototype
>>>>>on
>>>>> rbac feature we are going to propose in the community soon. Since it
>>>>>is
>>>>> not ready yet, we haven't proposed and published FS on the ML.
>>>>> 
>>>>> In this prototype, we have group, accout, role, permission as our
>>>>> first class object. Unlike Amazon, cloudstack ACL is mainly done at
>>>>> Account level, so our Group will be a collection of accounts instead
>>>>>of
>>>>> users. Different from Darren suggested here, we didn't extract a
>>>>> separate Policy object to
>>>>> Group several permissions to a policy, because we didn't see a big
>>>>> benefit to store collections of permissions as a Json policy object
>>>>> compared to storing each individual permission into a permission
>>>>>table.
>>>>> Another reason why we store individual permission in db table is to
>>>>> facilitate implementing row-level permission filter for list Apis,
>>>>> where we have created DB views to determine entities to be returned.
>>>>> With a separate permission table, we can potentially join that table
>>>>>in
>>>>> db view for row filtering in read operation. In terms of integrating
>>>>> with third-party RBAC system, I don't see a big difference between
>>>>> re-creating policy object using cloudstack defined Json format and
>>>>> asking them to define those permissions through cloudstack provided
>>>>> permission grant Apis.
>>>>> 
>>>>> Thanks
>>>>> -min
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On Sep 28, 2013, at 8:51 PM, "Darren Shepherd"
>>>>>> <darren.s.shepherd@gmail.com> wrote:
>>>>>> 
>>>>>> I've noticed there's a rbac branch and things are being committed
>>>>>> there.  I didn't see any documentation about the design or anything
>>>>>> (maybe it exists and I looked in the wrong place), so I'm just going
>>>>>> to give you my two cents on authorization systems.  Hopefully this
>>>>>> falls in line with what is being implemented, if not, at least we'll
>>>>>> avoid the awkward conversation when its finish when I say the code
>>>>>>is
>>>>>> marginally useful and should be rewritten.
>>>>>> 
>>>>>> When talking about authorization there's a bunch of terms like
>>>>>> principal, permission, subject, action, policy, etc.  I want to
>>>>>>focus
>>>>>> on policy.  Policy is central to an authorization system.  The
>>>>>>policy
>>>>>> is the collection of permissions that grant or deny access to some
>>>>>> resource or action for a given subject.  RBAC is a really just a
>>>>>>means
>>>>>> to generate a policy.  Once you know the user, group, roles, and
the
>>>>>> permissions of those entities that aggregation of information forms
>>>>>> the policy.  You then take that policy and use it determine if the
>>>>>> given resource/action is granted/denied to a particular subject.
>>>>>> 
>>>>>> It is really important that policy is a first class object in an
>>>>>> authorization system.  This is important to understand because
>>>>>>usually
>>>>>> in a big fat enterprise-y company, they really want you to enforce
>>>>>>the
>>>>>> policy, but not necessarily maintain it.  For example, you'll go
to
>>>>>> your fortune 500 company and they'll tell you they need RBAC.  So
>>>>>>you
>>>>>> go and create an RBAC system.  The problem is that the fortune 500
>>>>>> company probably already has a RBAC system, and its probably AD
>>>>>>based.
>>>>>> So when they said they need RBAC, the really meant you need to
>>>>>> enforce RBAC.  If you implemented RBAC -> Policy -> Authorization,
>>>>>> your good, if you implemented RBAC - > Authorization, your kinda
>>>>>> screwed. Now you need to create a system to sync the two RBACs. 
And
>>>>>> keeping data in two places and trying to sync them is never a good
>>>>>> idea.  Now if you implemented your system as having a policy as a
>>>>>> first class object, you can just swap your RBAC for theirs and all
>>>>>>is
>>>>>> still swell.
>>>>>> 
>>>>>> So if I was to implement this, this is how I'd do it.  (And if this
>>>>>> sounds a lot like IAM, its because it is.  If Amazon got anything
>>>>>> right, it's IAM).  The authenticator should be able to implement
>>>>>> another interface that allows it to supply a Policy object during
>>>>>> authentication.  This is logical in that the authentication systems
>>>>>> quite often hold authorization information too.  If the
>>>>>>authenticator
>>>>>> doesn't implement the interface we fall back to generating the
>>>>>>policy
>>>>>> ourself.  The policy is then consulted to see if the API command
and
>>>>>> the resulting entities are granted/denied.  So far none of this has
>>>>>> anything to do with RBAC.  So the RBAC is implemented in that
>>>>>>default
>>>>>> fallback implemenation that generates the policy.  You map the
>>>>>>current
>>>>>> user/account to groups and roles and get the policies of those
>>>>>> entities to construct the policy.
>>>>>> 
>>>>>> Now for storing the policies I wouldn't do it in a traditional
>>>>>> normalized form.  All you need is tables for user/group/role and
the
>>>>>> mappings for each.  The for user, group, and role you can specify
a
>>>>>> policy JSON blob and that gets stored in the database as a
>>>>>>mediumtext
>>>>>> field on the user/group/role row.  From an API perspective (just
>>>>>>like
>>>>>> IAM), you just let people upload the JSON blobs for each.
>>>>>> 
>>>>>> So if we do it this way, we can have our own simple RBAC but then
be
>>>>>> able to plug into far more complex and powerful authorization
>>>>>>systems.
>>>>>> Hopefully that all made sense.
>>>>>> 
>>>>>> Darren
>> 


Mime
View raw message