Today I want to talk a bit about a side project I’ve been working on for a while, but never actively publicised it.

As a security engineer I often like to test new tools and technologies related to Kubernetes, but I realised I didn’t have a proper environment to do so.

Lately, a few people have been asking me about my methodology to keep track of progress at work. In this blog post I’m going to share the process I follow to create and share weekly digests, both for me and my team.

Over the past couple of weeks, I started thinking a bit more about adding resiliency to my personal projects and accounts.

In a previous post (“Automated Github Backups with ECS and S3”) I started by taking a look at how to back up my Github data. In this blog post, instead, I’m going to focus on GDrive, since it is where I store the majority of my personal data.

Over the past couple of weeks, I started thinking a bit more about adding resiliency to my personal projects and accounts. You can follow my entire thought process on Twitter (see the embedded Tweet below), but in this blog post I’m going to focus on Github.

Following AWS, the second most critical service for my projects is Github: 90% of my code is stored there (mostly in private projects), and I have to admit I never took a backup of this data.

So I finally decided to set some time aside to set up an automated process to backup my Github account, and I ended up relying on ECS (Fargate) and S3 Glacier. This blog explains the architecture and implications of the final setup I decided to go with.

Congratulations! You have been tasked with establishing a cloud security strategy. Now what?

In this post, I’m going to walk through actionable advice that can be undertaken to establish a cloud security program aimed at protecting a cloud native, service provider agnostic, container-based, offering.