# GCP CI/CD and Redundancy Hardening

This records the current GCP hardening contract for `teleo-501523`.

## What Is Live

- Artifact Registry Docker repositories exist in `europe-west6`:
  - `teleo`
  - `livingip-web`
- Both repositories use immutable tags and active vulnerability scanning.
- `cloudbuild.gcp-staging.yaml` builds the staging Teleo image, runs the image smoke test, then pushes to Artifact Registry.
- Cloud Build runs as the dedicated service account:
  - `sa-teleo-cloudbuild@teleo-501523.iam.gserviceaccount.com`
- The dedicated Cloud Build account has only the roles required for the current build/publish path:
  - `roles/artifactregistry.writer`
  - `roles/logging.logWriter`
  - `roles/storage.objectViewer`
- GitHub Actions can publish Artifact Registry images through Workload Identity Federation:
  - workflow: `.github/workflows/gcp-artifact.yml`
  - provider: `projects/785938879453/locations/global/workloadIdentityPools/github-actions/providers/living-ip-github`
  - service account: `sa-artifact-builder@teleo-501523.iam.gserviceaccount.com`
  - repository scope: `living-ip/teleo-infrastructure`
- Backup buckets are versioned and use uniform bucket-level access:
  - `gs://teleo-501523-prod-backups`
  - `gs://teleo-501523-leoclean-backups`
- VM boot disks have a daily 7-day snapshot policy:
  - `teleo-prod-1`
  - `teleo-staging-1`

## How To Build

Automatic Artifact Registry publishing runs on pushes to `main` through GitHub Actions. To run the same lane manually from GitHub:

```bash
gh workflow run gcp-artifact.yml --repo living-ip/teleo-infrastructure --ref main
```

The workflow authenticates to GCP with Workload Identity Federation, builds `Dockerfile.gcp-staging`, runs the image smoke test, pushes the image, and uploads `gcp-artifact-image.txt` as a run artifact.

For a local/manual Cloud Build proof:

```bash
REVISION="$(git rev-parse HEAD)"
TAG="$(git rev-parse --short=7 HEAD)-manual-$(date -u +%Y%m%d-%H%M%S)"

gcloud builds submit \
  --project=teleo-501523 \
  --config=cloudbuild.gcp-staging.yaml \
  --substitutions="_TAG=${TAG},_REVISION=${REVISION}"
```

Expected result:

- `build-staging-image` succeeds.
- `smoke-test-image-before-push` succeeds.
- A Docker image is pushed to:
  `europe-west6-docker.pkg.dev/teleo-501523/teleo/teleo-pipeline-gcp-staging:${TAG}`

## How To Check Readiness

Run from the repository root:

```bash
python3 ops/check_gcp_infra_readiness.py
```

The check is read-only and prints no secret values. It verifies:

- Artifact Registry immutability and vulnerability scanning.
- Cloud Build config contract.
- Dedicated Cloud Build service account and roles.
- GitHub Actions WIF Artifact Registry publishing contract.
- Compute disk snapshot policy attachment.
- Backup bucket versioning and uniform access.
- Whether Cloud SQL/Postgres exists.
- Whether a GCP-approved KB/Postgres access secret slot exists.

## Current Boundaries

The GCP Docker build/publish path is live through manual Cloud Build and GitHub Actions Workload Identity Federation. Native Cloud Build GitHub triggers are not configured because this project currently has no Cloud Build repository connection.

Database redundancy is not complete. The current project has backup buckets and VM disk snapshots, but it does not yet have a GCP Cloud SQL/Postgres pgvector standby or primary. Do not claim DB parity until one of these is true:

- the existing canonical KB database is replicated into GCP and read back; or
- GCP Cloud SQL/Postgres becomes the canonical database and production services read/write it; or
- an explicitly approved standby restore drill proves that a GCP database can be restored and queried from the retained backups.

Do not create an empty Cloud SQL instance and call it redundancy. It only counts after source data, restore/replication, access controls, and readback are proven.

## Communication Posture

Current GCP communication hardening is limited to the surfaces already read back:

- default SSH/RDP firewall rules are disabled;
- Teleo SSH access is scoped by instance tags and current source IP rules;
- the custom Teleo subnet has Private Google Access enabled.

Before production cutover, add a dedicated runtime communication contract for service-to-service paths, including exact source tags/service accounts, allowed ports, health checks, and rollback.