Implement auditing

[Ethan-Arrowood]

Description

This PR will implement auditing for platform-chaos. The first reply will be a copy-paste from the first draft of AUDITING.md so we can begin discussing changes.

Closes #18 and #22

Checklist for success

• [ ] This change isn't already implemented by a pending pull request
• [ ] This change is a child commit of a reasonably recent commit in the master branch
  • Requests need not be a single commit, but should be a linear sequence of commits (i.e. no merge commits in your PR)
• [ ] All tests pass locally (see the testing section for more info)
• [ ] All New behaviors or major functional changes have tests

[Ethan-Arrowood]

Going to keep copying and pasting the AUDITING.md file contents here for discussion reference

Auditing

This document defines how Platform Chaos audits chaos events. It lists what is tracked and how it is formatted.

Tracked Data

When a chaos event is initiated or terminated through an API, CLI, or Extension, the following properties are recorded and exported through a JSON object.

• An id unique to this event instantiation (guid).
• A chaos-type of enumerable type initiate
• user and system that terminated the event
• date of event initiation (including time UTC)
• targeted resources. This is broken down by subscriptionID and then by resourceGroup
• Chaos event information (eventID, eventName, eventURL)

Additionally an Extension may record additional information regarding the specificities of the event. This information is stored within an extension property.

Every chaos event type will be logged. The general structure of an event log is defined below:

• event log (Object)
  • id (String)
  • GUID unique to this event instantiation
  • type (String)
  • One of 'initiate', 'terminate'
  • As extension functionality grows, more types can be added to this list.
  • These exist for the purpose of filtering audits.
  • user (String)
  • Some identifiable piece of information specifying which user executed the chaos event
  • system (String | Object)
  • Some identifiable piece of information specifying which system the chaos event was executed from
  • If more system information can be provided, do so in the form of an object
  • date (String)
  • UTC timestamp of chaos event initiation
  • resource (String)
  • String representation of the resource targeted by the chaos
  • This is typically generated by chaos resgen and looks like so: "subId/resGrpId/resName"
  • event (Object)
  • Chaos event properties defined when the event function is typically registered via chaos register
  • eventName (String)
  • eventURI (String)
  • extension (Object)
  • an optional object extension authors can utilize to log pertinant data relate to their module.

Here is an example template:

{
  "id": "",
  "chaos_type": "initiate",
  "user": "",
  "system": "",
  "date": "",
  "resource": "",
  "event": {
    "eventName": "",
    "eventURI": ""
  },
  "extension": { ... }
}

[Ethan-Arrowood]

How would I make this apart of the wiki? Is there a specific name you're looking for in regards to the directory for this file?

[bengreenier]

@Ethan-Arrowood You can add a page to the wiki. I'd prefer wiki over directory - @allydurks thoughts?

[Ethan-Arrowood]

This file has been made into a wiki page available here: https://github.com/Azure/platform-chaos/wiki/Auditing