3 ms·

> wipe out the block storage device attached to the VM Does this provide guarantee that subsequent job won't be able to recover the data?

auguzanellato 3y ago
Well, it’s the same as regular GHA runners. On GitHub provided runners you need to explicitly move data between jobs. I find that useful in preventing weird side effects in one job affecting another.
ozgune 3y ago
Yes, a subsequent job won't be able to recover the data. We completely shut down the VM and remove the block device (all files associated with the block device).
- riddley 3y ago
  I think the concern is that a subsequent allocation would have blocks from a previous allocation that could be readable.
amenghra 3y ago
If the data is also encrypted at rest (as they claim it is), then even if the raw data is recovered it shouldn't be useable without a combination of key leak.
- fdr 3y ago
  I work at Ubicloud. Although we have a KEK and DEK code for regular VMs, they are not operative on GHA...yet. The reason has to do with a technical conflict with copy-on-write we aim to close, not least of which because Ubicloud needs to grow its own copy-on-write features for block device snapshots, things we lack today. I expect within a few months, all expired GHA vms will be cryptoshredded upon their deletion. This is already true for regular virtual machines or managed postgres machines.
  - csdvrx 3y ago
    > because Ubicloud needs to grow its own copy-on-write features for block device snapshots, things we lack today. Just, why? CoW (or your own CoA) are ripe with performance problems. How exactly do you benefit from their use?
    - fdr 3y ago
      The GitHub image is 86GB and people want an action VM to start reasonably quickly, so a full copy for every run isn’t going to work so well. As a side note, isn’t it nuts that GHA operates on a principle of “installing the universe” (and apparently the universe is 86GB) and updating about every week, and it’s not total chaos? I was surprised, but it seems to work.
      - k8svet 3y ago
        > As a side note, isn’t it nuts that GHA operates on a principle of “installing the universe” (and apparently the universe is 86GB) and updating about every week, and it’s not total chaos? I was surprised, but it seems to work. As someone who has authored a GitHub Action to delete like 85% of the hodge-podge stuff blasted all over in a default runner image to free up more space for a Nix store. It's "nuts" indeed.
        maxloh 3y ago
        Any GitHub link for your code?

auguzanellato 3y ago

Well, it’s the same as regular GHA runners. On GitHub provided runners you need to explicitly move data between jobs. I find that useful in preventing weird side effects in one job affecting another.

ozgune 3y ago

Yes, a subsequent job won't be able to recover the data. We completely shut down the VM and remove the block device (all files associated with the block device).

riddley 3y ago
I think the concern is that a subsequent allocation would have blocks from a previous allocation that could be readable.

amenghra 3y ago

If the data is also encrypted at rest (as they claim it is), then even if the raw data is recovered it shouldn't be useable without a combination of key leak.

fdr 3y ago
I work at Ubicloud. Although we have a KEK and DEK code for regular VMs, they are not operative on GHA...yet. The reason has to do with a technical conflict with copy-on-write we aim to close, not least of which because Ubicloud needs to grow its own copy-on-write features for block device snapshots, things we lack today. I expect within a few months, all expired GHA vms will be cryptoshredded upon their deletion. This is already true for regular virtual machines or managed postgres machines.
- csdvrx 3y ago
  > because Ubicloud needs to grow its own copy-on-write features for block device snapshots, things we lack today. Just, why? CoW (or your own CoA) are ripe with performance problems. How exactly do you benefit from their use?
  - fdr 3y ago
    The GitHub image is 86GB and people want an action VM to start reasonably quickly, so a full copy for every run isn’t going to work so well. As a side note, isn’t it nuts that GHA operates on a principle of “installing the universe” (and apparently the universe is 86GB) and updating about every week, and it’s not total chaos? I was surprised, but it seems to work.
    - k8svet 3y ago
      > As a side note, isn’t it nuts that GHA operates on a principle of “installing the universe” (and apparently the universe is 86GB) and updating about every week, and it’s not total chaos? I was surprised, but it seems to work. As someone who has authored a GitHub Action to delete like 85% of the hodge-podge stuff blasted all over in a default runner image to free up more space for a Nix store. It's "nuts" indeed.
      - maxloh 3y ago
        Any GitHub link for your code?