82 lines
3.3 KiB
Markdown
82 lines
3.3 KiB
Markdown
# 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`
|
|
- 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
|
|
|
|
```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.
|
|
- 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 and proved manually. Automatic Git-triggered CI/CD is not yet live because this project currently has no Cloud Build repository connection or trigger.
|
|
|
|
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.
|