Open Stack

On 03/09/2016 10:17 AM, Andrew Bogott wrote:
> Thanks for the quick response, Adam! Responses inline...
>
> On 3/9/16 8:16 AM, Adam Young wrote:
>> On 03/08/2016 10:48 PM, Andrew Bogott wrote:
>>> Due to the weird public/private hybrid nature of my cloud, I'm 
>>> frequently needing to abuse policy.conf files in unexpected ways. 
>>> Today's challenge is the designate policy.  Right now we're running 
>>> a custom solution that maintains all public dns entries under a 
>>> single domain: wmflabs.org.  Here are the current access rules:
>>>
>> This is phreaken fantabulous!
> I totally can't tell if you're being sarcastic :)
I'm being serious.  I want input from people pushing the limits of RBAC.

>
>>
>>> Members of any project can:
>>>
>>> 1) Create any subdomains of wmflabs.org
>>> 2) Create records under those subdomains
>>> 3) Create records under wmflabs.org
>>>
>>> Project members cannot:
>>>
>>> 4) Alter/delete wmflabs.org
>>> 5) Create any domains that are not subdomains of wmflabs.org
>>> 6) Alter records or domains managed by other tenants
>>>
>>>     I see that I can get most of the way there by allowing users the 
>>> create/get/update/delete record policies, and restricting the 
>>> create/get/update/delete domain policies. That gets me 3, 4, 5 and 
>>> 6. I've no idea how/if I can set up a 'special' domain to support 1 
>>> and 2.  Does anyone have any suggestions?  (Since this is a one-off, 
>>> I've no objection to hacking the db directly if that's what it takes 
>>> to provide the kind of half-universal ownership I need for 
>>> wmflabs.org.)
>>
>>
>> I see you are working on domains in the real DNS sense of the word, 
>> and not the Keystone sense of it.
> Yes indeed.  We need to invent some more words it seems.
None of us will beat Charlie Parker on word invention.  He invented 
"klactoveesedstein"

>
>>
>> Could you put wmflabs.org in a separate project and give users 
>> different roles on that project than on the other?  It sounds like 
>> wmflabs.org is a shared resource.
> I definitely could put it in a separate project with special roles -- 
> I don't have global roles working yet, though, so as I understand it 
> that solution would probably require an upgrade to Liberty at least.
>
> So, given global roles, all users would have rights to see domains in 
> their projects and also in the shared project.  That's a baby step in 
> the right direction...

Global Roles...um...not quite right. There are no Global Roles. 
Hierarchical Multitenancy and inherited roles, but queries are still one 
project at a time.


>>
>> Why not give each tenant a subdomain under wmflabs.org to start? Make 
>> it the same as the project name, and if they want a new second level 
>> subdomain, they have to request that from an admin. This keeps each 
>> of them from stepping on each others toes by grabbing names from each 
>> other and squatting on them.
> That's not a terrible idea -- I should survey my users and find out if 
> any of them actually use the 'create domain' facility without 
> consulting an admin.  There are of course /already/ a bunch of custom 
> domains in my existing system but I have to import them anyway.
>
>>
>> With FreeIPA, I was able to do something like this a long time ago:
>>
>> http://adam.younglogic.com/2012/02/dns-managers-in-freeipa/
>>
>> That uses the Bind DynDB LDAP backing store and LDAP based 
>> permissions, which are incredibly fine grained.
>>
>> What are the other constraints you are working under?
> The big one (which I foolishly didn't mention) is that I want this to 
> work with designatedashboard.  The dashboard seems pretty good about 
> observing policies as set, but I bet it won't show a domain from a 
> different project just because the current user has the rights to that 
> project as well as the current one.

Right. What we really want is a way to create a resource (in this case a 
domain) in one project, and "mount" it read only in another project.  I 
think this pattern exists far beyond Designate.

The other possible approach I've started noodling on is applying roles 
to resources.  This has potential, both good and bad.  It has all the 
complexity and power associated with SELinux.  I'm not certain that most 
users would be able to deal with that.  But I can't see a way to mix two 
different policies inside a single project other than having access 
control on the resources themselves, and then the question becomes how 
to differentiate.  You don't want to do it through the userid/owner 
field, as that is way too limiting; what happens when that user is 
deactivated.

>
> Anyway, I will start systematically swapping in different policies and 
> see what turns up.
>
What policies are you contemplating?


> -A
>
>>
>>
>>>
>>> Thank you!
>>>
>>> -Andrew
>>>
>>>
>>> _______________________________________________
>>> Mailing list: 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to     : openstack at lists.openstack.org
>>> Unsubscribe : 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>> _______________________________________________
>> Mailing list: 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe : 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>