Page MenuHomePhabricator

Audit the WMF LDAP group and limit its permissions
Open, LowPublic


The WMF LDAP group is often mistaken for the "employee" default group. The purpose of this task is to eliminate this misconception by embracing it.

This task has several parts:

  1. Audit the WMF LDAP group to know what permissions it currently has. Ensure this set of permissions matches what is recorded in wikitech.
  2. Coordinate with stakeholders and decide on a minimum set of permissions that all employees should have (preferably ro).
  3. Break out other needed permissions into another group(s).
  4. Implement and update clinic duty and onboarding documentation.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 16 2019, 4:45 PM
colewhite triaged this task as Low priority.Dec 16 2019, 4:45 PM
jcrespo added a subscriber: jcrespo.EditedDec 16 2019, 6:56 PM

"all employees should have"

It was agreed some time ago that not all employees were to be added to the wmf group. The only requirements were to:

  1. Request it
  2. Have a reasonable reason for it

Now, why people with wmf rights but without root should be able to see root passwords through query monitoring is something that I have asked myself many times and reported it as worrying in the past.

@jcrespo that sounds bad to me. Perhaps query monitoring is a great candidate for a more specific and limited group?

Do we have non-roots who're using this actively? We could simply switch that to cn=ops otherwise?

jcrespo added a comment.EditedDec 19 2019, 11:26 AM

I belive mediawiki deployers use it sometimes (I cannot say, we can ask). The issue is that the tool is not segmented for mediawiki-only, it monitors the whole fleet, including sensitive servers like bacula or other sre services. (e.g. think like kibana, where it is most frequently used for mw events, but it has or it will have eventually all system-level logs). I am not as worried for those that use it occasionally but need it, at least partially, but for those that never asked for it (e.g. to access other web services) but got it in the wmf bundle, which was I think the core issue of this ticket.

Related: T62412: ldap/wmf group should not have +2 in Gerrit. This group has been problematic for a while.

Dzahn added a subscriber: Dzahn.Dec 23 2019, 5:18 AM

Wouldn't it be better to create a new group that actually means "wmf employee" and knowingly give that the permissions we agree it should have, rather than trying to remove stuff from the existing group that does not mean "wmf employee"?

Also note in the past I tried to granularize more, for example I created a group for prometheus editing, as several users only required that and to follow least privileges good practices, but it was scrapped .

Do we need a over-all wmf group at all? Would a group per service be better for a granularized access point of view and annual access auditing?