Cartography: Graph view of infrastructure assets and relationships between them
github.com
github.com
I once built a terraform provider for a custom neo4j cmdb to be able to add metadata in the form of additional relationships to anything provisioned with TF.
This data was used for config inventory, job scheduling and a bunch of other automations/rules.
Broke the ”cloud vendor” boundry this way and we used it seamlessly against on-prem vsphere and aws.
Never got around to open source it, unfortunately.
A graph for this type of cmdb/config data is really useful.
Thanks for the comment! Cartography can definitely be extended to do multi-cloud but we're focusing on AWS at the moment. At the same time though we didn't want to discourage others from looking at this by saying in the docs that it was solely an AWS project. There's nothing really stopping it from supporting other data sources.
Edit: we're planning on adding a GitHub module soon too.
If you're curious about this stuff for more day-to-day, we (Graphistry) add some crazy GPU graph visual analytics + visual templating / automation for daily tasks + DB connectors. Think automatically mapping your daily splunk alerts across host/network/intel data, or seeing your entire data center, or going through a ton of DNS logs for bots/intel. Super fun space right now! Ex: http://labs.graphistry.com/graph/graph.html?dataset=PyGraphi...
And Sacha of Lyft was previously using similar techniques on the red team at Microsoft.
The awesome Bloodhound project productizes some of the red team use cases: https://github.com/BloodHoundAD/Bloodhound/wiki
Check our Readme; we definitely had to give a shout-out to BloodHound :-).
Cartography doesn't.
But, words are just words.
This kind of software usually its licensed for the number of elements it tracks... and the costs add up easily (hosts, network ports, IP addresses, OS, Application, assets counts as one element and you end up tracking 1000s of them).
Edit: OP changed response to remove certain references, presumably because something sensitive was revealed. Changing my response out of respect.
Good question. As is, this does not keep anything in sync.
To keep the graph in sync with changes in the account, simply set up a cronjob to run `cartography` whenever you would need a refresh. Each sync run should guarantee that you have the most up-to-date data.
Here's how a sync works: when the sync starts, set a variable called `update_tag` to the current time. Then, pull all the data from your AWS account(s) and create Neo4j nodes and their relationships, making sure to set their `lastupdated` fields to `update_tag`.
Finally, delete the left over nodes and relationships (i.e. those that do not have up-to-date `lastupdated` fields). This way the data stays fresh, and you can see this in the [cleanup jobs](https://github.com/lyft/cartography/tree/master/cartography/...).
Our approach requires us to stay as real-time as possible, so we're actually using CloudWatch events to keep in sync -- the deletes become a little hard after that.
I look forward to the progress of Cartography, though!
The downside of AWS providing something like this out of the box would be complete lack of usability. There's a running not-even-a-joke that whatever UI an AWS service comes with, it's going to be at best an excuse. If you want to make a good use of a feature/offering in their stack, you have to write your own tools for it.
Don't get me wrong, the APIs in AWS are, for most parts, quite nice to work with. [asterisk goes here] -- It's the stock UIs in their web console that are maddening and (IMO) barely fit for anything productive.
Ontologies never took off because I think they tried to encompass too many things, where graphs are a simple tool you can use to build them as part of a greater idea.
It is in many ways well suited as it is so easy for even non-tech people to understand and even query.