Kubernetes & container security tips

Nice talk on modern K8s and container security tips by Google's Samuel Davidson:

(Backup link)

The highlight for me: 

Using “distro-less” base images seems like a recommendation that's easy to do and would help make post-exploitation harder.

Samuel has put all his recommendations in this doc.

Other resources I've come across lately:

• Sysdig's SELinux, Seccomp, Sysdig Falco, and you: A technical discussion article.
• Jessie's Setting the Record Straight: containers vs. Zones vs. Jails vs. VMs article.
• Jessie's Security in a containerized world presentation.
• Microsoft's Threat matrix for Kubernetes article.

Running product security

Julian Cohen and Michal Zalewski share their opinions on building a product security program. I find them incredibly on-point:

• Getting product security engineering right
• A Product Security Framework

And here's another page that ties up maturity and DevSecOps and looks interesting:

• Lean security

Happy reading!

Thank you to my colleague Luis for sharing these.

Tooling: Testing IaC for security flaws

TL;DR

I made a Github Action that enables you to easily scan infrastructure code for security mistakes. Grab it on Github's Marketplace!

Overview

So, static code analysis for infrastructure code is hot! A few tools have appeared recently, and Checkov looks pretty good.

I tested it locally (as a command line tool on my laptop) against my aws-student-lab project. This terraform code just sets up a simple student lab on AWS, and I like to use it for testing new tools, since it's both simple and realistic. Checkov found no problems, and showed a nice green "PASSED":

The next step after local analysis, of course, is continuous integration, so I used Github Actions to run Checkov each time there's a commit. This involved writing a small yaml snippet.


To avoid having to do this setup on each repository, I decided to make a new Github Action and publish it on the Github Marketplace. This way, other people can easily integrate Checkov in their CI with minimal configuration!

Deep-dive test-drive

To test out Checkov and my new Github Action, I added the definition for an S3 bucket in my terraform code and gradually removed security features, to see if Checkov complains.

Starting with a nice secure bucket:

This bucket is pretty ok: it has encryption, versioning, logging and MFA confirmation for deletions.

As expected, Checkov checks everything and is happy, so the build passes:

Then, I decided to remove most of the nice features and options. Checkov breaks the build and complains:


The output is very helpful in determining how to fix this:

• Ensure all data stored in the S3 bucket is securely encrypted at rest
• Ensure the S3 bucket has access logging enabled
• Ensure all data stored in the S3 bucket have versioning enabled
• Ensure S3 bucket has MFA delete enabled

Nice! Working backwards, someone who sees these errors can look up cloud provider (AWS in this case) and terraform documentation and enable the missing features, reaching a more secure configuration.

Overall I'm happy and will be using this on all my future cloud code.

Pull requests are welcome!

Asynchronous communication

For years now I've lived with email notifications turned off. Both at work and home accounts. It's never caused a problem, since people know how to reach me for emergencies, and I believe it has helped me be calmer and more productive.

Doist explains why asynchronous communication leads to increased productivity.
The article is great, and here are some highlights:

Real-time communication comes with a few downsides:

• Leads to constant interruptions,
• prioritizes being connected over being productive,
• creates unnecessary stress,
• leads to lower quality discussions and suboptimal solutions.

Having a more asynchronous way of working is better because of:

• Control over the workday = happier and more productive employees,
• high-quality communication versus knee-jerk responses,
• better planning leads to less stress,
• deep work becomes the default,
• automatic documentation and greater transparency,
• time zone equality.

And here's how to get there:

• Plan ahead to give people time to consider your message,
• after meetings, document discussions, and outcomes,
• turn off notifications,
• evaluate people based on their output and results, not how responsive they are or the number of hours they work,
• emphasize trust, organization, independence, and accountability,
• adopt a Direct Responsible Individual (DRI) model for management and decision-making,
• make transparency a priority,
• use tools that promote transparency, deep work, and async communication.

Meta: Managing engineers

Dear engineering managers, here’s an excellent 17' talk of a Github manager on “How to grow emotionally intelligent engineering teams”.
It’s really to the point imho. Highly recommended to watch!

Practical AWS security setup

2021 Update: Since I wrote this article in 2019, I've found this PDF guide on the same topic. It is much more elaborate and complete than my own notes. I highly recommend going through it :)

AWS security on the cheap

So, you're on a budget (say, you are voluntarily building a workshop for students in Ghana) and you want a secure AWS environment to allow people to learn on.

How do you setup and secure the account?
You use infrastructure-as-code and a few free tools. I'll discuss the setup and give code in my next blog post.

In this post I'll show something about two of the tools:
How does AWS's Trusted Advisor (free version) compare to NCC group's ScoutSuite?

Well, on a relatively simple AWS account, Trusted Advisor finds no issues:

But ScoutSuite has findings: 

Many of these findings are worth looking into and getting fixed. The rest can be marked as false positives, so they don't show up in future scans.

Please note that getting a paid AWS support plan would enable extra Trusted Advisor features that might produce similar results. But I like to be able to do it for free :D.