Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 19:00

    mitruly on gh-pages

    updated site updated site updated site and 8 more (compare)

  • 18:40

    mitruly on master

    Add max retries to MySQL queue … (compare)

  • 18:40
    mitruly closed #910
  • 18:01
    codecov[bot] commented #910
  • 17:58
    codecov[bot] commented #910
  • 17:58
    codecov[bot] commented #910
  • 17:45
    mitruly synchronize #910
  • 17:14
    mitruly synchronize #910
  • 16:02
    codecov[bot] commented #914
  • 16:02
    mitruly opened #915
  • 15:59
    codecov[bot] commented #914
  • 15:59
    codecov[bot] commented #914
  • 15:56
    britneywright edited #914
  • 15:51
    britneywright labeled #914
  • 15:48
    codecov[bot] commented #914
  • 15:48
    codecov[bot] commented #914
  • 15:48
    britneywright synchronize #914
  • 15:45
    codecov[bot] commented #914
  • 15:32
    codecov[bot] commented #914
  • 15:31
    britneywright synchronize #914
Paul Cleary
@pauljamescleary
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
Paul Cleary
@pauljamescleary
Perhaps we can replace the "professor" ldap setup with a normal test, and then use the same test (testuser testpassword) as what is in the quick start.
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
Paul Cleary
@pauljamescleary
@xmtrcv eh, I found a bug in my current PR. Need to fix that today. Let me get back to you later, really close here so I want to wrap this up while it is still :fire:
Paul Cleary
@pauljamescleary
@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
@xmtrcv
@pauljamescleary So, an LDAP user would use their credentials to log into the portal; the portal does not have the ability to create users in its own space? How would a portal admin (super) user be differentiated from a normal portal user (one assigned to x.y.z domain)?
Paul Cleary
@pauljamescleary
@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.
Paul Cleary
@pauljamescleary
We have had a nagging itch to rethink super and support users as well. Happy to have a discussion on it
Paul Cleary
@pauljamescleary
This is good feedback. Here, super users are primarily to resolve issues in a pinch. We had discussed system admins really managing special groups. In all honesty a lot of config can be managed by sysadmins in the app we just haven’t gotten there yet.
xmtrcv
@xmtrcv

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 as abc.xyz or def.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
  • .xyz can 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
@xmtrcv
also, it may be possible restrict some operations based on supporting update-policy in named.conf (requires some testing with portal, etc.)
Paul Cleary
@pauljamescleary
We do aspire to be closer to the dns backend, this sounds like an interesting idea there
Paul Cleary
@pauljamescleary
@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 :)
Paul Cleary
@pauljamescleary
The one thing interesting is that we do not control "connect zone", like anyone can connect a zone. There are valid use cases to do this regularly.
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
xmtrcv
@xmtrcv

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

xmtrcv
@xmtrcv
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.
Paul Cleary
@pauljamescleary
@xmtrcv yes, all users need to be in LDAP / VinylDNS (VinylDNS automatically adds users on login OR add a user to a group)
*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
Paul Cleary
@pauljamescleary
Actually, any user can be keystone tbh. What we have done is work with DNS to create a group that includes VinylDNS folks as well as DNS. Every zone in our VinylDNS has "vinyldns-system-admins" as the zone admin. The group that connects the zone can reassign it.
But, if you want user(s) to be able to free form manage any zone, we need to make super users
xmtrcv
@xmtrcv
@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 :)
Paul Cleary
@pauljamescleary
nice, I will have to open an issue on the super user part. I just reviewed our schema and we will need a one off script to run, not too hard to do
xmtrcv
@xmtrcv
@pauljamescleary I am happy to work within whatever structure exists for the user directory piece currently.
Paul Cleary
@pauljamescleary
sounds good
Paul Cleary
@pauljamescleary
Ok, I think I finally have this licked. Going to post a PR that you can work from, as well publish a SNAPSHOT docker image
The PR will demonstrate how to use the sample docker container
I also understand a 25 cents more about LDAP
Paul Cleary
@pauljamescleary
@xmtrcv - here is the PR, for your entertainment purposes you only need to look at the docker/portal/application.conf and docker/docker-compose-build.yml files for docker compose + setup guidance.
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
Paul Cleary
@pauljamescleary
I just updated the README and kept the container :)
Paul Cleary
@pauljamescleary
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
xmtrcv
@xmtrcv
@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. :(
xmtrcv
@xmtrcv
@pauljamescleary I have everything up, running, and connected to my test LDAP server; you mentioned something about a "super" flag on the user entry in vinyldns?
Paul Cleary
@pauljamescleary
I don’t think You need that to get started. I will create a script to update the database and you can mark a user at any time. Didn’t get there’re yet
Basically the script will take your db info and a username and will set it as super
xmtrcv
@xmtrcv
I spoke too soon; forgot to set approved-name-servers... ( ._.)
Paul Cleary
@pauljamescleary
Yeah. Those are regex. You can allow all and do “.*”
We do that so people don’t connect to some random evil NS that you aren’t aware of :)
xmtrcv
@xmtrcv
Oh yeah, I had it before; just forgot, lol
Paul Cleary
@pauljamescleary
Cool. Let us know if you have any other questions. Feel free to pm me if you need to