Skip to content
This repository was archived by the owner on Jul 12, 2023. It is now read-only.

Add auditing and system admin realm joining #705

Merged
merged 2 commits into from
Sep 30, 2020
Merged

Conversation

sethvargo
Copy link
Member

Release Note

Add basic auditing and allow system admins to join realms for recovery purposes

@google-oss-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sethvargo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@sethvargo
Copy link
Member Author

/assign @mikehelmick @whaught

@googlebot googlebot added the cla: yes Auto: added by CLA bot when all committers have signed a CLA. label Sep 29, 2020
audits = append(audits, audit)
}

// TODO(sethvargo): diff allowed CIDRs
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gonna do this later.

@sethvargo
Copy link
Member Author

@whaught @mikehelmick okay - this is ready for review now after a few iterations and virtual rubber-ducking.

High-level overview:

  • There's a new interface in the database package, Auditable, that determines if a resource can be audited. These resources can act as the "actor" (entity that did the action) or "target" (entity upon which the action was taken).

  • Audits are optionally tied to a realm, although some audits are not. There's currently no UI to display non-realm-specific audits, but they are captured and we can always add that later.

  • Audits are automatically cleaned up after 30d (default).

  • Audits intentionally don't use foreign keys so that they remain intact even if the resourcing record is deleted.

  • Audited resources require an auditable actor when calling their Save function. There's a database.System user for tests/when the actor is the system (e.g. seeding, model calculation).

  • Audited resources are currently manually diffed. We already have enough runtime reflection with gorm, and we want to have tight control over which fields are diffed and which order they are diffed. This means the Save functions are verbose, but I think it's worth the tradeoff.

  • Audit entries cannot be deleted (unless you do it directly from the database).

  • With this, system admins can now join and leave realms.

type AuditEntry struct {
Errorable

// ID is the entry's ID.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any reason why not the gorm.Model embed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gorm.Model changes the behavior and semantics for delete. If the resource has DeletedAt, it soft deletes. Audit entries are also immutable and gorm.Model includes an unnecessary UpdatedAt field. Given I expect audit_entries to be our largest table (even with purging), I wanted to keep the number of columns as small as possible.

Copy link
Contributor

@icco icco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like two metrics, they can be saved for future work if you'd like.

Unscoped().
Where("created_at < ?", createdBefore).
Delete(&AuditEntry{})
return result.RowsAffected, result.Error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add a metric, audit_rows_cleaned or something here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally, but it'll be a bit of work because the cleanup job isn't actually configured with metrics right now. I created #716 to add metrics to all the things we cleanup.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack, ty.

package database

// Auditable represents a resource that can be audited as an actor or actee.
type Auditable interface {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My knowledge of gorm is limited. Is there anyway to do a callback here so that we can increment a counter on every audit entry inserted? If there is, can we do it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have access to the tx in the callback, so we can increment a SQL counter (that's how we do the in-app stats actually).

We can create a global callback that has access to metrics and then basically guard it with a if table == "audit_entries". What do you hope to glean from counting the number of audits?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would love a graph in our dashboards to see how many things are happening on a server from an admin point of view. Basically a stackdriver stat that says x number of actions lets us see the rate of actions happening on an instance. Good for debugging or tracking admin abuse.

@icco
Copy link
Contributor

icco commented Sep 30, 2020

/lgtm

@google-oss-robot google-oss-robot merged commit 66aaf0b into main Sep 30, 2020
@google-oss-robot google-oss-robot deleted the sethvargo/audit branch September 30, 2020 14:57
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 6, 2020
flagxor pushed a commit that referenced this pull request Aug 11, 2021
* Allow for v1.5+ early key release. Multiple keys can be provided that all have the same start interval
* Add configuration params for this
* Add tests for new pieces. 100% coverage on exposure model transform.
* Add documentation.
* add same day release as an optional feature to the generate server

Fixes #705
Part of #663
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla: yes Auto: added by CLA bot when all committers have signed a CLA.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Audit trail of user add / remove Let system admins add themselves as a realm admin
6 participants