Automating an Attacking VM for Kubernetes Goat with Ansible and Kali Linux

Last updated on Jun 17, 2026

With the Kubernetes Goat environment now fully automated using Ansible, the next logical step was obvious:

Automating the attacking side as well.

Up until this point, I’d been:

manually installing tools
rebuilding test VMs
tweaking configurations
forgetting packages
recreating shell aliases
reinstalling Kubernetes tooling repeatedly

That gets old quickly.

So instead, I decided to build a fully automated Kali Linux attacker VM designed specifically for interacting with:

Kubernetes Goat
Kubernetes clusters
vulnerable web applications
exposed Traefik ingress routes
container security tooling

The goal was simple:

Rebuild the attacking environment just as easily as the cluster itself.

Now the entire lab can be recreated rapidly:

Kubernetes cluster
vulnerable applications
ingress exposure
attacker VM
offensive tooling

All from automation.

Why Automate the Attacker VM?

One of the most frustrating parts of security labs is environment drift.

Over time:

packages become outdated
aliases disappear
tooling versions differ
Python environments break
dependencies conflict

Eventually every VM becomes slightly unique.

That makes testing inconsistent.

Automating the attacker VM solves this by ensuring:

reproducibility
consistency
rapid recovery
predictable tooling

And honestly, rebuilding a disposable offensive security VM is often faster than troubleshooting a broken one.

Why Kali Linux?

There are plenty of distributions that work well for offensive security labs:

Ubuntu
Parrot OS
BlackArch
Debian

But Kali remains the easiest option for quickly building security testing environments because:

most tooling already exists in the repositories
documentation is widespread
package maintenance is solid
cloud images are available
automation works well

For this project, Kali’s cloud images were the key feature.

Using Cloud-Init for Fast VM Deployment

Rather than manually installing Kali every time, I switched to using:

Kali cloud images
cloud-init
automated provisioning

This dramatically speeds up deployment.

The process becomes:

Download cloud image
Create VM
Inject cloud-init config
Boot
Automatically configure everything

No manual installation required.

What Cloud-Init Handles

The cloud-init configuration:

creates users
configures SSH
injects keys
sets passwords
installs base packages
configures networking
enables sudo
prepares the VM for Ansible

This turns a generic Kali image into a ready-to-use attack platform within minutes.

Example Cloud-Init Configuration

My base configuration looks something like this:

#cloud-config

hostname: kali-kubernetes

users:
  - name: kali
    groups: sudo
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
  - name: ansible
    groups: sudo
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL

ssh_pwauth: true

package_update: true
package_upgrade: true

packages:
  - curl
  - git
  - python3
  - python3-pip
  - net-tools
  - nmap

This keeps the initial VM lightweight while preparing it for the larger Ansible configuration phase.

Why Use Ansible After Cloud-Init?

Cloud-init is excellent for:

first boot setup
networking
user creation
basic packages

But Ansible is significantly better for:

complex tooling
idempotent installs
reusable configurations
modular provisioning
large package sets

So the workflow becomes:

Tool	Purpose
cloud-init	Bootstrap VM
Ansible	Full offensive tooling setup

This separation keeps things clean and maintainable.

Offensive Tooling Automation

The Ansible playbook installs:

Kubernetes tooling
container tooling
web exploitation tools
reconnaissance tools
API testing utilities
debugging utilities

This creates a purpose-built Kubernetes attack workstation.

Kubernetes Tooling

The first set of tools focuses on Kubernetes interaction:

kubectl
k9s
helm
kube-hunter
kubescape
trivy

These provide:

cluster enumeration
workload inspection
security scanning
configuration analysis

Web Application Tooling

Because Kubernetes Goat exposes vulnerable web services, web tooling is essential:

burpsuite
owasp-zap
nikto
ffuf
sqlmap

This enables:

API testing
fuzzing
scanning
SSRF testing
authentication testing

Container and Runtime Tooling

Container-focused tooling is also useful:

docker
crictl
ctr
dive
syft
grype

These help investigate:

images
vulnerabilities
runtimes
containers
package inventories

Network Reconnaissance

Basic network tooling remains invaluable:

nmap
masscan
tcpdump
wireshark

Even inside Kubernetes labs, visibility matters.

Why Disposable Attack VMs Are Useful

A disposable attacker VM provides several advantages:

clean state
repeatable tests
isolation
rapid rollback
easier experimentation

When something breaks:

destroy VM
recreate VM
rerun playbook

Done.

Integrating with the Kubernetes Goat Cluster

Because the cluster already exposes:

Traefik entrypoints
external ports
ingress routes

…the Kali VM can immediately interact with:

vulnerable services
APIs
dashboards
intentionally insecure workloads

No additional setup is required.

Future Improvements

There are several things I’d like to automate next.

Snapshot Automation

Automatically snapshotting:

the cluster
the attacker VM

…would make rollback even easier.

Terraform Integration

At the moment:

VM creation
cloud-init attachment

…are still partially manual.

Terraform would solve this cleanly.

Multiple Attacker Profiles

It would also be useful to create:

lightweight recon VMs
Kubernetes-focused VMs
malware-analysis VMs
purple-team systems

All generated from automation.

Final Thoughts

One of the most satisfying things about home labs is when they evolve from:

isolated experiments
hand-built systems
fragile configurations

…into fully automated environments.

At this point, the Raspberry Pi cluster can:

deploy Kubernetes
expose vulnerable applications
configure ingress
automate security labs

…and now even provision the attacker infrastructure automatically.

That turns the entire environment into something much more powerful:
a reproducible Kubernetes security playground.

And the best part is that rebuilding the entire thing now takes minutes instead of hours.

About the author

Tim Wilkes is a UK-based security architect with over 15 years of experience in electronics, Linux, and Unix systems administration. Since 2021, he's been designing secure systems for a telecom company while indulging his passions for programming, automation, and 3D printing. Tim shares his projects, tinkering adventures, and tech insights here - partly as a personal log, and partly in the hopes that others will find them useful.

Want to connect or follow along?

LinkedIn: [phpsytems]
Twitter / X: [@timmehwimmy]
Mastodon: [@timmehwimmy@infosec.exchange]

If you've found a post helpful, consider supporting the blog - it's a part-time passion that your support helps keep alive.

⚠️ Disclaimer

This post may contain affiliate links. If you choose to purchase through them, I may earn a small commission at no extra cost to you. I only recommend items and services I’ve personally read or used and found valuable.

As an Amazon Associate I earn from qualifying purchases.