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.

In “Mapping Moving Clouds: How to stay on top of your ephemeral environments with Cartography” I described the process I undertook to deploy Cartography in a multi-cloud environment, from inception to self-service dashboards for data consumption.

Now, I’m going to open source an automated process to get Neo4J and Cartography up and running in a Kubernetes cluster, using HashiCorp Vault as a secrets management engine.

In “Deploy Your Own Kubernetes Lab” I covered multiple deployment options for a Kubernetes lab, ranging from more lightweight (like running Kubernetes locally) to more realistic ones (like deploying a multi-node cluster) suitable for security research.

In this blog post, I’m going to detail the steps I took to deploy my own Kubernetes Lab on baremetal, and on an Intel NUC in particular.

If you had to architect a multi-account security logging strategy, where should you start?

This blog, part of the “Continuous Visibility into Ephemeral Cloud Environments” series, will describe a design for a state of the art multi-account security-related logging platform in GCP.

A previous post covered a similar setup for AWS, hence I tried to follow the same structure here. A later post will cover a setup for Kubernetes instead.

This week Google introduced GKE Autopilot, defined as a fully managed, hardened Kubernetes cluster out of the box, for true hands-free operations.

I was curious to take a look at it, so if you don’t have time to play with it, I did it for you.