Forem: Madhu Akula

DEF CON Training — A Practical Approach to Breaking & Pwning Kubernetes Clusters

Madhu Akula — Tue, 19 Jul 2022 22:24:56 +0000

DEF CON Training — A Practical Approach to Breaking & Pwning Kubernetes Clusters

Popular Kubernetes Security Hacking @ DEF CON Trainings

https://defcontrainings.myshopify.com/products/madhu-akula-a-practical-approach-to-breaking-pwning-kubernetes-clusters

Woah! It’s amazing to see DEF CON 30 has started the training officially 🙌

I’ve been presenting and sharing my research at DEF CON since 2016 via workshops, talks, etc among other conferences around the globe. But this time I’m super excited to teach my popular training at the global hacker's stage on “A Practical Approach to Breaking & Pwning Kubernetes Clusters”.

If you are interested in learning something from some of my previous research, trainings, workshops and knowledge. Here are some of my content and give aways!

Introduction to DEF CON and Training

DEF CON (also written as DEFCON , Defcon, or DC ) is one of the world’s largest and most notable hacker conventions, held annually in Las Vegas, Nevada. The attendees include computer security professionals, journalists, lawyers, federal government employees, security researchers, students, and hackers with a general interest in software, computer architecture, hardware modification, conference badges, and anything else that can be “hacked”.

— https://en.wikipedia.org/wiki/DEF_CON

DEF CON has been the world’s most influential hacker con for thirty years. This year DEF CON running intensive, two-day courses of study with world-class instructors aimed at building specific skills in a challenging, fast-paced environment. In some cases, these courses will carry a certification.

Why should I join A Practical Approach to Breaking & Pwning Kubernetes Clusters Training?

Yes, that’s a great question 😊

Here are 3 reasons among many others hundreds 😅

👉 Why Kubernetes security?

Containers, Kubernetes is used everywhere, and understanding its security is paramount to break & hack or protect & defend against security attacks and vulnerabilities in the ever-growing and adapting ecosystem

👉 Then why me?

I have been working on containers and Kubernetes since 2016, as I’ve previously mentioned did a ton of research and shared it with the community and conferences like Blackhat, DEFCON, USENIX, SANS, OWASP, etc. among many others. Apart from that, I’ve also created a practical interactive community learning playground to teach about Kubernetes Security using “Kubernetes Goat”. Which helped thousands of folks around the globe to learn and understand real-world attacks and security misconfigurations.

👉 It looks like you already sold me? Anything else?

Yes, here are some more things I believe why it helps you 😊

This course is built from years of experience and real-world knowledge put as simulated scenarios of testing hundreds of clusters. Also built by the author of Kubernetes Goat and Hacker container
It has a complete hands-on approach, from beyond basic attacks to privilege escalation, exploitation, lateral movement, persistence, defense evasion, and many other techniques
To gain the confidence to perform pen-testing, red teaming, and security architecture reviews of Kubernetes Clusters and Containerised environments

What I will get out of the Training?

Real-World practical knowledge of effectively performing Pentesting/RedTeam/Security reviews of Kubernetes and Containersed environments
Going beyond basics, showcasing attack trees, and chaining vulnerabilities to cover the possible security risks like privilege escalation, exploitation, lateral movement, persistence, defense evasion, and many other techniques
Complete Digital Guide book, cheat sheets, many other resources, and references to further your learning

A little glimpse of the Training

Some of the fantastic hacking, breaking, and Pwning of clusters, nodes, containers, and cloud environments!

Okay, I’m super excited now. How can I sign up?

Here is the official DEF CON 30 training registration link, make sure you register before the training sold out 😉

https://defcontrainings.myshopify.com/products/madhu-akula-a-practical-approach-to-breaking-pwning-kubernetes-clusters

Anything I should be prepared before coming?

Laptop with a modern browser, and wireless internet connectivity. For the training purpose, you will get your Kubernetes cluster with all the setup included so we can purely focus on training to learn and hack!
Here are some skills which might be helpful to accelerate the training

👉 Able to use Linux CLI

👉 Basic understanding of system administration

👉 Experience with Docker and Containers ecosystem would be useful

👉 Security Experience would be plus

Thank you so much for reading this article, super excited and looking forward to seeing you at DEF CON 30 👋

A Practical Approach to Breaking & Pwning Kubernetes Clusters

Madhu Akula — Mon, 10 May 2021 22:24:20 +0000

https://rebrand.ly/bhusa21

Join me at Black Hat USA 2021 hands-on training!

Super excited to run a complete attacker and offensive-focused Kubernetes Security training at Black Hat USA 2021 (online — virtual). It’s such a privilege and honor to train and present at Black Hat as always. After training multiple batches with sold-out trainings at Black Hat physically(before corona situations), this year I will be running a virtual online training on “A Practical Approach to Breaking & Pwning Kubernetes Clusters” with 2 batches.

You can register for this training before it gets soldout at https://rebrand.ly/bhusa21 and there is an early-bird discount as well :)

Why this training, why blackhat, and why Madhu Akula?

The adoption of Kubernetes use in production has increased to 83% from a survey by CNCF. Still, most of the security teams struggle to understand these modern technologies.

Some of the high-level things you will be doing in this course:

Exploiting Misconfigruations, Private Registries by performing simple Recon
Escaping out of containers to host systems & cluster to gain more access
Escalating privileges, DoS cluster resources, Lateral movement from container
Gaining unauthorized access to namespaces, microservices, data, and logs
Breaking the boundaries of NSP(Network Security Policy), RBAC, PSP(Pod Security Policy)
Defense evasion techniques & Persistance in Cluster environments
Evaluating the cluster security using CIS benchmarks and Cluster Audits to find all possible risks

Black Hat is an internationally recognized premier cybersecurity event, highly technical that bring together thought leaders from all facets of the infosec world. Black Hat training sessions are provided by some of the most respected experts in the world and many also provide formal certifications to qualifying attendees. Read more about Black Hat here.

Madhu Akula has been working on Containers and Kubernetes since 2016. Created Kubernetes Goat, an intentionally vulnerable by design Kubernetes Cluster to learn and practice Kubernetes Security from years of experience from testing, reviewing, architecting, building, and researching Containers, Kubernetes, and Cloud Native Infrastructure environments. Read more about Madhu Akula and his work https://madhuakula.com

What you will be learning in this training?

This training is focused on the offensive and attacker point of view of Kubernetes Security. In this real-world scenario-based training, each participant will be learning Tactics, Techniques, and Procedures (TTP) to attack and assess Kubernetes clusters environments at different layers like Supply chain, Infrastructure, Runtime, and many others. Starting from simple recon to gaining access to microservices, sensitive data, escaping containers, escalating to clusters privileges, and even its underlying cloud environments.

Section-1

Kubernetes 101 — Fasttrack Edition
Security Architecture Review & Attack Trees using MITRE ATT&CK framework
kubectl kung-fu to explore the cluster
Attacking the supply chain by exploiting private registry
Pwning the container images and gaining access to the cluster
Exploiting security misconfigurations in the cluster

Section-2

Escaping out of the container to the host system to gain more privileges
Bypassing NSP and gaining unauthorized access to other microservices
Lateral movement from container to node and then complete cluster access
Escalating from ServiceAccount to more RBAC privileges (No least privileges)
Helm with Tiller service = ClusterPwn (Complete cluster takeover)
Gaining access to k8s volumes, logs of the services, and sensitive data
From application vulnerability to cloud provider access (attack chain)

