geoffreywiseman / awswl Goto Github PK

Right now, AWSWL avoids duplicating by trying to authorize ingress and getting an duplicate error. That's worth handling anyway, so it's a good first approach, but it has limitations:

• I suspect it wouldn't complain if you added 192.168.0.1/32 when you already have 192.168.0.1/24, but technically you don't need to add.
• Moto doesn't return this duplicate error, so I can't properly test it.

This is not high-priority, but maybe worth looking into anyway.

Want to be able to find security groups by name/tag rather than having to know the id all the time.

Moto or possibly Both changed in some way that breaks the No Region test; make sure this still works in a real install, and if so, figure out how to trigger with Moto.

I tried a simpler form of a boto API call when I first wrote this, but it broke with Moto, and I discovered that if I used a slightly more complex form of the same boto invocation, it would work. I stuck with the more complex invocation and filed a bug with Moto that has been fixed in the meantime.

Time to test out the simpler API call again, see if the tests pass now that Moto has been updated.

Moto doesn't seem to support Ipv6 permissions right now:
getmoto/moto#1523

If that ever gets added, we should probably add tests for IPv6 CIDRs.

Hi, as shown in the following full dependency graph of awswl, awswl requires botocore * ， while the installed version of boto3(1.10.45) requires botocore >=1.13.45,<1.14.0.

According to Pip's “first found wins” installation strategy, botocore 1.13.45 is the actually installed version.

Although the first found package version botocore 1.13.45 just satisfies the later dependency constraint （botocore >=1.13.45,<1.14.0), it will lead to a build failure once developers release a newer version of botocore.

Dependency tree--------

awswl - 1.0.2
| +- boto3(install version:1.10.45 version range:*)
| | +- botocore(install version:1.13.45 version range:>=1.13.45,<1.14.0)
| | | +- docutils(install version:0.15.2 version range:>=0.10,<0.16)
| | | +- jmespath(install version:0.9.4 version range:<1.0.0,>=0.7.1)
| | +- jmespath(install version:0.9.4 version range:<1.0.0,>=0.7.1)
| | +- s3transfer(install version:0.2.1 version range:>=0.2.0,<0.3.0)
| | | +- botocore(install version:1.13.45 version range:<2.0.0,>=1.12.36)
| | | | +- docutils(install version:0.15.2 version range:>=0.10,<0.16)
| | | | +- jmespath(install version:0.9.4 version range:<1.0.0,>=0.7.1)
| +- botocore(install version:1.13.45 version range:*)
| | +- docutils(install version:0.15.2 version range:>=0.10,<0.16)
| | +- jmespath(install version:0.9.4 version range:<1.0.0,>=0.7.1)
| +- future(install version:0.18.2 version range:*)
| +- ipaddress(install version:1.0.23 version range:*)
| +- requests(install version:2.22.0 version range:*)
| | +- certifi(install version:2019.9.11 version range:>=2017.4.17)
| | +- chardet(install version:3.0.4 version range:<3.1.0,>=3.0.2)
| | +- idna(install version:2.8 version range:>=2.5,<2.9)
| | +- urllib3(install version:1.25.7 version range:<1.26,>=1.21.1) 

Thanks for your attention.
Best,
Neolith

Would be nice to be able to run:
awswl --update-current --desc "GW MBP"

Such that awswl will:

• Check to see if there's an entry with description GW MBP:
  • If not:
    • add it
  • If so:
    • Does existing CIDR block cover current ip address?
    • If so:
      • Report that current ip address is already present and good.
    • If not:
      • Remove old CIDR
      • Add external IP as new CIDR

Similarly: awswl --desc "Bastion Hosts" --update 10.0.0.1/24

Add some kind of listing to the CI build.

Ruff? Type checking? What are the current options?

Using GitHub Actions more than Travis these days.

AWSWL will make calls to api.ipify.org to get the current ip address. If you don't need/want those requests, it will slow down --list a little and make network requests that you might prefer not to make. Add a switch to disable this, like --disable-exip

If I did have a switch, I'd have to print an error if --disable-exip and --add-current or --remove-current were used together, but that's not so hard.

Might be a good idea to make use of the description field -- could indicate which rules were added by AWSWL. Could also potentially use a keyword in the description that could be used for matching. Could default to something like #awswl, and could be used with something like --remove-tagged, with a customization --tag option (which could even be used to set up groups of rules).

Might also be useful to display the description in the list output.

None of this is directly useful to me at the moment, so I'm not building it yet, but it occurred to me, and someone else stumbles across this and it would be immensely useful to them, I'm not opposed to the idea. ;)

This should wait until after the CI build is set up in #8 so that it's clear that the dependency updates haven't caused a build failure.

Should be able to make a release on GHA and have it automatically go to PyPi.