<story><title>Fast CI with MicroVMs</title><url>https://blog.alexellis.io/blazing-fast-ci-with-microvms/</url></story><parent_chain></parent_chain><comment><author>throwawaaarrgh</author><text>&amp;gt; I spoke to the GitHub Actions engineering team, who told me that using an ephemeral VM and an immutable OS image would solve the concerns.&lt;p&gt;that doesn&amp;#x27;t solve them all. the main problem is secrets. if a job has access to an api token that can be used to modify your code or access a cloud service, a PR can abuse that to modify things it shouldn&amp;#x27;t. a second problem is even if you don&amp;#x27;t have secrets exposed, a PR can run a crypto miner, wasting your money. finally, a self-hosted runner is a step into your private network and can be used for attacks, which firecracker can help mitigate but never eliminate.&lt;p&gt;the best solution to these problems is 1) don&amp;#x27;t allow repos to trigger your CI unless the user is trusted or the change has been reviewed, 2) always use least privilege and zero-trust for all access (yes even for dev services), 3) add basic constraints by default on all jobs running to prevent misuse, and then finally 4) provide strong isolation in addition to ephemeral environments.</text></comment>
<story><title>Fast CI with MicroVMs</title><url>https://blog.alexellis.io/blazing-fast-ci-with-microvms/</url></story><parent_chain></parent_chain><comment><author>no_wizard</author><text>Firecracker is pretty great, good to see it can be used in a CI environment like this, definitely peaking my interest.&lt;p&gt;I know its the backbone of what runs fly.io[0] as well&lt;p&gt;[0]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;fly.io&amp;#x2F;docs&amp;#x2F;reference&amp;#x2F;architecture&amp;#x2F;#microvms&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;fly.io&amp;#x2F;docs&amp;#x2F;reference&amp;#x2F;architecture&amp;#x2F;#microvms&lt;/a&gt;</text></comment>