Add support for PersistentVolume resource kind

[gsalaz98]

Summary:

➖ Refactors internals of codebase to make adding new K8s object types easier #12
❌ Add SecretReference, ObjectReference, NodeSelector, NodeSelectorTerm, NodeSelectorRequirement, etc.
✔️ : Centralizes the relationship strings under single class for easier tracking in IDE/dev environments (PR opened #11)
➖ Adds object hash (SHA2-256) to object model for tracking down references in neo4j #12
✔️ Fixes bug in attack_path.py where non-plural resource name for Pod was used (PR opened #11)
❌ Add support for choosing neo4j database from CLI
➖ Add support for object recursing for nested objects in resources #12
➖ Refactor re-looping of relationships to be configurable #12
➖ Add BaseResource type for representing nested objects #12
➖ Move some code from Resource to BaseResource to reduce code duplication #12
❌ Move some code in neo4j.py to neo4j_utils.py in attempt to reduce chances of circular import (might not be needed)

Motivation

I'm interested in modeling K8s resources using neo4j for DevOps/SRE purposes and wanted a more complete cluster definition to experiment with. I also read through the issues and noticed that there are some hostPath detections that you may want to make, and thought that this could potentially help out.

I found this project yesterday and I'm in love with it, I think it's a great approach to solving some of the lower-hanging fruits for securing clusters.

I'm upstreaming some changes I made to make onboarding new object types more easy and provide the flexibility of defining new relationship types for objects and their sub-resources.

I'm not expecting to get all of my changes merged in, but I'm willing to work on this repo until it's in a shape where it could be merged in without any issues.

Please feel free to reach out directly to my email if you'd like to establish a dialogue in private.

[Skybound1]

Hey @gsalaz98, glad you like the project :D Also, thanks a lot for the contributions, it is very much appreciated, let's try to get as much of it merged in as we can :D

This is quite a hefty PR with quite a few different areas being changed. To make it slightly easier to go through it all and to let us merge individual components as soon as they're ready (as opposed to having it all ready before merging), do you mind splitting this into multiple PRs? Where each PR covers one of the points you're addressing, fully appreciate some of these PRs might rely on others, and we can prioritise those accordingly ;)

[gsalaz98]

Hey @gsalaz98, glad you like the project :D Also, thanks a lot for the contributions, it is very much appreciated, let's try to get as much of it merged in as we can :D

This is quite a hefty PR with quite a few different areas being changed. To make it slightly easier to go through it all and to let us merge individual components as soon as they're ready (as opposed to having it all ready before merging), do you mind splitting this into multiple PRs? Where each PR covers one of the points you're addressing, fully appreciate some of these PRs might rely on others, and we can prioritise those accordingly ;)

I'll start breaking the PR down today - I've also got PersistentVolumeClaims and MutatingWebhookConfiguration done and on the way, so there'll be a few more PRs than what's on the bullet points. I appreciate the willingness to merge the work upstream, hopefully someone else will find it useful :)

Closing for now in favor of splitting into multiple PRs