The title makes it seem like this is a major or systemic issue, but the article content essentially says this was a one-off, potentially a mistaken omission that was fixed within 24 hours. The article itself even states that the Post routinely discloses its ties to Bezos in its reporting and this was an anomaly. I used to read the Post (I’m not a subscriber anymore) but I do distinctly remember seeing such a disclosure all over the place. Is this an attempt at outrage clicks?
Edit: people saying I didn’t read the article apparently didn’t read it themselves. From the article:
> The Post has resolutely revealed such entanglements to readers of news coverage or commentary in the past … since 2013, those of Bezos, who founded Amazon and Blue Origin. Even now, the newspaper's reporters do so as a matter of routine.
So at minimum the article disagrees with itself, but it seems the outrage bait is working hook line and sinker.
Edit 2: To try and be a little clearer here: the article is trying to (but in my opinion doing a really poor job of) make a distinction between the disclosures that the non-editorial WaPo authors do, and the disclosures that the editorial authors do, with the assertion that the editorial authors are worse at it.
Within AWS this role falls under the Systems Engineer job family. It is not a devops role, and its involvement in events like today would be the same involvement as every other SWE at Amazon.
Just do a quick google search for that “40% of devops laid off” and you’ll see that it’s actually an old article from months ago that multiple people, including AWS employees, are saying is bullshit and unsourced.
edit: found another source that says this 40% number came from an AWS consultant that worked with customers to help them be better at DevOps, and it was 40% of their specific team that was laid off. Even if it were true, it has nothing to do with the internal operations of AWS services. This is why it’s important to understand the information you’re sharing before making judgements off of it.
AWS does not have dedicated devops roles. All AWS SWEs are expected to take oncall shifts and respond to incidents, manage build pipelines, etc rather than having specific devops people to do it for them. The article you linked claiming 40% of them were fired is total junk. You can believe that or not, I don’t care.
The last one is a ProServe role, which is a consulting role that spends their time working in customer environments, which is where they may encounter terraform. It does not mean anything about internal use of terraform.
AWS doesn’t even have a “devops team” nor even any devops job roles. AWS also does not use Terraform (which is what the article says everyone was replaced with) at any significant scale, so this article is similar junk.
> One of the benefits of Litestream 0.5.0 is that there’s now an official litestream Docker image. All of my previous Docker containers required a lot of boilerplate to download the correct version of Litestream and make it available in my container, but now it reduces to a single Dockerfile line
There’s been an official Litestream container image for over 3 years at this point (since version 0.3.4, it’s at the same Docker Hub as 0.5.0).
Homelabbing is a hobby for most people involved in it, and like other hobbies, some people dip their toes in it while others go diving in the deep end. But would you say it’s “overkill” for a hobbyist fisher to have multiple fishing poles? Or for a hobbyist painter to try multiple sets of paintbrushes? Or a hobbyist programmer to know multiple programming languages?
There’s a lot of overlap between “I run a server to store my photos” and “I run a bunch of servers for fun”, which has resulted in annoying gatekeeping (or reverse gatekeeping) where people tell each other they are “doing it wrong”, but on Reddit at least it’s somewhat being self-organized into r/selfhosted and r/homelab, respectively.
Ahh you’re right, there are some that just initiate a connection via something like Session Manager, but those connections where AWS initiates the connection for you are logged in CloudTrail, even without data events, and root doesn’t give you any ability to directly SSH into an instance outside of those methods (you cannot, for example, use root to find out what the private keys are for logging into an instance) so we’re back to the fact that any such access would be auditable.
SSH is totally irrelevant here. Having AWS root account access doesn’t give you any ability to SSH to or otherwise access running instances. You could access data on those instances by cloning the EBS volumes or modifying build pipelines or changing network access or similar, but these would all show up in CloudTrail even without data events enabled.
For S3 objects, you don’t necessarily need data events to identify if tampering happened. S3 objects are immutable as well, so if any changed you would see that reflected in the creation date and new hashes that S3 attaches as tags, which you can correlate with application logs to see if they match up or not. It’s not as simple as data logging, sure.
But you’re also missing the key component here that they did not say they only just enabled CloudTrail logs, they’re saying they just now enabled CloudTrail log alerting. We don’t have any idea if data events were enabled or not, or if things like flow logs were enabled or not, or what other investigation tools they have running at the application layer. However, even if none of existed, there’s still a lot more audit-ability of events that happen in an AWS account than you’re implying, even the root account.
CloudTrail logs for the last 90 days are enabled by default, cannot be turned off, and are immutable, even by root. If you view this “event” as starting when Arko was supposed to have their access terminated, that’s within the 90 day window and you can indeed trust the logs from that period.
You can still generate the QR code in the desktop and scan it with your phone camera. The device receiving the file does not have to be the device that scans the code.
Of the big three cloud providers, only GCP uses containers for customer isolation, and they do so with the supervision of gVisor. It’s certainly possible to do container isolation securely, but it takes extra steps and know-how, and I don’t think anyone is even considering using gVisor or similar for the type of developer workflows being discussed here.
AWS and Azure both use VM-level isolation. Cloudflare uses V8 isolates which are neither container nor VM. Fly uses firecracker, right?
This topic is kind of unnecessary for the type of developer workflows being discussed that the majority of readers of this article are doing, though. The primary concern here is “oops the agent tried to run ‘rm -rf /‘“, not the agent trying to exploit a container escape. And for anyone who is building something that requires a better security model, I’d hope they have better resources to guide them than the two sentences in this article about prompt injection.
The public land situation in the western US is vastly, vastly different from the situation in the east. Just like you’re saying comparing the US to the UK are two different situations, you also have to treat parts of the US separately.
Almost all of the US’s public lands are west of the Rockies. If you live in Colorado, California, Oregon, Washington then you can basically throw a rock and hit some public lands. East of the Rockies, you can go your entire life without ever even seeing public lands.
Again, this isn’t at all in the scope of restic’s docs. If you’re using S3 as the storage, it’s on you to understand how S3 works and what permissions are needed, just like it’s on you to understand how your local file system works and file permissions work if you use the local file system as a backend.
If you don’t understand S3 or don’t want to learn, then that’s fine, and you can pay the premium to tarsnap for simplifying it for you. But that’s your choice, not an issue with restic.
If you think differently, have you submitted a PR to restic’s docs to add the information you think should be there?
That’s because restic is not opinionated about where and how you store your backups. Restic provides a nice interface to create the backups, and then lets you choose where you want to store them (and how access to them is managed), be it locally or via SFTP or S3 or many other backends. Any security properties related to S3 are not in the scope of what restic is meant to do.
It’s pretty simple to enable versioning and object lock on your S3 bucket, but it is another step if you’re using restic. Sure, if you just want all of that taken care of for you, you can use tarsnap, but you’re paying a 5x+ premium for it.
The other nice thing about restic is that since it’s just the client-side interface, it allows others to provide managed storage. Borgbase.com is a storage backend that is supported by Restic that supports append-only backups, and is cheaper than tarsnap.
The pricing isn’t due to AWS. Even if you used standard S3 and paid for data retrieval for your entire backup every single month, tarsnap is over 3x the price of just using S3 yourself. The markup on tarsnap is wild.
Using something like restic or borgbackup+rclone is pretty much the same experience as tarsnap but a fraction of the price.
Edit: people saying I didn’t read the article apparently didn’t read it themselves. From the article:
> The Post has resolutely revealed such entanglements to readers of news coverage or commentary in the past … since 2013, those of Bezos, who founded Amazon and Blue Origin. Even now, the newspaper's reporters do so as a matter of routine.
So at minimum the article disagrees with itself, but it seems the outrage bait is working hook line and sinker.
Edit 2: To try and be a little clearer here: the article is trying to (but in my opinion doing a really poor job of) make a distinction between the disclosures that the non-editorial WaPo authors do, and the disclosures that the editorial authors do, with the assertion that the editorial authors are worse at it.