Our great sponsors
-
I went down a bit of a rabbit hole of Digital Ocean and their "security" for production workloads.
> Show me any other vps provider that silently provides access to customer A's data to customer B after receiving commands from customer A to destroy their instance and then I'll believe you guys aren't at the very bottom of the "takes security seriously" list.
From: https://github.com/fog/fog/issues/2525#issuecomment-31337481
YC News Discussion: https://news.ycombinator.com/item?id=6983097
> You do not need to scrub or write anything to not provide user A’s data to user B in a multi-tenant environment. Sparse allocation can easily return nulls to a reader even while the underlying block storage still contains the old data. ... On top of all of that, when I pointed out that what they were doing was absolute amateur hour clownshoes, they oscillated between telling me it was a design decision working as intended (and that it was fine for me to publicize it), and that I was an irresponsible discloser by sharing a vulnerability.
From: https://news.ycombinator.com/item?id=20091026
> You've got an additional problem though, which is that this tells us you have two support channels: one that doesn't work (i.e. yours, the one you built), and one that does (Twitter-shaming). The first channel represents how you act when no one's watching; the second, how you act when they are. Most people prefer to deal with people for whom those two are the same.
From: https://news.ycombinator.com/item?id=20064169
Speaking of randomly locking accounts, the post-mortem kills me:
> The initial account lock and resource power down resulted from an automated service that monitors for cryptocurrency mining activity (Droplet CPU loads and Droplet create behaviors). These signals, coupled with a number of account-level signals (including payment history and current run rate compared to total payments) are used to determine if automated action is warranted to minimize the impact of potential fraudulent high-cpu-loads on other customers.
From: https://www.digitalocean.com/blog/an-update-on-last-weeks-cu...?
In other other words, DO will kill your account with a curt email staring simply: "We have reviewed your account and have declined to activate it. No further information or action is required from you." for simply using "too much CPU"! https://pbs.twimg.com/media/D76ocofXoAY_xB5.png
-
Unfortunately restic was a no go for me due to not being compatible with B2 keys that only have the permissions readFiles,writeFiles,listBuckets,listFiles (no deleteFiles). I don't want the attacker to be able to delete any backups if the manage to get to the B2 keys.
I believe this is the ticket that would add support for this to restic: https://github.com/restic/caddy/issues/2
-
PopRuby
PopRuby: Clothing and Accessories for Ruby Developers. Fashion meets Ruby! Shop our fun Ruby-inspired apparel and accessories designed to celebrate the joy and diversity of the Ruby community.
Related posts
- Show HN: Manage on-prem servers from my smartphone
- Show HN: Built a Cloud-native Stack for Ollama: Build locally and push to deploy
- Build internal tools with Infrastructure as Code
- CloudCarbonFootprint: Estimate energy use and carbon emissions from cloud usage
- Configurar AWS Signer en lambda con terraform