canonical / canonical/workshop

Feature request: declarative per-workshop network policy / egress control

Open
#927 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
108
Forks
17
Avg merge
1d 7h
Merged PRs (30d)
40

Description

Hi team,

I'm building a trust-boundary pattern for running AI coding agents against
Infrastructure-as-Code ([is-tf-plan-broker](https://github.com/canonical/is-tf-plan-broker)).
It uses two sibling Workshop projects separated by a trust boundary:

- an `untrusted` coding-agent workshop that edits Terraform code and holds
zero infrastructure credentials, and
- a `trusted plan-runner` workshop that holds Vault/state/cloud credentials
and runs `terraform plan` on the agent's behalf.

They communicate only through a shared host file spool.

A core part of the design's is defense-in-depth, which involves restricting the agent workshop's network egress. For example, I want the untrusted workshop to be able to reach the public internet, but I don't want it to be able to reach any sensitive infrastructure (Vault, Cloud APIs, JAAS etc).

To work around this, I currently
- create an LXD network ACL with the deny/allow egress rules
- create a dedicated bridge and bind the ACL to it at the network level
- repoint the workshop's instance's NIC onto that bridge and restart it.

To make this solution reproducible and not dependent on LXD, I would prefer a way to declare network attachment and/or egress policy in the workshop definition.

E.g.
```
network:
name: my-isolated-bridge
```
or for the ACLs

```
network:
egress:
default: allow
deny:
- 10.0.0.0/8 # Internal infrastructure
- X.X.X.X/32 # a specific IP I don't want the workshop to have access to
```

I think that first-class support for network policies aligns with Workshop's goals of enabling safe, sandboxed experimentation and would help accelerate agentic engineering by making trust boundaries declarative. It's far easier to let an agent run in full auto-pilot when you can prove (from committed configuration) that it can't reach sensitive resources.

Contributor guide

Open the contributing guide

Research direction

No implementation files or tests are named in the issue. Start by tracing how workshop definitions configure instance networking and how the existing LXD bridge and ACL setup is applied. Done should be a reproducible workshop-level network attachment or egress policy that enforces the declared restrictions.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, terraform
Domain
infrastructure, networking, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.