Open Stack

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!

> 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.

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.

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.

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?


>
> 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