01 / Network
No inbound listener from Gondola. You define the egress, subnets, and security groups.
Security
Security model / implemented controls
Your AWS account is the execution boundary.
Gondola’s controllers and runners operate in your AWS account. Its controls cover IAM, networking, runner isolation and release verification.
GitHub
Queue + JIT token
Your AWS account
Gondola controller
Your VPC
One-job EC2 runner
02 / Identity
The setup page never receives your GitHub App key or AWS credentials; the key goes directly into your Secrets Manager.
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 your account. There are no product analytics in the controller.
What Gondola stores
- A short-lived leader lease, deployment generation, and readiness bit in customer DynamoDB.
- Estimated launch reservations in a separate customer DynamoDB ledger when daily allowances are enabled.
- EC2 tags needed to identify, expire, and reconcile Gondola runners.
- Configuration in the customer-managed ECS task definition and infrastructure state.
What it does not need
- A Gondola-hosted proxy for jobs, logs, or source code.
- A vendor-side GitHub App key store or customer AWS credentials.
- 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
What Gondola handles. What you configure.
| 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 or OpenTofu plan, IAM policies, runner image, and network path against your own requirements.
Review public verification evidencePrivate 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 reportsupport@gondola.build
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 target acknowledgement within one business day during published support coverage, then coordinate validation and disclosure. This is not a resolution guarantee, bug bounty, service-level agreement, or audited compliance program.