01 / Network
No inbound listener from Gondola. Customer-defined egress, subnets, and security groups.
Product stationBoundary record / 01
Security model / implemented controls
The customer account is the execution boundary.
Gondola keeps the execution path in infrastructure you own. This page describes implemented controls and product boundaries; it is not a certification or audit report.
GitHub
Queue + JIT token
Customer AWS
Gondola controller
Customer VPC
One-job EC2 runner
02 / Identity
GitHub App credentials in customer Secrets Manager; AWS workload permissions on customer IAM roles.
03 / Isolation
One ephemeral EC2 runner per job, IMDSv2 required, encrypted root volumes, hard expiry timer.
04 / Supply chain
Digest-pinned OCI images, signed release checksums, provenance, SBOMs, and third-party notices.
05 / Availability
Two controller tasks across Availability Zones, with a revision-fenced DynamoDB lease and independent runner expiry.
06 / Telemetry
Operational CloudWatch metrics are optional and stay in the customer account. No product analytics in the controller.
What Gondola stores
- A short-lived leader lease, deployment generation, and readiness bit in customer DynamoDB.
- EC2 tags needed to identify, expire, and reconcile Gondola runners.
- Configuration in the customer-managed ECS task definition and Terraform state.
What it does not need
- A Gondola-hosted proxy for jobs, logs, or source code.
- Inbound access to the controller or runner security groups.
- Long-lived GitHub registration tokens on runner instances.
- A billing callback in the execution path.
Responsibility map
Product guardrails still need customer policy.
| Area | Gondola control | Customer decision |
|---|---|---|
| IAM | Launch and terminate scope constrained to configured fleet resources | Runner role permissions and GitHub OIDC trust |
| Network | No inbound rules; fleet-specific attachment supported | Egress, DNS, proxy/firewall, and allowed destinations |
| Images | Digest enforcement and exact launch-template versions | Image approval, signature verification, patch cadence |
| Workloads | One-job instance and hard expiry | Repository access, trigger safety, runner-group policy |
| Observability | Secret-aware structured logging; optional bounded metrics | Retention, alert routing, log access, incident response |
Important workload boundary
A runner job controls its disposable host.
Root EBS volumes are encrypted and deleted on termination. IMDSv2 is required, instance metadata tags are disabled, and the runner container starts as its image’s non-root runner user.
Docker-based Actions require the Docker socket. A job can therefore control containers and should be treated as fully trusted inside that EC2 instance. Do not expose a privileged fleet to fork-originated pull requests or mix untrusted tests with release credentials.
Current assurance scope
Gondola does not currently claim audited compliance or an independent penetration-test attestation. Begin with a non-critical workload and review the Terraform plan, IAM policies, runner image, and network path against your own requirements.
Private reporting / SEC-01
Found a vulnerability?
Send a private report. Do not open a public issue or include secrets, customer data, or working exploit details in a public channel.
Email a private reportgreg.gordon.tucker@gmail.com
Include if safely available
- Affected version and image digest
- Component and configuration boundary
- Impact and realistic attack conditions
- Minimal reproduction without live secrets
- Whether the issue is already public
- A safe way to coordinate follow-up
We will confirm receipt and coordinate validation and disclosure as soon as practicable. No bug bounty, guaranteed response time, or audited compliance program is currently offered.