# Prove a build can reach www.google.com on Yeeted

One Dockerfile, one fetch, one question: **can this deployment's build reach
an external website?** The build itself is the test - `probe.py` runs during
`docker build`, fetches `https://www.google.com`, and the build fails if the
fetch cannot leave. A deployment that succeeds has already proven the route
before the app ever starts.

This is the allowed half of the egress pair. Its sibling,
[egress-denied](egress-denied.md), proves a **running app** cannot
reach the same site without a declaration. Together they check both sides of
the platform's network promise: declared external access can work, and the
default is no external network.

## What it does

- `yeeted.yaml` carries a `network_access` section declaring exactly one
  destination: `www.google.com` over HTTPS on port 443. The platform validates
  the declaration at deploy and records an access request for the project's
  owner. The declaration cannot approve itself; an active Admin reviews and
  approves it, and the approved grant cannot exceed what is declared here.
- `probe.py` (build time) fetches the target once and writes
  `build_egress.json`. Any HTTP answer, including a 30x redirect or a 429,
  counts as success: the test is reachability, not Google's application
  response. A DNS failure, timeout, or refused connection fails the build.
- `server.py` (runtime) serves the record at `/egress` and
  `/egress/build`, plus a live runtime attempt at the same target. The
  runtime half is informational - see the sibling example for why runtime
  egress is expected to be denied.

## The network_access section

The declaration follows the platform's `yeeted.yaml` network access spec:

```yaml
network_access:
  justification: "..."
  use_case: "..."
  requested_until: "2027-06-30T00:00:00Z"
  destinations:
    - domain: www.google.com
      protocol: https
      ports: [443]
      profile: opaque_endpoint
  expected_usage:
    business_requests_per_day: 100
    bytes_per_day: 10000000
```

Rules worth knowing, all enforced at deploy:

- `destinations` must be exact DNS names - no IP literals, wildcards, or
  URL paths. HTTPS destinations must use port 443. Use the `opaque_endpoint`
  profile with HTTPS; `parsed_http` is for plain HTTP.
- `requested_until` must be in the future and at most 366 days out. Update
  this file's date before it passes; an expired declaration is preserved but
  creates no new access request.
- `expected_usage` needs at least one positive daily figure. These are
  estimates for review, not hard limits.

## Run locally

From `python/egress-allowed`:

```sh
docker build -t egress-allowed . && docker run -p 8080:8080 egress-allowed
```

Open `http://localhost:8080/egress`. Your laptop has internet, so the build
probe succeeds - locally the example mostly proves the plumbing works.

## Deploy and verify

Follow the [deployment walkthrough](getting-started.md). Deploy this
folder. The build runs the probe; a failed fetch fails the build with the
probe's error in the build log.

```sh
sh smoke.sh "$PREVIEW_URL"
```

The script checks the served record: the build-phase fetch succeeded and the
target is `https://www.google.com`.

## Endpoints

- `GET /healthz` - `ok`
- `GET /egress` - build record, plus a live runtime attempt (informational)
- `GET /egress/build` - the build-time record the smoke script asserts on

## Caveats

- Which networks a build may reach is platform policy, not something this
  manifest controls. If the platform later restricts build egress to declared
  endpoints only, the `network_access` section here is what keeps this
  example building - after an Admin approves the request it records.
- The runtime attempt reported at `/egress` is expected to fail on today's
  platform (runtime egress is default-deny). That is not a defect of this
  example; it is what [egress-denied](egress-denied.md) asserts on
  purpose.
- The probe fetches once per build and the usage figures are deliberately
  tiny. This example is a network probe, not a scraping template.