Section-3

Hacker Container — The Swiss Army knife for hacking Kubernetes Clusters
Exploiting Kubernetes Secrets and gaining access to third-party services
DoS the services and cluster nodes by resources exemption
Understanding Admission controller and possible attack surface around Webhooks
Persisting in the clusters using Sidecar/Cronjob/DaemonSets
Defense evasion techniques for Kubernetes Cluster environments
Some useful hacks around kubectl(cheatsheet will be provided)

Section-4

Tools, techniques for beyond manual exploitation and analysis
KubeAudit, KubeSec, k9s, trivy, dockle, rakkess, linters, and many others…
Performing Docker & K8S CIS benchmarks to find all the possible security risks
Auditing the cluster security posture from Code to Production running cluster
Real-World case studies of Kubernetes Hacking, Vulnerabilities and Exploits
Best practices, Recommendations based on the Security Maturity
Resources & references to further your attacks, exploitation, more learning

Finally, lot of experience and knowledge from the trainer to ask curious questions and learn more about best practices, architecture reviews, advice, strategy, and some hacking stories.

Why you should attend this training, what you will get?

By end of the training, participants will be able to apply their knowledge to perform architecture reviews, security assessments, red team exercises, and pen-testing engagements on Kubernetes Clusters and Containersed environments successfully. Also, the trainer will provide step by step guide(Digital Book) with resources and references to further your learning.

Key takeaways and Giveaways

Real-World practical knowledge of effectively performing Pentests/RedTeam/SecurityReviews of Kubernetes and Containersed environments
Going beyond basics, showcasing attack trees, and chaining vulnerabilities to cover all the possible security risks like privilege escalation, exploitation, lateral movement, persistence, defense evasion, many other techniques
Complete Digital Guide book, labs, other resources to further your learning
Private Slack Channel for next 30 days for any questions & discussions

Who should attend and what to bring?

One of the coolest things I have been doing since my first Black Hat training is running the entire training smoothly on browser-based labs. This means the attendee or participant just needs to bring their laptop with internet and browser and the trainer will be providing a dedicated custom-built Kubernetes Cluster for everyone.

Some of the skill requirements include

Able to use Linux CLI
Basic understanding of system administration
Experience with Docker and Containers ecosystem would be useful
Security Experience would be plus

I work in DevOps/SRE team, can I join this training?

Yes, absolutely you can join this training. This training very much helps anyone interested in learning more about attacks and the offensive side of the Kubernetes and containerized environments. While doing the training defenders/blue teams get a detailed picture of what things can go wrong and how we can secure Kubernetes Clusters and Cloud Native environments.

Pen Testers, Red Team, and Security Engineers
DevOps, Defenders, Blue teams, Cloud and SRE teams to see the attackers side
Security and Solutions Architects, Kubernetes Administrators
Anyone interested in learning more about attacks and the offensive side of Kubernetes and Containersed environments security

Some glimpse of this training includes

Some of the glimpse for the Kubernetes Security training

Feedback & Review from previous attendees

As I have been doing training, talks, and sessions around the globe for years. I had produced quite a lot of training and sessions around Kubernetes, Containers, and Cloud Native Security. So below are some of the feedback, review from the attendees and events recently.

Attendees Training Reviews: Hacking & Securing Kubernetes Clusters

Nullcon Virtual Online Training Feedback Tweets

NULLCON

@nullcon

😎We had an amazing 4 Days with @madhuakula for his Training

⚡Hacking and Securing Kubernetes Clusters & Students loved the Training session

🙌Sharing with you the Upskilled Batch from Nullcon March Trainings 2021

#Kubernetes #Hacking #Cybersecurity #Nullcon2021

11:40 AM - 11 Mar 2021

This is awesome, I wanted to join the training. What should I do?

You can register for this training before it gets sold out at https://rebrand.ly/bhusa21 and there is an early-bird discount as well :)

Registration Link: https://rebrand.ly/bhusa21

Looking forward to seeing you in the Black Hat training!

A practical guide to writing secure Dockerfiles

Madhu Akula — Mon, 19 Apr 2021 12:32:01 +0000

Photo by Ishant Mishra on Unsplash

Tools, techniques, and procedures to write secure Dockerfiles

Docker is a familiar name by now. It has been instrumental in streamlining and improving the workflows of developers, operations, and other engineering teams. In this article, we are going to learn best practices to write Dockerfiles using BuildKit features, linters, and other tools. We’ll also touch on leveraging OPA (Open Policy Agent) to write custom policies.

TL;DR: this article is based on A practical guide to writing secure Dockerfiles, a presentation that took place at the recent Container Day conference. The talk is available online as a video recording.

What is Dockerfile?

Before learning about Dockerfiles — what is Docker?

Docker is an open-source platform for building, deploying, and managing containerized applications. It has become the de facto standard to build and share apps, from desktop to cloud, including edge devices like Raspberry Pi.

One of the features that have made Docker so popular among developers is the ability to easily pack, ship, and run applications as lightweight, portable, and self-sufficient containers that can run virtually anywhere.

The instructions to build a Docker container image are stored in files called Dockerfile. This is an example of a typical Dockerfile :

Dockerfile example from https://github.com/dockersamples/example-voting-app/blob/master/vote/Dockerfile

A Dockerfile is a text document that contains all the commands a user can call on the command line to assemble an image.

Why Dockerfile security?

If you perform a quick search for Dockerfiles in GitHub, you can see that it returns more than 3 million files.

https://github.com/search?l=&q=filename:Dockerfile&type=code

Dockerfiles are a blueprint for building your Docker container images
Dockerfiles are a codified version of your application and infrastructure
Dockerfiles are among the key components in the entire supply chain security
Dockerfiles need to be part of your security posture to maintain the highest level of security comprehensively
Insecure Dockerfiles can cause serious security issues

Best practices to write Dockerfiles

Here is a collection of standard best practices that Docker recommend in their Documentation, as well as community-driven best practices:

Start with a small version of the image
Create ephemeral containers
Understand the build context
Exclude files from the image with .dockerignore — it works similarly to .gitignore in Git
Use multi-stage builds to reduce the image size and its attack surface
Create multi-line arguments in a structured way, and reduce the image layers
Minimize the number of layers
Leverage the build cache
Create your own base image like a golden image

The Docker community recommends a number of other best practices when creating Dockerfiles . For example:

