Step by step, with screenshots: install Kali Linux and turn on SSH, every screen shown.

An official arm64 build, and the right file to use

Kali Linux, maintained by OffSec, publishes generic arm64 installer ISOs next to a long list of images for specific single-board computers. For a VM you want the generic installer. The Raspberry Pi and other board images carry hardware-specific kernels and won't boot in a virtual machine.

In the catalog, installed by hand

Velo Workspaces 1.2 has Kali in its catalog, so you don't have to find the right file yourself. Create a workspace, choose Installer image and pick Kali Linux; the app downloads the current arm64 installer from Kali's servers and checks it against Kali's published checksum. Kali's installer is debian-installer, and like Debian's it isn't automated yet, so you go through it yourself in the workspace's display: your user, partitioning, and which tool sets to install. When the installed system has booted, click Installation Complete in the banner at the top of the workspace. After a manual install the app can't tell on its own that you're done, so until you click, it keeps attaching the installer and keeps the Large Text display scaling that makes the installer readable. Stop and start the workspace once afterwards to switch to its own display setting.

A Kali cloud image that sets itself up on first boot is on the roadmap for a 1.2.x update. Kali publishes it as a compressed archive rather than a disk image, so the app needs to unpack it first.

NAT networking, and what it means for a lab

Velo Workspaces uses NAT networking only; bridged networking needs an entitlement the app doesn't have, as the Virtualization.framework post explains. For most Linux guests you'd never notice. For Kali it matters more, because much of the toolkit is meant for scanning and testing other devices on your network. Behind NAT, the guest sits on the Mac's private virtual network, not your LAN. Tools that connect out to a target by address work; tools that expect to share a network segment with their targets, like ARP scans, won't see them. Check what a tool needs before you build a workflow on it.

Why disposable workspaces suit a testing lab

Tools, scan results and artifacts from one engagement have no business carrying over into the next, and a lab that has piled up months of leftovers makes it hard to say you tested from a clean baseline. Install and configure Kali once, save it as a base image, and start each engagement from a fresh disposable workspace cloned from it. Closing it deletes it, and the next one starts from exactly the same state. Base images as versioned infrastructure covers the base-image half of that.

Related reading: Debian on Apple Silicon, which uses the same installer; disposable VMs for testing untrusted software; and how Linux VM networking works on Apple Silicon. Or download Velo Workspaces and try it yourself.