{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicikaeug4jnar37gigbmpjmfhktb7qnc534ihj7nbc7g4if67r3aq",
    "uri": "at://did:plc:5y2ps7xhcqmc2d63b73ui72s/app.bsky.feed.post/3moiveycemqo2"
  },
  "description": "Build an automated Kali Linux attacker VM for your Raspberry Pi Kubernetes Goat lab using cloud-init and Ansible to create a repeatable Kubernetes security testing environment.",
  "path": "/automating-an-attacking-vm-for-kubernetes-goat-with-ansible-and-kali-linux/",
  "publishedAt": "2026-06-17T18:00:18.000Z",
  "site": "https://blog.php-systems.com",
  "textContent": "With the Kubernetes Goat environment now fully automated using Ansible, the next logical step was obvious:\n\n> Automating the attacking side as well.\n\nUp until this point, I’d been:\n\n  * manually installing tools\n  * rebuilding test VMs\n  * tweaking configurations\n  * forgetting packages\n  * recreating shell aliases\n  * reinstalling Kubernetes tooling repeatedly\n\n\n\nThat gets old quickly.\n\nSo instead, I decided to build a fully automated Kali Linux attacker VM designed specifically for interacting with:\n\n  * Kubernetes Goat\n  * Kubernetes clusters\n  * vulnerable web applications\n  * exposed Traefik ingress routes\n  * container security tooling\n\n\n\nThe goal was simple:\n\n> Rebuild the attacking environment just as easily as the cluster itself.\n\nNow the entire lab can be recreated rapidly:\n\n  * Kubernetes cluster\n  * vulnerable applications\n  * ingress exposure\n  * attacker VM\n  * offensive tooling\n\n\n\nAll from automation.\n\n* * *\n\n# Why Automate the Attacker VM?\n\nOne of the most frustrating parts of security labs is environment drift.\n\nOver time:\n\n  * packages become outdated\n  * aliases disappear\n  * tooling versions differ\n  * Python environments break\n  * dependencies conflict\n\n\n\nEventually every VM becomes slightly unique.\n\nThat makes testing inconsistent.\n\nAutomating the attacker VM solves this by ensuring:\n\n  * reproducibility\n  * consistency\n  * rapid recovery\n  * predictable tooling\n\n\n\nAnd honestly, rebuilding a disposable offensive security VM is often faster than troubleshooting a broken one.\n\n* * *\n\n# Why Kali Linux?\n\nThere are plenty of distributions that work well for offensive security labs:\n\n  * Ubuntu\n  * Parrot OS\n  * BlackArch\n  * Debian\n\n\n\nBut Kali remains the easiest option for quickly building security testing environments because:\n\n  * most tooling already exists in the repositories\n  * documentation is widespread\n  * package maintenance is solid\n  * cloud images are available\n  * automation works well\n\n\n\nFor this project, Kali’s cloud images were the key feature.\n\n* * *\n\n# Using Cloud-Init for Fast VM Deployment\n\nRather than manually installing Kali every time, I switched to using:\n\n  * Kali cloud images\n  * cloud-init\n  * automated provisioning\n\n\n\nThis dramatically speeds up deployment.\n\nThe process becomes:\n\n  1. Download cloud image\n  2. Create VM\n  3. Inject cloud-init config\n  4. Boot\n  5. Automatically configure everything\n\n\n\nNo manual installation required.\n\n* * *\n\n# What Cloud-Init Handles\n\nThe cloud-init configuration:\n\n  * creates users\n  * configures SSH\n  * injects keys\n  * sets passwords\n  * installs base packages\n  * configures networking\n  * enables sudo\n  * prepares the VM for Ansible\n\n\n\nThis turns a generic Kali image into a ready-to-use attack platform within minutes.\n\n* * *\n\n# Example Cloud-Init Configuration\n\nMy base configuration looks something like this:\n\n\n    #cloud-config\n\n    hostname: kali-kubernetes\n\n    users:\n      - name: kali\n        groups: sudo\n        shell: /bin/bash\n        sudo: ALL=(ALL) NOPASSWD:ALL\n      - name: ansible\n        groups: sudo\n        shell: /bin/bash\n        sudo: ALL=(ALL) NOPASSWD:ALL\n\n    ssh_pwauth: true\n\n    package_update: true\n    package_upgrade: true\n\n    packages:\n      - curl\n      - git\n      - python3\n      - python3-pip\n      - net-tools\n      - nmap\n\nThis keeps the initial VM lightweight while preparing it for the larger Ansible configuration phase.\n\n* * *\n\n# Why Use Ansible After Cloud-Init?\n\nCloud-init is excellent for:\n\n  * first boot setup\n  * networking\n  * user creation\n  * basic packages\n\n\n\nBut Ansible is significantly better for:\n\n  * complex tooling\n  * idempotent installs\n  * reusable configurations\n  * modular provisioning\n  * large package sets\n\n\n\nSo the workflow becomes:\n\nTool | Purpose\n---|---\ncloud-init | Bootstrap VM\nAnsible | Full offensive tooling setup\n\nThis separation keeps things clean and maintainable.\n\n* * *\n\n# Offensive Tooling Automation\n\nThe Ansible playbook installs:\n\n  * Kubernetes tooling\n  * container tooling\n  * web exploitation tools\n  * reconnaissance tools\n  * API testing utilities\n  * debugging utilities\n\n\n\nThis creates a purpose-built Kubernetes attack workstation.\n\n* * *\n\n# Kubernetes Tooling\n\nThe first set of tools focuses on Kubernetes interaction:\n\n\n    kubectl\n    k9s\n    helm\n    kube-hunter\n    kubescape\n    trivy\n\nThese provide:\n\n  * cluster enumeration\n  * workload inspection\n  * security scanning\n  * configuration analysis\n\n\n\n* * *\n\n# Web Application Tooling\n\nBecause Kubernetes Goat exposes vulnerable web services, web tooling is essential:\n\n\n    burpsuite\n    owasp-zap\n    nikto\n    ffuf\n    sqlmap\n\nThis enables:\n\n  * API testing\n  * fuzzing\n  * scanning\n  * SSRF testing\n  * authentication testing\n\n\n\n* * *\n\n# Container and Runtime Tooling\n\nContainer-focused tooling is also useful:\n\n\n    docker\n    crictl\n    ctr\n    dive\n    syft\n    grype\n\nThese help investigate:\n\n  * images\n  * vulnerabilities\n  * runtimes\n  * containers\n  * package inventories\n\n\n\n* * *\n\n# Network Reconnaissance\n\nBasic network tooling remains invaluable:\n\n\n    nmap\n    masscan\n    tcpdump\n    wireshark\n\nEven inside Kubernetes labs, visibility matters.\n\n* * *\n\n# Why Disposable Attack VMs Are Useful\n\nA disposable attacker VM provides several advantages:\n\n  * clean state\n  * repeatable tests\n  * isolation\n  * rapid rollback\n  * easier experimentation\n\n\n\nWhen something breaks:\n\n  * destroy VM\n  * recreate VM\n  * rerun playbook\n\n\n\nDone.\n\n* * *\n\n# Integrating with the Kubernetes Goat Cluster\n\nBecause the cluster already exposes:\n\n  * Traefik entrypoints\n  * external ports\n  * ingress routes\n\n\n\n…the Kali VM can immediately interact with:\n\n  * vulnerable services\n  * APIs\n  * dashboards\n  * intentionally insecure workloads\n\n\n\nNo additional setup is required.\n\n* * *\n\n# Future Improvements\n\nThere are several things I’d like to automate next.\n\n* * *\n\n# Snapshot Automation\n\nAutomatically snapshotting:\n\n  * the cluster\n  * the attacker VM\n\n\n\n…would make rollback even easier.\n\n* * *\n\n# Terraform Integration\n\nAt the moment:\n\n  * VM creation\n  * cloud-init attachment\n\n\n\n…are still partially manual.\n\nTerraform would solve this cleanly.\n\n* * *\n\n# Multiple Attacker Profiles\n\nIt would also be useful to create:\n\n  * lightweight recon VMs\n  * Kubernetes-focused VMs\n  * malware-analysis VMs\n  * purple-team systems\n\n\n\nAll generated from automation.\n\n* * *\n\n# Final Thoughts\n\nOne of the most satisfying things about home labs is when they evolve from:\n\n  * isolated experiments\n  * hand-built systems\n  * fragile configurations\n\n\n\n…into fully automated environments.\n\nAt this point, the Raspberry Pi cluster can:\n\n  * deploy Kubernetes\n  * expose vulnerable applications\n  * configure ingress\n  * automate security labs\n\n\n\n…and now even provision the attacker infrastructure automatically.\n\nThat turns the entire environment into something much more powerful:\na reproducible Kubernetes security playground.\n\nAnd the best part is that rebuilding the entire thing now takes minutes instead of hours.",
  "title": "Automating an Attacking VM for Kubernetes Goat with Ansible and Kali Linux",
  "updatedAt": "2026-06-17T18:00:18.717Z"
}