Order the steps in the Dockerfile from least to most frequently changing content
Use the COPY instruction to copy only the necessary files. Avoid executing instructions such as COPY . .
Only install what you need. For example, use the --no-install-recommendsoption
Group similar commands. For example: RUN apt-get update && apt-get install -y curl
Remove the package manager cache: rm -rf /var/lib/apt/lists/*
Use a specific image tag; avoid the latest tag
Set non-root user and group
Disallow acquiring new privileges
Use only trusted and official base images
Don’t store secrets or sensitive information in Dockerfiles
Don’t install SSH or similar services that may expose your containers
Apply image lifecycle management updates, if required

So far we explored a number of standard best practices to follow. Now let’s see how we can apply them in practice in our DevOps workflow

Linters, tools, techniques to validate

We can automate these tasks and checks to enforce them in our workflow, and to ensure the highest level of security.

Let’s start with securing the place where we build the Dockerfiles to create Docker container images.

Say hello to BuildKit

BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive, and repeatable manner.

Available from Docker 20.10
Enabled by default in the latest release (export DOCKER_BUILDKIT=1)
It significantly improves performance and security

A couple of cool features in BuildKit are its support for securely passing secrets, and forwarding the SSH authentication agent from the host to the Docker build.

BuildKit — Secrets usage in the build (security use case)

Sometimes, developers and organizations use insecure ways to pass secrets and sensitive information to the Dockerfile during build time. For example, they hardcode the data in the Dockerfile, or they pass it via build arguments.

An insecure way to pass sensitive data and secret keys to the Dockerfile during build time

Both examples are flawed: if you hardcode AWS secrets in the Dockerfile, any user or attacker with access to the file has access to the AWS environment. Similarly, if we pass the secrets as build arguments, they are available in the Docker build history, which is easy to obtain and to look up to gain access to the AWS environment.

BuildKit offers a best practice approach to pass secrets to the Dockerfile.

A secure way to pass sensitive data and secret keys to the Dockerfile during build time is by using BuildKit

In the example above we pass the AWS secrets via the mount option from the host system. In this way, the secrets are available only during build time; they aren’t stored in the Docker build history or in the Dockerfile.

BuildKit — SSH Socket (security use case)

Organizations hosting their code on private version control systems and running Docker builds in CI/CD pipelines may sometimes use workarounds to pass the SSH authentication credentials to have SSH access to the container build. In the example below, the SSH key is copied to the Dockerfile in an insecure manner.

An insecure way to pass SSH keys to the Dockerfile

BuildKit enables passing the SSH socket by mounting it. This forwards the SSH agent from the host in a secure manner.

A secure way to pass SSH access by forwarding the agent to Docker using BuildKit

Learn more about Docker BuildKit on Build images with BuildKit.

hadolint — Haskell Dockerfile Linter

A smarter Dockerfile linter that helps you build best practice Docker images. The linter parses the Dockerfile to an AST, and then it runs rules on top of it.

hadolint is inspired by ShellCheck, which lints Bash code inside RUN instructions.

hadolint online — https://hadolint.github.io/hadolint/

hadolint is available also online at https://hadolint.github.io/hadolint. However, it is valuable to add these linters and checks to our CI/CD pipelines as part of the deployment workflow.

hadolint linter checks against Dockerfile

dockle — Container Image Linter for Security

Container Image Linter for Security. It helps build best practice Docker images. To learn more about dockle, check the GitHub repo: https://github.com/goodwithtech/dockle

dockle performs multiple CIS benchmark checks, as well as more generic checks that are considered recommended best practices, and which we mentioned in the lists at the beginning of the article.

CIS Benchmarks security checks comparison

https://github.com/goodwithtech/dockle#checkpoints-comparison

Generic Checks for Dockerfiles

https://github.com/goodwithtech/dockle#checkpoints-comparison

docker-slim — Minify and Secure Docker Containers

DockerSlim is a project to minify and secure Docker containers. The process doesn’t change anything in your Docker container image; but it minifies it by up to 30x, making it secure too! DockerSlim can do more, besides optimizing images: also help you understand and author better container images. Find out more about the project on https://dockersl.im/.

Example from the DockerSlim project — https://dockersl.im/

DockerSlim — Security Profiles

DockerSlim collects application information to optimize containers for security. It also generates Seccomp and AppArmor (potentially SELinux as well) profiles.

Generating the Seccomp profiles may not work for some use cases

Run the DockerSlim

docker-slim build your-name/your-app

Use the generated Seccomp profile

docker run — security-opt seccomp:<docker-slim directory>/.images/<YOUR_APP_IMAGE_ID>/artifacts/your-name-your-app-seccomp.jso n <your other run params> your-name/your-app

dive — Explore each layer in a Docker image

dive enables exploring a Docker image, layer contents, and discovering ways to shrink the size of your Docker/OCI image. Find out more about the project on https://github.com/wagoodman/dive.

Dive offers a rich exploratory feature set. For example, it can:

Show broken Docker image contents by layer
Indicate what’s changed in each layer
Estimate image efficiency
Execute quick build/analysis cycles
Be included in CI integration

dive tool analysis in action

IDE linters and plugins

We write our Dockerfiles in our IDEs; this is a good opportunity to mention some IDE linters and plugins that help us enforce best practices and identify potential security issues in the early stages of our SDLC lifecycle.

For example, this is a Docker linter plugin for Microsoft Visual Studio Code. It enables running linters in Docker containers.

Source: https://marketplace.visualstudio.com/items?itemName=henriiik.docker-linter

Introducing Open Policy Agent (OPA)

Open Policy Agent (OPA) is an open-source, general-purpose policy engine that unifies policy enforcement across the stack. It is a policy-based control for cloud native environments providing flexible, fine-grained control for administrators. It features a high-level declarative language that lets administrators specify policy as code and simple APIs to offload policy decision-making from their software. Find out more about the project on https://www.openpolicyagent.org.

Rego — OPA policy language

OPA policies are expressed in a high-level declarative language called Rego. Rego (pronounced “ray-go”) is purpose-built for expressing policies over complex hierarchical data structures
Rego was inspired by Datalog, which is a well-understood, decades-old query language. Rego extends Datalog to support structured document data models such as JSON
Rego queries are assertions on data stored in OPA. The queries can be used to define policies that enumerate instances of data that violate the expected state of the system

This is an example of a Rego policy from the Rego Playground for the Role-Based Access Control (RBAC) use case scenario.

Rego Playground — https://play.openpolicyagent.org/

Conftest — Tests against structured configuration data

Conftest is a utility to help you write tests against structured configuration data. For example, you can use Conftest to validate Kubernetes configurations, Terraform code, Serverless configurations, or any other structured data. In this context, Conftest helps write validation policies for Dockerfiles.

Conftest relies on the Rego language from Open Policy Agent to write the assertions.

Conftest supports multiple formats of input types, such as:

YAML
JSON
INI
TOML
HOCON
HCL
HCL 2
CUE
Dockerfile
EDN
VCL
XML
Jsonnet

The sample policy below checks the Kubernetes YAML manifests to verify if the security context of the container is running as root or not, and if it has an app label.

Sample policy from conftest for Kubernetes YAML: https://www.conftest.dev/#usage

Execution of conftest tests against the deployment YAML file: https://www.conftest.dev/#usage

To learn more about leveraging the power of OPA and Conftest, check the Conftest project on https://www.conftest.dev.

Dockerfile security checks using OPA Conftest Rego policies

Let’s take an intentionally insecure Dockerfile example that doesn’t comply with security best practices and standards.

FROM ubuntu:latest
LABEL MAINTAINER "Madhu Akula"

ENV SECRET AKIGG23244GN2344GHG
ENV GITLAB_API_ID gig32oig3bgi34gb43gb43uigb43i 

WORKDIR /app

ADD app /app
COPY README.md /app/README.md
ADD code /tmp/code
RUN sudo apt-get udpate

RUN apt-get update && apt-get install -y htop

CMD ["/bin/bash", "/app/entrypoint.sh"]

The snippet is part of the docker-security-checker tool, based on OPA and Conftest. Find out more about the project on https://github.com/madhuakula/docker-security-checker.

Sample Rego policy to check ADD vs COPY

The example below checks if a Dockerfile contains occurrences of the ADD command. If it finds occurrences of ADD, it throws an error, and it notifies users about replacing ADD with COPY.

warn[msg] {
  input[i].Cmd == "add"
  val := concat(" ", input[i].Value)
  msg = sprintf("Use COPY instead of ADD: %s", [val])
}

Running docker-security-checker against Dockerfiles

In the example below, we run a set of custom security OPA Rego policies with Conftest on Dockerfiles to validate best practices and to perform security checks.

docker-security-checker in action https://github.com/madhuakula/docker-security-checker

Why custom policies?

Most organizations have common patterns across their workflows. Some policies can be specific to the organization. For example, the policy below allows only base images from a predefined trusted source ( exampletrustedregistry.com ).

deny[msg] {
  input[i].Cmd == "from"
  image := input[i].Value
  not startswith(image, "exampletrustedregistry.com/")
  msg := sprintf("Base image '%v' is used from untrusted registry", [image])
}

Simple and powerful policies like this help prevent using untrusted images, and they enforce only images from internal private registries.

Want to try it yourself?

I created a simple Katacoda online interactive playground where you can play with the docker-security-checker, OPA policies, and Conftest.

https://katacoda.com/madhuakula/scenarios/docker-security-checker

What should I do next?

Try following best practices when writing Dockerfiles; use linters
Include these checks in your GitOps workflow, and in your usage of Git hooks
Create and standardize organization-wide custom policies to make your workflow consistent and predictable
Add these checks to your CI/CD pipelines to enable and to validate security best practices
Extend these practices besides Dockerfiles, and implement them in each workflow layer https://medium.com/media/e52b9f88224437d919138d1d160ae4fb/href ### Resources and references

The list below includes a selection of resources and reference I used to create, follow, and learn more about Dockerfile security, as well as the ecosystem around it:

Thank you so much, Marco Spinello and Ivan Remizov for the review :)

Seems cool, exciting, and fun stuff? Then Join our team at Miro!

Do you like building things and working at scale while we are in hypergrowth? Would you like to be an Engineer, Team Lead, or Engineering Manager at Miro? Check out opportunities to join the Engineering team.

Introducing Kubernetes Goat

Madhu Akula — Thu, 25 Jun 2020 17:20:31 +0000

https://madhuakula.com/kubernetes-goat

Intentionally vulnerable cluster environment to learn and practice Kubernetes security.

I have been working in Containers, Kubernetes and it’s security for quite sometime. I felt that there is a gap between the security and technology understanding of the Kubernetes it self. We all learnt using different goats in security world like WebGoat. I wanted to create some simple environment where anyone can practice and learn to get started in Kubernetes Security.

That’s how it all started with Kubernetes Goat. But it has lot of extensive documented scenarios which are taken from real-world attacks, vulnerabilities and misconfigurations.

Kubernetes Goat Home

Okay, where can I get more info about Kubernetes Goat?

You can learn more about Kubernetes Goat and its active development, scenarios and the documentation at Github.

madhuakula/kubernetes-goat

https://github.com/madhuakula/kubernetes-goat

What all scenarios Kubernetes Goat has?

I had covered almost 14 different scenarios in Kubernetes Goat currently, also adding more scenarios and features soon. List of scenarios currently available in Kubernetes Goat are as follows

Sensitive keys in code bases
DIND(docker-in-docker) exploitation
SSRF in K8S world
Container escape to access host system
Docker CIS Benchmarks analysis
Kubernetes CIS Benchmarks analysis
Attacking private registry
NodePort exposed services
Helm v2 tiller to PwN the cluster
Analysing crypto miner container
Kubernetes Namespaces bypass
Gaining environment information
DoS the memory/cpu resources
Hacker Container preview

I’m excited, how can I quickly get started using/learning more about Kubernetes Goat?

As it’s a complicated to setup the entire cluster environment and trying these scenarios, I have created free online playground at Katacoda to just tryout from your browser. You can just get started playing with Kubernetes Goat by clicking below link

Kubernetes Goat | madhuakula | Katacoda

https://katacoda.com/madhuakula/scenarios/kubernetes-goat

I am stuck at a scenario while playing, where can I get solutions?

Yes, indeed the Kubernetes Goat is intended to help you teach and learn as a walkthrough and the detailed step by step Guide can be found at https://madhuakula.com/kubernetes-goat

https://madhuakula.com/kubernetes-goat

Can we try this in our production cluster?

No, please don’t do that. It’s intentionally designed to be vulnerable cluster to showcase different vulnerabilities, misconfigurations in Kubernetes environments. Also read the below disclaimers.

Kubernetes Goat creates intentionally vulnerable resources into your cluster. DO NOT deploy Kubernetes Goat in a production environment or alongside any sensitive cluster resources.

Kubernetes Goat comes with absolutely no warranties whatsoever. By using Kubernetes Goat, you take full responsibility for any and all outcomes that result.

Wow, this looks amazing! how can I can i get to know more about its upcoming features/scenarios?

As I said, the project is in active development to include new features and scenarios. So, to just name some of the upcoming features/scenarios coming in Kubernetes Goat includes:

More offensive or attacker scenarios to learn about Kubernetes security from an attackers perspective
Defender scenarios to secure/mitigate these misconfigurations and vulnerabilities
Also, working on KIND based deployments to showcase cluster it self vulnerabilities and weaknesses
Detailed references and resources for attacks/vulnerabilities which are unable to reproduce with newer version of clusters
Many more…

So stay tuned for the more updates in below channels

⭐️ Star the Github repo to show some love❤️https://github.com/madhuakula/kubernetes-goat

Follow me in twitter @madhuakula for more updates/tweets about Kubernetes Goat as well as information more about security around Cloud, Containers, Kubernetes.

Hacker Container for Kubernetes Security Assessments

Madhu Akula — Sat, 06 Jun 2020 21:42:54 +0000

https://worditout.com/word-cloud/4251548/private/752ede061babc4da45ef0d8ea0599924

Your go to container for hacking Kubernetes Clusters

Hacker Container is a simple alpine based docker container with commonly used tools and utilities while performing security assessments for containerised and Kuberentes cluster environments.

The repository and project information can be found here https://github.com/madhuakula/hacker-container

madhuakula/hacker-container

Why Hacker Container?

While performing and testing container or Kubernetes infrastructure, I always have to install some common tools inside a container to perform further exploitation and later movement with in the cluster.

To give an example, I have found redis service within the cluster without any authentication and network security policies. So I had to install and setup redis-cli to communicate and see what more data I can get from the server.

In another case, I wanted to understand what all privileges and capabilities I had for the container. So I end up running amicontained or capsh --print

Hacker Container in Action running amicontained

Some use cases why we need all tools in one container?

Having multiple tools and processes running in a single container is not a good approach in real-world. This container is not for running production workloads or real-world applications.

Consider that we want to perform a white box security assessment of Kubernetes cluster, and we got one pod access with limited privileges in the cluster. In this scenario we can use this container as an attacker, with all the utilities to perform assessment and understand cluster environment. Similarly in black box assessments as well, it helps you with all the utilities in a single place to perform further exploitation
Also, there could be an usecase where your cluster doesn’t have internet access and wanted to perform specific assessment. You end up downloading required tools and build it from scratch with all the requirements. Hence using this container helps you to gain more time in identifying and exploiting vulnerabilities in the infrastructure instead of investing time in setup

What tools are available in this container

There are almost nearly 50 commonly used tools and utilities for hackers, security researchers and penetration testers. The detailed list of tools can be found at https://github.com/madhuakula/hacker-container/blob/master/list.todo

The idea behind these tools is not to add all of them and making a big fat container. But just adding useful utilities or commonly highly required tools while performing containerised security assessments.

How to use Hacker Container?

The simplest way to get started with Hacker container is trying out the container in Play With Docker

Just run the following command to explore in the docker container environments

docker run --rm -it madhuakula/hacker-container

To deploy as a Pod in Kubernetes cluster run the following command

kubectl run -it hacker-container --image=madhuakula/hacker-container

This container can be used in different ways in different environments, it aids your penetration testing or security assessments of container and Kubernetes cluster environments.

Hope this helpful for fellow researchers, security engineers/testers and I would love to hear your feedback/suggestions. Feel free to tweet to me @madhuakula or create an issue at Github

Thanks for reading this article. If you enjoyed it please let me know by clicking that clap below :)

How does the pen testing world do penetration testing : Part-2

Madhu Akula — Sat, 30 May 2020 17:31:42 +0000

Penetration Testing World — Part 2

How does the pen testing world do penetration testing : Part-2

Hello Folks,

This article is part of the series called How does the pen testing world do penetration testing. If you haven’t read the Part-1 please check the below link.

How does the pen testing world do penetration testing : Part-1

Different standard organisations activities to perform penetration testing

There are different suggested methodologies for penetration testing, some of the main ones are

PTES Methodology
OWASP Methodology
OSSTMM Methodology
ISSAF Methodology

PTES Methodology

PTES is a newer standard designed to provide both businesses and security service providers with a common language and scope for performing penetration. The industry has used the term Penetration Test in a variety of ways in the past. This has driven a large amount of confusion to what a Penetration Test is or isn’t. PTES’s aim is to create a clear standard to measure Penetration Testing and provide customers/consultants a guideline to how testing needs to be conducted.

OWASP Methodology

The goal of this project is to collect all the possible testing techniques, explain these techniques, and keep the guide updated. The OWASP Web Application Security Testing method is based on the black box approach where the tester knows nothing or has very little information about the application to be tested.

OSSTMM Methodology

OSSTMM is a methodology to test the operational security of physical locations, workflow, human security testing, physical security testing, wireless security testing, telecommunication security testing, data networks security testing and compliance. OSSTMM can be supporting reference of IOS 27001 instead of a hands-on penetration testing guide.

ISSAF Methodology

The methodology defined by ISSAF covers all the aspects related to security assessments: from a high-level perspective (e.g. business impact and organisational models) to practical techniques (e.g. security testing of passwords, systems, network, etc.). The framework is divided in four main phases structured in several working packages (named “activities”). The four phases are respectively: Planning, Assessment, Treatment, and Accreditation.

PTES, OWASP, OSSTMM, ISSAF activities of doing penetration testing

What are software and network requirements for doing penetration testing?

There are multiple resources required while conducting a penetration testing engagement. These include software resources such as tools, scripts, network requirements like the IP network range through you are going to test and collaboration tools to make the team effective when more than one person is conducting penetration testing. The most important thing is documentation and reporting, this is the result or output of the entire penetration testing process which includes the way you approached it, the methodologies used and the tools and techniques you used. This will help both technical and non-technical users to understand what has been done.

Tools to perform penetration testing

There are multiple frameworks and tools out there to do penetration testing. Which ones are used will depend on the which application or infrastructure is being tested. For example, if you are testing IoT devices then you might need a different toolset to testing a server environment. Penetration testers often use a pre-complied set of tools known as a ‘distro’ (distribution in an operating system which helps them to do things more quickly. One of the more popular distros was created by Offensive Security called “ Kali Linux ” (and formerly called as “Back Track”).

The Kali Linux distro for penetration testing includes tools for

Information Gathering
Vulnerability Analysis
Exploitation Tools
Wireless Attacks
Forensics Tools
Web Applications
Stress Testing
Sniffing & Spoofing
Password Attacks
Maintaining Access
Hardware Hacking
Reverse Engineering
Reporting Tools

More details about the tool-set can be found at http://tools.kali.org/tools-listing

Some of the network requirements while performing penetration testing in terms of organisational and pen tester perspective are key part.

Penetration testing may also need to be carried out internally or externally; internal penetration test is like having a malicious intruder inside the network and trying to get into the system by exploiting.

While conducting penetration testing it’s also important that you are aware about the boundaries and critical systems.

Another good practice is to test from specific IP’s to help organisations make sure that pen testers are performing the attack and not real attackers.

Overview of penetration testing

Considerations

Before starting a penetration testing engagement it’s good to consider a few things

The one of the main things to agree is the scope of the penetration tests which helps both the organisation and individual to decide what to test and what not to test. Scopes may vary differently for each engagement. For example, some organisations will want to do complete exploitation of their systems but they won’t want to include social engineering attacks. It’s also possible that in some cases they may want to do only external penetration testing which means only conducting tests on public facing environments like websites and external infrastructure.

It is very important to select a proper organisation or well experienced penetration tester, so they have the skills and experience to properly understand the system before doing penetration testing; in some cases there might be critical infrastructure (or) legacy systems you have to test and the amount of scanning should not be aggressive while doing that.

Conclusion

These methodologies and techniques are helpful from both individual and the organisational perspective. Penetration testing simulates attacks like a real world hacker test security controls. By conducting penetration testing it helps an organisation to create a baseline for security and compliance for their infrastructure and to understand existing vulnerabilities.

The sample penetration test report below is one produced by the Offensive Security team.

https://medium.com/media/db36b3d0b02431fa87f025be6528c078/href

References

Thanks for reading this article. If you enjoyed it please let us know by clapping to reach more audience.

Dockerfile Security Checks using OPA Rego Policies with Conftest

Madhu Akula — Sat, 16 May 2020 09:52:22 +0000

Photo by Glenn Carstens-Peters on Unsplash

Docker is everywhere! In modern day to day development and operations, we use Docker images and containers to run our applications ranging from developer laptop, raspberry pi, staging servers to including production environments.

As we use modern technologies and tools, we tend to forget securing them while building and serving customers. That is why we can write and codify our security into policies and validate them against the Dockerfiles (Infrastructure as a Code) to identify the potential security risks before deploying them into production.

What is Conftest?

Conftest is a utility to help you write tests against structured configuration data. For instance you could write tests for your Kubernetes configurations, Terraform code, Serverless configs or any other structured data. In our context, we will use it to write validation policies for deprecated Kubernetes API versions.

Conftest relies on the Rego language from Open Policy Agent for writing the assertions. You can read more about Rego in How do I write policies in the Open Policy Agent documentation.

What is OPA (Open Policy Agent)?

The Open Policy Agent (OPA, pronounced “oh-pa”) is an open source, general-purpose policy engine that unifies policy enforcement across the stack. OPA provides a high-level declarative language that let’s you specify policy as code and simple APIs to offload policy decision-making from your software.

What is docker-security-cheker?

docker-security-checker uses open policy agent rego policies for Dockerfile security checks using Conftest.

Checkout more information at https://github.com/madhuakula/docker-security-checker

How to write a simple rego policy for Dockerfile?

The below is simplest example of a rego policy for identifying if the Dockerfile is using ADDinstead of COPY command in the Dockerfile.

deny[msg] {

   input[i].Cmd == "add"

   val := concat(" ", input[i].Value)

   msg = sprintf("Use COPY instead of ADD: %s", [val])

}

Here in the above example input contains the Dockerfile in a JSON format and we are looking for any command we find ADD and if we find in the Dockerfile we are returning the deny message.

This is much simplified by using Conftest, also it supports multiple different files, formats like Kubernetes manifests, terraform, ini, etc. to build your own policies with OPA checkout examples at https://www.conftest.dev/examples/

Running conftest docker security policies

You can run the conftest using the following command, which by default pickup the policies from policy directory.

conftest test Dockerfile

Now you can see similar output

WARN - Dockerfile - Do not use latest tag with image: ["ubuntu:latest"]
FAIL - Dockerfile - Suspicious ENV key found: ["SECRET", "AKIGG23244GN2344GHG"]
FAIL - Dockerfile - Use COPY instead of ADD: app /app
FAIL - Dockerfile - Use COPY instead of ADD: code /tmp/code

5 tests, 1 passed, 1 warning, 3 failures

Try out yourself

I had built this scenario to try out your self to learn and practice rather reading it and forgetting ;)

You can practice this scenario at katacoda playground https://katacoda.com/madhuakula/scenarios/docker-security-checker

https://katacoda.com/madhuakula/scenarios/docker-security-checker

Some ideas to take this forward

Adding this checks in CI/CD pipeline as part of the DevSecOps
Also, integrating these checks at your Kubernetes clsuters as a DaemonSet to look for Kubernetes Objects for any security misconfigurations and issue in near real-time
Many more…
Please feel free to contribute and add more feedback/issues/PR at https://github.com/madhuakula/docker-security-checker

References to learn more

I just started learning more and more about Open Policy Agent and writing security policies using conftest. But you can explore more about them and write your own policies using below resources.

Thanks for reading this article. If you enjoyed it please let me know by clicking that clap below :)

A Fond Farewell to Appsecco

Madhu Akula — Fri, 17 Jan 2020 02:26:01 +0000

TL;DR: Woah! What an exciting ride it was :)

Image by Gerd Altmann from Pixabay

Hello everyone, I’m not sure how I should start writing this post. It’s been one amazing ride these last few years at Appsecco. I believe all good stories need to be told, so here’s me writing about my journey as one of the earliest core team member of an amazing company with an even more amazing team!

An unbelievable opportunity

It all started when I was about to quit my previous job and was thinking of moving outside India for sometime. Given that I had worked with Akash before, I sought his opinion and ended up accepting an offer to work with him at Appsecco. Back then, I was just excited to work with him and Riyaz, but little did I know that it would become one of the most fulfilling adventures of my life. It is here that I began my journey to fulfill my goals and (many a times, items from a bucket list that I did not even know existed) in both as part of my professional and personal career.

I have always tried to build myself as a T-shaped individual at Appsecco, focusing on depth in security as my primary area and breadth of everything including building training programs, consulting, individual personality and adding to our amazing company culture. It wouldn’t be fair if I don’t give credit to the amazing people I have had the opportunity to work with in these last few years.

If you haven’t read how I joined Appsecco and what my first month looked like, I highly recommend you read this :D

I can’t believe it’s been a month already @ Appsecco!

The first year

I cannot believe that I did so many cool things in my first year itself. I started working on opensource platforms, created solutions to manage the company’s operations while breaking and pwning applications and servers whenever I could with Riyaz and his team.

Our ubercool free upgrade to Business class in an Emirates A380 flight to the US for DEFCON, Las Vegas :)

I started preparing myself to OSCP (offensive security certified professional) as a way to challenge my self and to sharpen my attacker skills with help of Riyaz Walikar (aka wincmdfu) in early December 2016. I have nothing but immense respect for Riyaz for his patience and explaining concepts to someone who doesn’t have much knowledge about that topic. The way he visualises targets and application features to identify where the vulnerabilities could be, sometimes even without actually making any HTTP requests, is just mind-boggling. I wish there was a Brain-as-a-Service thingy so that I could utilise his skills and attacker mindset. I was able to successfully complete my OSCP and it helped me gain a lot of confidence in the approach to testing for security and finding cool bugs.

Madhu Akula

@madhuakula

As part of my to-do checklist at @appseccouk I completed my #OSCP certification 😀

09:39 AM - 19 Jan 2017

In my time at Appsecco, I had lots of opportunities to perform security testing for applications and servers for variety of clients across industry verticals and I did use them to find some amazing vulnerabilities.

One of the best things I learnt while performing security assessments at Appsecco, is that it’s not only important to show what cool vulnerability you found, but it is far more ubercool to explain the vulnerability and it’s mitigation in a friendly language that developers can consume and fix their stuff.

As time progress, I started creating research talks, trainings and workshops that I liked to present. I toured a bunch of industry notable conferences around the world like DEFCON, All Day DevOps, nullcon, DevSecCon, at the null community etc. This also allowed me to travel around the world in my first year itself!

By the end of my first year, I was able to work on a given problem statement and come up with pragmatic solution (with automation as the key). I started working with the 3 largest cloud providers (AWS, Azure and GCP) and opensource software platforms like HashiCorp Stack (Vagrant, Terraform, Packer, etc). I ended up writing numerous automation playbooks using Ansible and custom scripts as well.

While trying out some OpenSource products and platforms, I found critical vulnerabilities in GitLab CI/CD private build system, SaaS based malware analysis platform, etc. that could be additional visibility in the security community, which was very cool.

As part of building stuff internally, I created an in-house infrastructure security monitoring system using Elastic Stack and Beats with ElastAlert for detecting attacks and alerting our teams.

I can surely say that I have never before coming to Appsecco, built these many Proof of Concepts on multiple open source tools and technologies on Monitoring, CI/CD, Version Control, Scanning, Auditing, etc. which helped me to explore even more wide variety of platforms, products and stacks. Using all of the collective knowledge, I built an automated markdown based documentation, knowledge base system using Raneto, MkDocs, Gitbooks with help of pipelines, containers and Kubernetes.

Me presenting my first DEFCON workshop in Las Vegas :)

I can go on and on about all the cool technical things I did, but this post would be incomplete if I don’t talk about the people I worked with and with whom I started my journey at Appsecco.

Our tech team when we started the company and our fancy backdrop :D

Our awesome team outings. By the way these are blue team and red team (of course blue team won :D)

Here is my 1 year working at Appsecco blogpost. It’s fun read about things I have done over a year with an amazing team :)

1 Year @Appsecco

As time flew by

We have always been a small team of people doing amazing and cool work and that kept us busy. So I started working on more and more operational work to use Docker containers and Kubernetes clusters to help other teams streamline their work, which helped us to automate most of our deployments using CI/CD pipelines, resulting in lots of time saved to do more cool things and do research.

Me teaching my first BlackHat training on “Automated Defense using Cloud Service for AWS, Azure and GCP”

Over the years, I also kept my promise of giving back to the community by teaching and sharing my work at multiple conferences including BlackHat, OWASP Appsec, USENIX LISA, All Day DevOps, DevSecCon, nullcon, null and many more.

Some of my conferences photos :D

With our experience of doing automation using Ansible, Akash Mahajan suggested that we can share what we learnt with everyone to perform their daily security tasks. So we ended up writing a book on Security Automation using Ansible2, which is also referenced as a technical resource by RedHat Ansible itself. This fulfilled a life goal of mine without me realising I wanted it. The feedback about the book was very heartwarming from friends, the community and total strangers on the Internet.

I haven’t met or worked with anyone in my entire career and personal life who shares the same attitude towards life like Akash. A quote that I will always remember that he said to me was “Knowledge is noble”. This keeps me motivating and will continue to do so to keep learning new things and trying them out. One thing he explained was about fatigue that if you continue to do the same thing for too long there are chances that I would get bored. However, as I picked up several different technologies and got better at many new things rapidly, Akash helped me automate several things that would leave my time for cool new things that I would like to pickup. As a mentor, Akash also worked with me to figure out what makes me happy and what new exciting things we could work at so that Appsecco could benefit from my energy levels while I would develop my career and technical skills at a personal level.

As we moved forward, we started working with more and more challenges in automation and cloud native technologies. At this point, Akash suggested that I become a Certified Kubernetes Administrator by appearing for the CKA exam. This aligned perfectly with my personal interest as well, as I was on my way to digging deeper into container and orchestration security. As most of our workloads ran on Kubernetes, it was easy to get started and prepare for the exam. I learnt a LOT in the next few months as I realised that the more deeper I got into understanding about cluster specific operations like API Server and troubleshooting etc. I got better at identifying potential security pitfalls and how we could secure clusters and what could be the potential attack surface as well.

Madhu Akula

@madhuakula

Did I tell you that I have passed @linuxfoundation and @CloudNativeFdn Certified @kubernetesio Administrator exam with 95%?

Thanks @makash for motivation me to take the exam. @appseccouk team you are amazing & always helped me to achieve my goals!

#CKA #Kubernetes

15:18 PM - 01 May 2019

The certification and my personal interest pushed me into learning more about containers, Kubernetes and the ever evolving cloud native landscape. So I started giving more time to research and ended up building an amazing training focusing on both attackers and defenders perspectives in container security. I eventually had an opportunity to present my research and training at a wide variety of my dream conferences including USENIX :D

Some of the screenshots of my Docker Containers and Kubernetes Cluster Hacking Training

While presenting at multiple conferences, I realised that I wanted to build my leadership and management skills as well. I have been lucky enough to moderate one of the worlds largest DevOps conference (30k+ audience) called All Day DevOps for the past 4 years. I moderate their DevSecOps track which not only helped me build my leadership and communication skills, also gave me a lot of friends, connections and community involvement.

If you haven’t read about how I speak and moderate AllDayDevOps conference for the past 4 years, I suggest you must read this :D

Moderating and Presenting at All Day DevOps

Appsecco provided me with a lot of opportunity to travel the world. In my stint here, I have done some amazing trips to some of the most beautiful cities in the world.

My high level travel history while at Appsecco

Travelling to a different city/country without fun is no travel at all :)

One of the things I will take back with me is the support and ever learning culture that Appsecco provides that helps it’s employees to achieve their dreams and put their progress in the right direction.

To spice things up at work and to break some monotony that had started to develop, I suggested that we should do team hackthons in office. So one Friday a month would be when there was no client work assigned but pure hacking and breaking. We ended up doing lots of cool hacking and gulping down copious amounts of Coke Zero and Pizzas :) Our internal Hackathons have not only helped the team think of edge cases and create out of the box attack scenarios but also helped build team spirit and get better at collaboration.

Akash Mahajan - Chat about Cloud DataSec & AppSec

@makash

Some of the @appseccouk team decided today was a day to participate in a #hackathon today. 😃😃😃

Cc @abh1sek @0xbharath @madhuakula @_riddhishree @riyazwalikar @suneshgovind

04:40 AM - 15 Nov 2019

A very simple responsibility I picked up was to send a daily quote to everyone in the company, first thing in the morning. This allowed me to read up on so much motivational stuff, figure out what would be applicable to Appsecco and keep my energy levels going throughout the day.

Here’s an example quote that I have shared with the team

Daily Quotes by me for to keep everyone motivated and learn cool things about team work and collaboration

In my last year at Appsecco, I was fortunate to work with Abhisek Datta to build internal automation platform using Kubernetes and cloud native technologies. This platform helps our Security Testing team to hasten up their process of discovery of low hanging fruits while the team can work on attacking the bigger bits.

First Kubernetes Day Bangalore!

Abhisek Datta or Datta sir as he is lovingly addressed by most of us, has an insane amount of patience. His experience across domains like attack, defense, automation and development is something I have never see. His trolling capabilities are next level too!

Working with Abhisek has taught me the most important parts of my work. My approach towards any task that I pick up was to dive right into it because of my hunger for knowledge, but working with him allowed me to focus on the thought process and figure out the most simple, yet elegant solutions to the problem statement in question.

When not working, most of my time spent in office was hanging out with my cool colleagues and having fun with them. Bharath, Riddhi and Sunesh are always up for coffee break and random discussions (which would eventually come back to something technical), making me realise that Appsecco is a company of people with amazingly common interest towards same goal with the hunger to achieve it.

Our team at Kochi airport, going for c0c0n to deliver our workshops :)

Our Friday lunches was an amazing break from work and we have tried a variety of restaurants and cuisine in Indiranagar. My favourite has been Bombay Brasserie and my favourite food has been Kashmiri Naan Kebab and Amritsari Kulfa.

My amazingly favourite dessert, Amritsari Kulfa :D

The last month

Last month I decided to tell Akash, Abhisek and Gwil about my plans for the future and how I wanted to move on to my next adventure. It has been the most difficult thing I have had to do. It was like telling your family you are leaving them and not knowing how they would react or feel.

But when I told them, for reasons I did not fully understand, they were happy for me! This was very weird in my head as I had not anticipated them to be happy.

They said that I have done so much at Appsecco and put in all the effort I could to ensure the company and community progresses that they had nothing but good luck for me. It’s a good sign, they said, as my career is still growing (and being young :D) now would be a good time to explore.

When it came to transition and handing over of responsibilities, access and data, it could not have been smoother. Apart from doing all of that, we had the most fun, I think in recent times, this month.

Our amazing and awesome Ubercool team :D

We had fun outings, cool lunches and dinners, secret santa, bowling, go-karting, games, eating, drinking, etc. to name a few, mostly thanks to our new Fun Committee in-charge — Shruthi Kamath.

Our Christmas team outing and fun activities :)

I have had really great time working at Appsecco. My time year has nothing been short of a movie. A blockbuster, not the flop types. The people, the culture, the learning, the fun, the trolling, the acceptance of new tech, the embracing of failures, the celebration of success and the ever constant push to do more than you are capable of. I will always be thankful for the opportunity given to me and I believe that very few companies out there will match my experience of Appsecco.

5 key things I learnt at Appsecco

To end this looooooong blogpost, here’s 5 cool things I picked up at Appsecco as part of my non-technical learning

Don’t assume anything. As the quote goes — Never ASSUME, because when you ASSUME, you make an ASS out of U and ME
The company is as strong as the team
Set your dream goals and work towards them
Communication is the key to everything
It’s okay to fail and learn from failures

What is next for me

Alas, all good stories need a sequel. My journey has just begun in the world of security of Cloud, Containers, Kubernetes and Cloud native landscape. I’m moving on to a different place, to get a taste of a different culture and to try something new and hopefully as exciting as my time here.

If I want to leave you all with just one thought, remember

Great things happen to those who don’t stop believing, trying, learning, and being grateful.

— Roy Bennett

Follow me on Twitter or LinkedIn for upcoming updates :)

Madhu Akula

Thank you so much Riyaz Walikar for reviewing my blogpost, you are awesome as always :)

Submit your proposal to All Day DevOps

Madhu Akula — Tue, 30 Apr 2019 01:46:20 +0000

All Day DevOps — World’s largest DevOps conference

Why you should submit your proposal to All Day DevOps

Speaking and working experience with one of the worlds largest online community

Hello Everyone,

This blog post is all about All Day DevOps, especially why you should submit your proposal to see the world class experience of presenting your research. I have added my experience as a veteran at speaking and organizing All Day DevOps event for the past 3 years and it’s keep growing :)

First of all let me tell you what is All Day DevOps

All Day DevOps is a FREE online community responsible for creating the world’s largest DevOps conference.

✅ 24 Hours

✅ Live Streaming

✅ 125 Speakers

✅ Five Tracks

✅ 38 Time Zones

✅ World wide viewing parties

✅ Free Registration

✅ No Travel Required

All Day DevOps 2016

It all started from All Day DevOps 2016, I have had an opportunity present my research Automated Infrastructure Security Monitoring with FOSS and got wonderful response and feedback from the community, organizers and around them. It almost built my confidence to next level to prepare, present at 13k+ crowd.

I still remember and bookmarked the CFP page of All Day DevOps 2016. This conference helped me to get some great friends and chance to contribute and work with amazing organizers Derek E. Weeks, Mark Miller and devsecops. They have helped me throughout the conference as well as post conference and now as well :)

I would have to really appreciate and give credit to my company Appsecco and Akash Mahajan for pushing me towards to contribute to community and helping me all the way along :)

Speakers photo from All Day DevOps 2016

All Day DevOps 2017

This year I had taken more responsibility and privileged to share my research with community. In this year I had chance to moderate the DevSecOps track and speak as well. Initially bit nervous but you don’t believe what I had done. Read my story about taking at taking two role during All Day DevOps

Moderating and Presenting at All Day DevOps

https://medium.com/media/1a7f2c2a9d488bb42445cb20ed82e3fa/href

Speakers photo from All Day DevOps 2017

All Day DevOps 2018

As I had done great job with previous year. This year I continued to take my role as moderator for DevSecOps track and presenting my research.

In this year I had also did some chitchat preview interview with Mike Rosado about my presentation “Container Security Monitoring using Open Source” and about my self and other things. You can watch the video below

All Day DevOps

And here is the my presentation from All Day DevOps 2018

https://medium.com/media/06564555a0b6066eec8acb6f81b0ce1f/href

Speakers photo from All Day DevOps 2018

Some of the cool goodies you will get includes, I love them all the time :D

Some of the benefits you will get by speaking at All Day DevOps

Get a chance to present your amazing work to the world
Get review, feedback and suggestions from organizers, reviewers and participants
Build your confidence to next level as you are facing almost 30k+ participants from variety levels and skills in the world
One of the great speaking experience from submitting to the post conference. You will definitely learn something along the way, if you are the veteran at speaking also ;)
You will get help from organizers throughout the conference to build your presentation, review, prepare for the session, per-checks and many more
Awesome preview interview with Mike Rosado about your session and your hobbies, etc
Get to interact with fellow speakers, moderators and organizers
Talking to the amazing crowd of participants in the slack channel
And I totally forgot to mention, You will get an amazingly ubercool speaker goodies and I love them all the time :D
Build your personal and your organisation public brand in social media and other news coverage
Many more, I think this list keep going…

Remember that what is ordinary to you is awesome for someone else

What’s about this year?

The 4th Annual All Day DevOps is on November 6, 2019. Starting at 9:00am GMT and continuing for 24 hours, there will be 5 simultaneous tracks, with each track containing a continuous series of 30-minute presentations, for a total of over 50+ hours of presentations. Attendance is free.

The high level overview of tracks includes

There are 5 defined tracks:

Cloud Native Infra and Monitoring
DevSecOps and Automated Security
CI/CD — Continuous Everything
Cultural Transformation
SRE — Site Reliability Engineering

I have submitted my talk for this year and also moderating DevSecOps track as well. Looking forward and excited to the All Day DevOps 2019!

Excited!! Want to share your story with All Day DevOps 2019, then submit your talk at https://sessionize.com/2019-all-day-devops

I would like thank every organizer, moderator, speaker, supporters, sponsors and awesome participants without them we can’t have this free online community.

Thanks for reading the article, if you like it please share with others by clicking on the clap icon - Follow me on twitter @ madhuakula

Some tips to review Docker Hub Hack of 190k accounts

Madhu Akula — Sat, 27 Apr 2019 18:05:37 +0000

Docker Hub Hack of 190k accounts compromised and put everyone at risk!

As most of you must be aware, Docker Hub has been compromised very recently and this attack has put almost 190K users at risk. According to me, this is one of the craziest supply chain attacks in the recent history. I say so, because it is not easy to make oneself foolproof against this attack. We might have to review multiple things before we feel safe, and still, we cannot provide the guarantee that we are secure enough.

Read more about this hack in Hacker News thread

Docker Hub Hacked - 190k accounts, GitHub tokens revoked, Builds disabled | Hacker News

For your benefit, I have come up with a list of checks which might help you to review your Docker hub, Github account, etc. Listed below are some of the checks that might help you while reviewing your Docker hub, Github accounts. All of these points are taken from my personal checklist, and they might or might not guarantee that you are completely secure.

Checklist

Check each of your repository image’s last build time, and see if you could identify any suspicious build. Additionally, check if any new tags were created for the images, or, if new images have been created or pushed manually

Review the repository settings and check if any new collaborator has been added without your knowledge

Review all external webhooks. Check if a suspicious webhook has been added to any of the repositories, or, if an existing webhook has been modified suspiciously

Review your organization’s team members and ensure that any unknown user has not been added

Ensure your automated builds from version control systems have been revoked and reconnected. Also, check for new connections or providers that might have been added suspiciously. Finally verify if the emails are mentioned correctly and that no new or modified webhooks have been added

Navigate to your version control system provider and ensure you revoke the existing application integration and tokens. Also, review if any new GitHub apps have been added or if the existing ones have been removed

Review yours and your organisation’s GitHub security activity to verify if any suspicious changes have been made over time

Review your organisation’s and your personal account’s audit logs. Review any changes that have been made based on the privileges of the Docker Hub integration with GitHub

Some additional checks which might be done includes, verifying your base images and existing images as it is possible that the corresponding owner accounts might have been compromised too. Use some open source image scanners like Clair, Vulners Audit, etc. These checks would apply even if you are not in Docker Hub and are using a private registry. This is because you might have ended up using some external base image like nginx, alpine, etc.
Monitor, and monitor again, all the things (containers) that you are running. This is required because there are chances that some of the running containers might have been compromised already

These are some of the tips that I came up with and I would love to know what are some of the other thing that you might be thinking of and that could be helpful for our community. Please leave your comments and suggestions here and I will incorporate your suggestions into my post.

Contributors

Riddhi Shree

Please feel free to provide any feedback, suggestions or improvements. If you liked this article, click the 👏 button and share this post so that other people could also benefit from this post.