Closed Bug 1477782 Opened 6 years ago Closed 6 years ago

audit "hackers" and "hackers plus" groups

Categories

(Socorro :: General, task, P2)

Product:
Socorro
Component:
General
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: willkg, Assigned: willkg)

References

Details

Attachments

(3 files)

pr 4525: bug 1477782: implement auditgroups Django command
53 bytes, text/x-github-pull-request
Details | Review
pr 4529: bug 1477782: adjust output of auditgroups
53 bytes, text/x-github-pull-request
Details | Review
pr 4530: bug 1477782: change dryrun to persist
53 bytes, text/x-github-pull-request
Details | Review 
Crash Stats site has users. Some users are in the "hackers" and "hackers plus" groups which grant them privileges to view PII in crash report metadata and raw dumps.

This group is not automatically maintained and requires a manual audit periodically.

If we inadvertently remove someone from a group that should continue to have access, they can request access again.

This bug figuring out the audit process and then performing the audit.
As a side note, Crash Stats doesn't have any automatic auditing of accounts in these groups, but access to the site is gated by Mozilla SSO which is tied to LDAP, so people can't access Crash Stats if they're no longer an employee. This is predominantly just bookkeeping work.

I was thinking we'd remove people who:

1. don't have a valid Mozilla email address
2. haven't logged in the last year

Lonnen: Does that look ok to you?
Assignee: nobody → willkg
Status: NEW → ASSIGNED
Flags: needinfo?(chris.lonnen)
Priority: -- → P2
I think we should commit to this as a policy in Mana, warn users we're adding this policy, and then enforce the policy. I don't expect push back. (Re)activating an account is pretty quick.

Will: 
1. What do we do about api keys? A user may not log in but have active keys in automation?
2. Manual or automatic?
Flags: needinfo?(chris.lonnen)
Great questions!

1. What to do about API keys? API keys all have expiration dates and are tied to user accounts. If we disable a user account, the related API keys will stop working.

Two interesting things about that:

First, because API keys expire, then users are forced to log in to create a new API key. Active accounts will not get swept up in this audit.

Second, we have a few API keys that have crazy far-in-the-future expiration dates since they're used by release engineering. If we make sure not to remove accounts that have active API keys, then these accounts will not get swept up in the audit.

So we should be all good here.

2. Manual or automatic? I was thinking this first pass should be manual and then we could figure out whether to do it automatically or not. Having said that, now I'm inclined to do this as a crontabber job and have it run once a week. That's probably less work.


I'll write up a policy section in Mana next.
I added this to the mana page:

> Auditing of Hackers group
> 
> The Hackers group will be audited weekly and members who do not meet the following
> criteria will be removed:
> 
> 1. users who do not have a Mozilla email address
> 2. users who have not logged into the site in over a year and have no active API keys

https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=5734601#crash-stats.mozilla.com(Socorro)-AuditingofHackersgroup

Does that cover what we need clearly enough?
Flags: needinfo?(chris.lonnen)
Now that I see it next to the section about getting access to the data, maybe we should expand that instead of having an independent section.
Flags: needinfo?(chris.lonnen)
I added another line to the agreement that users must consent to in order to get elevated access regarding account activity.

I also tweaked that whole section so it's clearer that one part is the process for getting elevated access and one part covers the auditing.

https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=5734601#crash-stats.mozilla.com(Socorro)-CrashStatsgroupsandPIIaccess

Does that work better?
Yes. This looks good
I sent an email to the stability list.

I think I'm going to write a crontabber job to do the work and push it out in "debug mode" where it'll tell us what it's going to do without actually doing anything. That'll let us know whether it works or not before we turn it on. That seems easier than trying to do a manual audit using the Django admin.
I added a Django command which I'll have Ops run manually. We'll run it as a dry run, I'll verify what it did, then we'll run it for realz.

I'm going to have to spin off "let's do this automatically every week!" to a new bug. I need to fix some crontabber issues first.
I landed this and it's on -stage.

I emailed Brian and Miles asking someone to run it in dry run mode on stage. I'll verify the output.

Then I'll deploy to prod next week and I'll have someone run it in dry run mode and I'll verify the output there.

Then I'll get Miles or Brian to run it for real on stage and prod.
That landed and got deployed to stage. Miles ran it on stage a few times. I need to tweak the command arguments, but otherwise it works fine.

On stage, we had 79 people in the hackers group. Now there are 6.

I'm going to fix the command arguments now and get that landed. Then we'll run it in prod.
I landed another fix to make the cli better. We pushed that to prod today and ran it in prod.

There were 147 people in the hackers group. Now there are 98.

I also removed a couple of people from the "hackers plus" group who are inactive. That group only has a few people in it and we can manually audit it.

This bug covered auditing the two groups which is now done. I wrote up bug #1480214 to run that on a periodic basis.

Marking this one FIXED.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Making this public.
Group: mozilla-employee-confidential
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: