search

woodpecker-ci / autoscaler

Scale your woodpecker agents automatically to the moon and back based on the current load.
Apache License 2.0
30 stars 5 forks source link

Add AWS provider #118

Open hhamalai opened 5 months ago

hhamalai commented 5 months ago

Add autoscaler provider to execute builds on AWS

anbraten commented 5 months ago

Thanks for your work. I guess AWS is affected by https://github.com/woodpecker-ci/autoscaler/issues/91 as well, right?

henkka commented 3 months ago

Thanks for your work. I guess AWS is affected by #91 as well, right?

I believe this pull request is not affected by the issue mentioned in #91 because the AWS Instance Metadata Service v2 hop limit configuration in https://github.com/woodpecker-ci/autoscaler/pull/118/files#diff-c77d8b5077c4d2c3350ad7ca994ceffe1737935b4e1390f0963acca2d338ca67R74 prevents the containers from connecting to the Instance Metadata API 🤔

https://www.element7.io/2023/01/shift-left-security-why-you-should-use-aws-imdsv2-explained-in-detail/ seems to summarize the hop limit as

It becomes interesting once you know that with IMDSv2, the PUT response containing the secret token can, by default, not travel outside the instance. This is accomplished by having a default Time To Live (TTL) on the low-level IP packets containing the secret token set to “1”. Hardware and software that handle packets, including EC2 instances, subtract 1 from each packet’s TTL whenever they pass it on. If the TTL gets to 0, the packet is discarded. A packet with a TTL of “n” can therefore make n “hops” in a network before giving up, while a packet with a TTL of “1” can exist in just one. In the context of IMDSv2, we refer to hop limit of the PUT call instead of TTL. By using a default hop limit (TTL) of 1, a session token can only be used directly from the EC2 instance where that session was initiated.

and without the IMDS session token the cloud-init user-data cannot be fetched