Closed Bug 1600845 Opened 5 years ago Closed 5 years ago

automatically expire API keys

Categories

(Location :: General, enhancement, P2)

Product:
Location
Component:
General
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED MOVED

People

(Reporter: willkg, Unassigned)

Details

In MLS, we have a different types of API keys and one of those types needs to auto-expire in 3 months. Currently, there's no way to do that.

We need the following:

  1. a way to set some API keys to expire on a specified date
  2. a way to denote which API keys are active and which are not
  3. an automated way to deactivate API keys that have expired on a daily basis

For that, I think we need at least an "expires_on" datetime field and a "active" boolean field. We need something to auto-expire API keys once a day--probably a scheduled celery task. Or something along those lines.

This bug covers figuring that out and building it.

ckolos says we delete keys from the table that are no longer active. Given that, we don't need to add an "active" boolean field.

So then the requirements are this:

  1. add a way to set some API keys to expire on a specified date
  2. an automated way to delete API keys that have expired daily

Seems like we can add an "expires_on" date field to the table that's either NULL or a valid date. Then we can add a task that deletes API keys that have expired. Plus it should log the expiration in a easy-to-reconstruct manner.

ckolos: Does this look correct? Should we add an "eventlog" table with a log of what keys got deleted when? Do we want notifications somewhere? Is there anything else we should be thinking about when doing this?

Flags: needinfo?(ckolos)

I agree with the requirements set in #c1.

Flags: needinfo?(ckolos)

I never moved further with this. In the weekly meetings, it was clear that the current system was preferred to making changes. Further, the requirements set in comment #1 don't cover possible performance issues from deleting keys from the table. So I think that plan is bunk.

We had a recent discussion (June 22, 2020) about this. We've had some issues with API keys that we thought were disabled that were still enabled, and we continue to get API key requests. There is additional metadata, such as human-readable names, that are useful when exploring the data or creating dashboards.

The consensus is moving toward expanding the API key model and adding an API key dashboard.

Possible model additions:

  • License type: Commercial Project, Public Interest Project, Mozilla
  • Firefox: True if used in a Firefox deployment, by Mozilla or a Linux distribution
  • Organization: Human-readable name of the licensing organization
  • Comment: Administrator comment
  • Created / Modified: creation and modification dates, nullable for historical keys
  • Expiration: date the key should no longer be valid
  • Abandoned: True if we believe the key is no longer in use

My thoughts about an API key dashboard are heavily influenced by the Django admin, which provides:

  • A web-based UI for browsing, filtering, creating, and updating items
  • Defaults and form validation

This could be hosted in a way that is only accessible to administrators, for example requiring the VPN and an LDAP-backed login. Other nice features would be embedded usage graphs, such as those generated by Grafana.

Moved to GitHub issues:

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → MOVED
You need to log in before you can comment on or make changes to this bug.