feat: AWS EC2 route table initial support

[achantavy]

Summary

Describe your changes.

Adds initial support for AWS EC2 route tables, routes, route associations, and subnet / gateway targets.

Schema diagram of what this PR accomplishes:

• The dotted lines indicate not done yet
  

These can be resolved in a fast follow. For now, I think this is a decent chunk ready for review.

Related issues or links

Include links to relevant issues or other pages.

N/A

Checklist

Provide proof that this works (this makes reviews move faster). Please perform one or more of the following:

• Update/add unit or integration tests.
• Include a screenshot showing what the graph looked like before and after your changes.
  
• Include console log trace showing what happened before and after your changes.
  I have run this locally e2e and it works.

If you are changing a node or relationship:

• Update the schema and readme.

If you are implementing a new intel module:

• Use the NodeSchema data model.

[cubic-dev-ai]

mrge found 9 issues across 8 files. View them in mrge.io

[cubic-dev-ai]

mrge found 7 issues across 8 files. View them in mrge.io

[jychp]

General feedback:
Overall, the code looks correct and functional.

Design question:
Do we really want to have a RouteTableAssociationSchema node? It seems to be a 1-to-1 relation between the parent and child nodes. Is this node truly necessary, or could it be replaced by a direct relationship between RouteTable and EC2Subnet (or other relevant nodes)?

[jychp]

Opinionated and non-blocking comment:
Having is_main default to false and targetdefault to"main"can be a bit confusing. I would have leftis_maindefaulting to false and settarget = "main"` inside the else block (since there's an else block, target will always be defined, so it's not an issue).

[jychp]

May be we can add a debug log here if the route target key is not found, that would help in the future if new target are added.

[jychp]

Not sure if this is an actual issue, but since the function's goal is to generate a unique ID, could there be a scenario where two routes within the same route_table_id both point to a KEY that's not defined in the array? In that case, the function would return something like route_table_id,None for both, which wouldn't be unique.

[jychp]

after further reading it seems there is no impact

[achantavy]

Right, this collision would happen if a new route target key is introduced by AWS that we don't support. I'll update so that we log a warning.

Otherwise though, the route data structure is like a 'union' data structure where it is designed so that only one of those target keys will be present.

[achantavy]

Do we really want to have a RouteTableAssociationSchema node? It seems to be a 1-to-1 relation between the parent and child nodes. Is this node truly necessary, or could it be replaced by a direct relationship between RouteTable and EC2Subnet (or other relevant nodes)?

Good catch. Yeah, I struggled here a bit. I'm pretty new to AWS networking so I started out just by doing a naive object by object model. I think you're right: association to subnet / gateway is 1-1, and I think the design would be better to remove the intermediary

[achantavy]

Oh, there is a reason why I did it:

• If a route table is connected to an internet gateway via an association, then that means the internet gateway is used for ingress.

• On the other hand, if a route table is connected to an internet gateway via a route, then that means the internet gateway is used for egress.

These cases seem complex and not straightforward so I figured the simplest way to avoid future misunderstanding was to just model it API object by API object. I'm open to thoughts here though on a smarter way.

[jychp]

I think both approaches are valid, but there should be clear guidance at the project level.

After a bit of thought, here’s my take:

• Stick as closely as possible to the source provider’s data model for the base nodes.
• Introduce an abstraction layer only when we need to represent more generic concepts shared across multiple providers.

This way, we preserve the maximum amount of information, keep the tool easy to adopt for anyone (e.g., if I come from AWS, I don’t need to learn a new data model—it’s the same as AWS), and still allow for cross-provider intelligence through higher-level abstractions, if needed.

[achantavy]

Stick as closely as possible to the source provider’s data model for the base nodes.
Introduce an abstraction layer only when we need to represent more generic concepts shared across multiple providers.

Agree

[achantavy]

Will take an action to add that to intel module documentation

[jychp]

LGTM

[achantavy]

@krisek - we finally got around to it; thought you'd find this interesting :)

should be in 0.102.0rc2