kewl. I have a PR about to go up. I am going to publish 0.9.4-SNAPSHOT to docker hub that you can pull in for your testing. I am not quite sure what to do with the docker compose setup as it cannot be merged like in the PR, but at least you can just do
./bin/docker-up-vinyldns.sh --version 0.9.4-SNAPSHOT and everything will start up with the test LDAP instance. I am open to thoughts on how to "start up" an alternative version. I suppose I could also promote this to the default and update the README
Also @xmtrcv for our public docker images that we push to docker hub, we sign all of them with our own keys. This means from a security standpoint you can verify signatures on the docker images you pull, and you can certify that they come from us
@xmtrcv the issue I am working through is that each user has to have a login in the LDAP server, that is the standard way to authenticate on login (we basically pass the username and password entered in the login form up to the LDAP server to connect, it can refuse if the user enters incorrect info).
I think the best approach is to drop in an openldap compliant docker container with "testuser" and "testpassword" at a minimum with some sample org in it for people and auth management. I am a little out of my element as well, so I need to figure out the best way to configure logins in an LDAP server.
fwiw, an alternative to this is to just use OIDC, I have that work well underway. It would allow one to use GitLab, Github, Google, etc. for login. I haven't really explored user search yet on that front, so OIDC currently requires either LDAP for user lookup or users just simply have to login one time
@xmtrcv right now we have scripts to do that (we can opensource). There is danger with providing out-of-the-box adding of super users because they have crazy privileges (it scares me a bit actually). We have toned down their privileges to be less dangerous, but that gives you a sense on why it isn't a first class feature in the system.
I completely mangled my explanation above (thanks mobile) so I deleted it; an example could resemble the following:
- a large organization hosts & maintains a namespace
.xyz - an operator group is responsible for the namespace (tier2:sysadmin,sr.dnsadmin)
- other groups in the organization host & maintain second level domain namespace under
.xyz, such asabc.xyzordef.xyz - other groups have operators (sr.dnsadmin) responsible for these second+ level domains
- some groups may no longer want to maintain the footprint required to support hosting; but still want to own and maintain their zone data
.xyzcan host second+ level domains via dynamic DNS; allowing second+ level operators to own and maintain zone data
In the scenario above:
- tier3 (engineering:sr.sysadmin,sr.dnsadmin) engineering support (test, integration, etc.) for DNS infrastructure, but is not involved in day-to-day DNS operations
- tier2 operators are dns & portal admins; configures hosted second+ level dynamic zones, connects second+ level operators (sr.dnsadmin) to those zones
- sr,dnsadmin are the second+ level domain dns admins; (configures lower level zones?); connects second+ level or lower dns operators (jr.dnsadmin) to configured zones
@xmtrcv thanks for the explanation above. I have to parse it a bit. VinlDNS has the concept of ACL Rules that are applied at the zone level (right now they do not extend to child zones). For example, if I own abc.xyz, I can grant a specific VinylDNS user or group the ability to manage A, AAAA, CNAME records matching a particular regular expression. There is also a concept of "Zone admins", that are like super users, but only for an individual DNS zone. They can manage any record in the zone, in addition to ACL Rules. Zone admins can also abandon a zone (wipe it from VinylDNS but does not affect the backend)
Groups are free form here, really up to the organization to determine what the groups are, who is in those groups, and what access / ACL rules they have. People get creative :)
That maybe a missing feature in your scenario
If I follow your scenario: tier 2 folks create and manage zones like abc.xyz. They can make another group zone admins for these zones for other folks to fully manage. Those other groups can grant access to tier3 folks via ACL rules to only manage certain records in those zones.
Like I mentioned though, access controls live at the Zone level (not an entire subdomain)
We have plans for zone management (actually creating zones in the dns backends), and the feature would follow on a delegation, the user can optionally choose to "inherit" the parent zone's access controls
@pauljamescleary Anyone can connect a zone; but that requires:
a) the zone to exist
b) the zone clause in named.conf
c) TSIG key generation for update-policyand/or allow-transfer in that clause
That is something that dnsadmin of .xyz would control for abc.xyz; if the .xyz DNS infrastructure was hosting abc.xyz
.xyz dnsadmin would do the steps above, then create the zone connection in the portal, and assign a user to be a "zone admin" or "super user" for abc.xyz
abc.xyz zone admin could then assign a user to mange limited records? (a.abc.xyz, cname.abd.xyz, txt.abc.xyz)
for a child zone of lmno.abc.xyz; the process would need to be repeated as above.
However, all of those users require an account in LDAP correct? Which account is the keystone (portal admin) account; how is that designated?
I am sure whatever the portal currently implements with respect to zone admins and ACLs is more enough once I get familiar with the process. I am just thinking out loud; only because I am limited to
testuser interaction for the moment; connect/abandon zones; record operations; verifying on my test DNS backend, etc.
*adds users to VinylDNS
all of your connect is correct, need to allow-update and allow-transfer to a tsig key (or use some kind of global template ymmv based on the DNS software)
The portal admin / super user we can help you with. Basically, need to mark a "super" flag on the user entry in vinyldns
But, if you want user(s) to be able to free form manage any zone, we need to make super users
@pauljamescleary Once we get past the LDAP connection piece, I am eager to work with the how users / zones / ACLs / etc. to get a better understanding. I think if one user can connect a zone is able to re-assign it to another user(s?), that works just as well as the super user. A user can be in charge of multiple zones (assigned), but I would not expect the portal admin to manage some jrdnsadmin's zone four domains down :)
The PR will demonstrate how to use the sample docker container
I also understand a 25 cents more about LDAP
To start this version up from the published docker images, run
./bin/docker-up-vinyldns.sh --version 0.9.4-SNAPSHOT --clean
I think the right approach is to put the same test users in a blank slapd / ldap server instead of using the planetexpress one. But then again, the planetexpress has some good info on setting up LDAP, so I may opt to just update docs / README
Also, the setup of the test LDAP server is a good guide to follow - https://github.com/rroemhild/docker-test-openldap/tree/master/bootstrap/data
@pauljamescleary Thank you very much! I will test the PR first thing in the morning. The
planetexpress documentation and structure is comprehensive and I think it made sense to keep the container. :) There are definitely some deltas between the Debian-based docker-test-openldap docker vs. Red Hat/CentOS OpenLDAP setups ... For example: Red Hat's KB article re: OpenLDAP & cn=config has steps for manually editing olcDatabase=\* files. I would not recommend. :(
Basically the script will take your db info and a username and will set it as super
We do that so people don’t connect to some random evil NS that you aren’t aware of :)