|
|
|
|
|
by JeremyNT
7 days ago
|
|
The way I did it, I've got a convention where I store git checkouts in a specific directory on my laptop. I use the repo name as an argument and the wrapper script creates / shells into the per-project VM. It uses cloud-init for the initial setup and injects the agent's config file and some other stuff in a ro mount from my laptop. That single subdirectory is mounted rw into a conventional location inside the VM. I inject only credentials to e.g. test environments that don't matter if they're exposed. The agent context instructs it that it can use full sudo and install any utilities from apt that it needs. So for the ux I do incus-dev-vm.sh shell <projname> or incus-dev-vm.sh opencode <projname> etc. A fun thing about this is I used nested virt to have the agent write the script - so I spooled up an incus VM myself first, then the agent can run with full privs inside there creating nested VMs to ensure its functionality. Right now I'm not filtering anything on the VM - with my threat model only limited access is granted and I don't give creds to touch real infra. But you should be able to filter it on the host (I haven't researched the best approach however). |
|