Initial design for ExternalService API with service for public IP

[RaitoBezarius]

Description

As per to #235 ; I'm trying to see what kind of external service API would fit the usage in Kube Hunter (as in, it's generalizable for other external services). Here is an initial idea, I didn't want to go full OO magic, using singletons pattern & whatever.

This is a very simple PR, though it has the potential for external plugins to use their own providers of public IP, it can be used to modify if you want IPv4/IPv6, it can accommodate special use cases: when you want private IP, let's say, you're in a private VPC or something like this.

Two things are left as questions and require feedback:

• Test, how do we want to go? I can test for generic failures using mock and ensure that try_get calls the second provider. That's a simple enough and relevant test to do. But before, I want to know if that'd be interesting to move this logic into a base class called ServiceWithFailover which enables this pattern.
• Propagate a form of configuration to the modules, if we want to globally use only this provider, we may want that all subsequent instances of ExternalService instantiates using only those specific providers, what I usually suggest is to use module name which are importable: ["plugins.external_providers.canhazip", "plugins.external_providers.ipify"] for example, this can be configured in some file or even in the conf.py if #264 is merged.

This enables new patterns to configure stuff using environment variables too. Anyway, I need feedback to understand what maintainers feel is the most appropriate for this project.

Bonus: Ipify.org is added.

Fixed Issues

Fixes #235

Contribution checklist

• [x] I have read the Contributing Guidelines.
• [x] The commits refer to an active issue in the repository.
• [ ] I have added automated testing to cover this case.

Notes

As above-mentioned, automated testing is a question.

[lizrice]

Sorry it has taken so long to get back to you on this @RaitoBezarius - we had a lot of Hacktoberfest changes and then KubeCon. I like the general idea of this, will leave it with @iyehuda and @itaysk to figure out how they want to take this forward.

I realized we could be querying https://canihazip.com/s which returns simply the IP address, which I think would be better than http://canihazip.com. Which then begs the question whether it's worth falling back between one service and another identical one, but I suppose one of them might be down.

[RaitoBezarius]

@lizrice No problem, I have some cleanup to do myself on my contributions. Regarding the HTTPS vs HTTP stuff, it's baked in this PR (except the final /s I suppose), this was a low hanging fruit I guess which is cool. One of them might be down, worst, one of them might be blocked (?).

To me, as a red teamer, this is the kind of the tool I'd use for initial recognition (it's super cool and I really appreciate Python was used for this because it makes it easier for me to extend than Ruby/Perl stuff I deal with), I have done some tests with it and it gave really interesting results.

In a corporate environment or in certain super strange contexts, it is really important for me to control that kind of service. Better, it enables me to switch a public IP service for a private IP service, which is really neat in cloud infrastructures (if it makes sense for the tool or during an assessment).

So… I guess I'll just do a real effort and clean my PRs so you guys can see how do you want to move forward with this.

[iyehuda]

Hi @RaitoBezarius !

Any progress made?

[RaitoBezarius]

Hi @RaitoBezarius !

Any progress made?

Hi there, I addressed most of the comments, I'll fix the conflicts and I need to ask you regarding the base class stuff.

[danielsagi]

Closing.. a lot of those changes are not longer relevant. changing cloud discovery is already planned to be implemented differently. and we no longer rely on canhazip.com