Consolidate vinyldns sys admins

[pauljamescleary]

Is your feature request related to a problem? Please describe.
Right now, the concept of a sysadmin is spread across a few flags in the database that are now rather unaccessible. For users to use shared zones, they have to be a super user or a support user, which cannot be updated without some kind of script.

Describe the solution you'd like

1. Create a script to help manage support users - this is a short term fix
2. Create a default VinylDNS group, only manageable by a root / admin user, not visible to anyone else in the system (unless they are are added to the group).
3. Collapse the idea of "support" and "super" users to just simply be a member of the special "sysadmin" group

[remerle]

Longer term we should consider RBAC, and simply assign roles to groups/users. A "sysadmin" role would be a good first candidate and could replace the current concept of "super" users. I can imagine other types of roles (e.g., batch queue review).

Shorter term, being able to designate a group as a "sysadmin" group would be a good first step.

[JanuszU]

in the current version the "super user" is build in and pays a huge role; but I can see no way to assign a super user so at least a short term fix is needed. I vote both hands.

[pauljamescleary]

@JanuszU "super user" is mostly on par (or entirely on par) with "support user" at this point.

@remerle we never did develop a user/role/privilege system (outside of zone level access controls and zone admins). At its inception, we did not see the need for it. I could certainly see an initially hard-coded set of privileges and a single role for "support" coming about, at least a pattern could be put in place for future expansion.

The immediate need follows:
Need a "root" user (it is like a single admin account). Right now, every login registers a new user automatically; however, there is no way to do certain "admin only" type things. The only "admin only" type thing we need right now is to designate a "support user". I created a script to do it but it is a short term hack.

In addition, we need the ability to register a user via the API, as well as see other users in the system. This could be done by the "root" account or "super" users.

@JanuszU not sure if you have any other needs. @remerle not sure if you heard of anything else as well.

[JanuszU]

@pauljamescleary The functionality I need is a group of admins-approvers and a group of users that may apply for a change or a new record. All their applications need an approve. It would be best if the users have access only to assigned zones while admins to all.
I have solved the narrowing of Vinyl access via AD group filter.
Maybe You could add a config attrib with a group name which the users of, would only have the right to fill in the "DNS Change request" for a further approval.

[pauljamescleary]

@JanuszU thanks for the info, let me see if I understand right.

You need a group of admins who are "approvers" who can review+approve certain DNS changes

• In vinyldns, approvers are "support" users. If you have manual review turned on, you can flag DNS requests for manual review by FQDN / IP address. When a user submits a DNS request, if any entry in that change request requires review, the DNS request goes into a "Pending Approval" state. At that point only "support users" can Approve / Reject the request. If they "Approve" (in the Portal or the API), then the request is automatically processed

"A group of users that may apply for a change for a new record"

• Any user that can login to VinylDNS can submit a DNS request.

"It would be best if the users have access to only assigned zones"

• Any user in the system can submit DNS requests for Any zone registered in VinylDNS
• If the user does not have access, they cannot submit the DNS request
• Access can be granted in a number of ways outlined in the new "Permissions Guide", quickly:
  • if the user is a Zone admin, they can make any change to that zone
  • if the user has been granted access to a Zone via an ACL rule, that user can make the allowed changes to the zone based on the ACL rule
  • if the zone is marked as "Shared", the user can make changes to the zone (respecting record ownership)
  • Finally, if the zone is configured for manual review, any changes to the zone must be approved by a support user (or rejected)

Let me know if this helps. In short, I think that we have the ability to support most of your needs today. Will be happy to answer questions, and update our Docs in short order with whatever is not clear (I know there are a lot of switches so I certainly sympathize)

[JanuszU]

@pauljamescleary thanks for putting the access rights clear. Currently the access is "zone centric".
I think the good idea is to move step by step towards RBAC.
To fine grade the rights it would be nice to have a right to "enter a record set for approval" as something between Read and Write rights.
So if I could set a group of users that are forced to apply for approval that would allow me to build a nice quasi RBAC solution.

[pauljamescleary]

@JanuszU hmm, so do you mean something like "If anyone changes these records, let ME approve them"?

Would the process follow:

1. A zone admin creates an ACL rule on a Zone. The ACL rule specifies "approval needed" for the rule
2. A user makes a change to that zone, authorized under the ACL rule. Because the ACL rule specified "approval needed", the change is in a pending approval state
3. A zone admin has the ability to approve or reject that change

Or was it something different, I am trying to parse "enter a record set for approval", do you mean "give these users right to make changes, but require ALL changes to be approved"?

[JanuszU]

@pauljamescleary Your 3 step solution sounds very good. If I could assign such ACL to a group would be delicious.

[pauljamescleary]

@JanuszU thanks. Could you elaborate on how you see this working? Wondering if you could provide a little more context / even an example or a story that walks through "who" sets it up, and how they go about setting it up.

When you mention "Step 3", I assume you mean someone sets up a rule / RBAC / ACL somewhere in VinylDNS that says "these kinds of changes need to be approved by the zone admins". I am wondering "who" sets up that authorization check, and at what level(s) it applies (i.e. globally across ZONES (like a subdomain), at the zone level only, both)

[JanuszU]

@pauljamescleary I think it goes clear from Your 3 points.
ACL applies to a particular ZONE.
every zone has its AdminGroup
an ACL may be set by a zone Admins on that zone
I do not know for sure but for now only "support users" may approve YES ? In the future there should be an ACL designating aprovers for a particular zone.

[pauljamescleary]

@JanuszU thanks for the clarity. It circles back to the RBAC for approvers. I like that idea alot. It goes beyond ACL rules, where you can grant an ACL rule and in the end instead of automatically applying they can be approved.

Lacking full RBAC, a smaller, interim solution could be to add an "approval group" to an ACL rule (or would that be at the zone level?).

1. Add an option to "require approval" at the zone level, designating the zone approver group, default to support users
2. Allow an option to "override" the zone level approval at the ACL rule level.

There is also the issue of "batch changes / DNS requests" have a somewhat different workflow than requests hitting a zone directly. It does complicate this a bit.

Imagine if you will that a batch change goes in that touches 2 zones. Each zone has a different "approver group". How does the entire batch change ultimately get approved in its entirety. (you can amplify this challenge by 1000 as you can make 1000 changes in the same DNS request).

So this is a bit bigger than what I mentioned above. We would need to have "item level approval" on a DNS request.

Not sure how this would work

[JanuszU]

@pauljamescleary I am just describing my scenario. We are a mid size business, having about a 200 zones.
The only usage of two-zone batch request in my situation is an "A + PTR". We do not have a lot of DNS changes but it would be fine to delegate some duties.
Full RBAC sounds really nice but I understand it is a lot of work so any step would be kindly welcommed.

[pauljamescleary]

Thanks @JanuszU , in your common use case "A+PTR", would you require approval for just the "A", just the "PTR", or both?

On our end, typically users do not care much about PTR and do it for completeness, so authorization matters most for the A record / forward zone.

[JanuszU]

@pauljamescleary "A" record is crucial o course, if it helps coding make it just for the forward zones