985361 - simplify Socorro VPN groups

Status: RESOLVED FIXED

(Socorro :: Infra, task)

Description

[Daniel Maher [:phrawzty]]

There are currently four vpn groups related to socorro which contain arbitrary collections of users and machines, and which are used inconsistently (or not all) in Puppet.  I propose that we simplify this by narrowing it down to one group, with one set of users, and the complete list of Socorro nodes.

Advantages include: 
* One single LDAP entry to manage when adding/removing users and machines.
* Very easy to implement in Puppet (consistently).
* Ultimately solves problem of people having seemingly random access to some things and not others.

Disadvantages include:
* Loss of fine-grained access control; though, to be honest, we're not really exploiting this behaviour now anyways.

Comment 1

[Lonnen :lonnen]

phrawzty: there's vpn_socorro which has some people and some machines; vpn_socorro_dev, which has some people and some machines; vpn_socorro_dba, which has just selena and like 2 machines; and vpn_socorro_hbase which has some people and some machines. don't let those labels fool you though - there isn't a lot of coherence to be found.

lonnen: since those are all related to the administration and development of socorro, +1 to merging them we don't need granularity there

Comment 2

[Daniel Maher [:phrawzty]]

I've compiled a list of 110 machines that are either directly part of the Socorro project, or are indirectly associated but still need to be accessible by Socorro team members.  This list was compiled from the existing VPN groups (ipHostNumber field) and from a google spreadsheet that contains a list of all the machines within our budget purview.  There was definitely some overlap between all of these sources, but no one source was anywhere near complete.  As it stands, this list almost certainly contains machines which no longer exist, but it's a good starting point for building a proper list for a Grand Unified LDAP Group.

The primary advantage of the GULG is that we need to maintain only one ACL.  The primary disadvantage of the GULG is that we need to maintain an ACL at all (ideally, there would be some sort of automation that could help us out here).  That said, I strongly suspect that Socorro is going to get a dedicated VLAN down the line, in which case we could just insert the netblock (CIDR) and be done with it.

WIP.

Comment 3

[Selena Deckelmann :selenamarie :selena]

(In reply to Daniel Maher [:phrawzty] from comment #2)

> The primary advantage of the GULG is that we need to maintain only one ACL. 
> The primary disadvantage of the GULG is that we need to maintain an ACL at
> all (ideally, there would be some sort of automation that could help us out
> here).  That said, I strongly suspect that Socorro is going to get a
> dedicated VLAN down the line, in which case we could just insert the
> netblock (CIDR) and be done with it.

That is very very exciting!  Thanks so much for putting this together.

Comment 4

[Daniel Maher [:phrawzty]]

There is now an LDAP group called "vpn_socorro_all" which contains all(?) of the necessary hosts and users.  This LDAP group is now implemented by the "socorro::access" class.

Now to roll this class out to All The Things.

Comment 5

[Daniel Maher [:phrawzty]]

I rolled this out today. There are still some edge cases (basically nodes that aren't specifically named in Puppet, uuggghhh), but it's mostly done.