Country isolation
Workloads, networks, identities, data, encryption boundaries, and telemetry need country ownership without losing central governance.
← Work
Cloud Security · Google Cloud · DevSecOps
AfyaBridge Cloud Security
A production-style cloud-security reference implementation for a fictional community-health organization operating across Kenya, Ghana, and South Africa. The project covers landing-zone design, country isolation, identity, application security, keyless Terraform delivery, software supply-chain controls, posture governance, and validation evidence.
Independent portfolio project. AfyaBridge Cloud Security uses a fictional organization and synthetic data. It does not represent the infrastructure, systems, credentials, or data of a real healthcare organization.
01 · Scenario
Security requirements
The scenario assumes community-health teams working across several countries, handling sensitive identity and health data, supporting low-connectivity field workflows, and relying on cloud systems that must remain governable as the platform grows.
Least privilege
Human and workload access should be narrow, reviewable, and separate from the authority required to grant more privilege.
Protected data
Classification, residency, encryption, secrets, retention, backup, recovery, and deletion boundaries are part of the design.
Secure delivery
GitHub-to-GCP deployment uses short-lived identity, separate plan and apply roles, reviewed saved plans, and no downloaded GCP key.
Offline workflows
Synchronization is treated as a trust boundary with actor and device binding, replay protection, idempotency, and conflict handling.
Evidence
Designed, implemented, statically validated, live validated, and negative-tested controls are kept distinct.
02 · Google Cloud foundation
Landing zone
The landing zone defines where workloads belong, how policy inherits, which services are shared, how countries remain separate, and where Terraform state and deployment identities live. The broader foundation is implemented in Terraform and statically validated; only the bootstrap and GitHub deployment-control planes are live-validated so far.
State and deployment prerequisites
Protected Terraform state, CMEK, deployment identities, and project-factory prerequisites stay outside workload projects.
Shared security and platform services
Security, logging, networking, CI/CD, artifact, and DNS capabilities are modeled as shared services rather than country workload concerns.
Country-owned production boundaries
Kenya, Ghana, and South Africa production environments are separated through hierarchy, workload projects, networks, data, and keys.
Development and staging
Non-production remains separated from production so development identities and pipelines do not inherit production capability.
Short-lived experimentation
Experimental resources are constrained by permissions, metadata, cost controls, and cleanup expectations.
Inheritance and visibility
Organization policies, naming, labels, budgets, audit routing, and asset visibility provide repeatable governance as countries are added.
03 · Architecture
Architecture overview
Central governance does not require shared runtime trust. The design keeps country workloads, data, network paths, keys, and telemetry scoped while allowing shared organizational controls and a common delivery model.
04 · Application security
Application security baseline
Infrastructure boundaries are reinforced in the application. The baseline focuses on identity, country scope, persistence constraints, auditability, concurrency, and offline synchronization behavior.
Authorization and country scope
Requests pass through explicit authorization seams and country scoping instead of relying on UI visibility as an access control.
Persistence and audit boundaries
Database constraints, audit events, optimistic concurrency, and server-authoritative decisions reinforce application rules.
Replay and conflict handling
Actor and device binding, timestamp checks, replay protection, idempotency, and explicit conflict states protect synchronization flows.
05 · Terraform delivery · v0.7I–L
Keyless Terraform delivery
GitHub OIDC and Google Workload Identity Federation replace a stored service-account key. Planning and applying are separate identities, the approved job consumes the exact saved plan, and provider permissions were measured from controlled denied operations.
Short-lived workload identity
Google WIF evaluates repository, workflow, ref, event, and environment context before the dedicated Google Cloud identity can be used.
Plan and apply identities
The plan identity reads protected state and refreshes providers. The apply identity receives write capability only on the protected path.
Production approval before apply identity
The production environment gate is crossed before the privileged apply identity is authenticated.
Saved-plan integrity and provenance
The apply job independently verifies the plan checksum plus repository, commit, ref, run, project, state-bucket, and KMS provenance.
Permissions from observed operations
The controlled provider mutation required iam.serviceAccounts.get and iam.serviceAccounts.update. The apply identity was not given authority to rewrite its own IAM grants.
Trust boundaries fail closed
Tests proved the plan workflow cannot assume the apply identity, non-main cannot enter production, and the main apply workflow is rejected by WIF when the production environment claim is absent.
06 · DevSecOps · v0.8
Shift-left security
Pull requests are evaluated by secret, dependency, license, code, Terraform, package, container, API-contract, policy, and exception controls before the repository security verdict can pass.
07 · Software supply chain · v0.9
Software supply chain
The trusted-main build path adds SBOMs, separated build and signing identities, keyless Sigstore/Cosign signing, GitHub attestations, provenance verification, revocation decisions, and negative tests.
Signing authority is not available to pull requests
Pull requests exercise unprivileged build and validation paths; trusted-main context is required for signing and provenance authority.
Artifact, SBOM, and provenance
The exact build is signed and verification is constrained to the expected repository, workflow identity, source ref, and source commit.
Current trust is an explicit decision
Artifact, source, and workflow identities are checked against a revocation policy that fails closed when reviewed trust is withdrawn.
08 · Observability and posture
Cloud posture and governance
Desired-state posture, drift decisions, finding ownership, remediation SLAs, exceptions, evidence-backed closure, logging, monitoring, and detection contracts are modeled in the repository. Live cloud posture and runtime detection exercises remain pending.
Desired-state posture
Machine-readable rules and fail-closed governance checks encode the control baseline without pretending repository state is live cloud state.
Findings and remediation
Severity, SLA, exceptions, remediation attempts, independent verification, and closure evidence are represented as governed state.
Logging and detection contracts
Centralized logging, monitoring, log-based metrics, alert policies, and responder paths are implemented but still need live exercise.
09 · Decisions
Architecture decisions
The implementation is organized around explicit trust and ownership decisions rather than a checklist of Google Cloud products.
Country boundaries are infrastructure boundaries
Country networks, workloads, data services, keys, and telemetry are scoped rather than sharing runtime trust by default.
No long-lived GCP key in GitHub
GitHub OIDC and WIF provide job-time identity instead of stored service-account credentials.
Plan is not apply
Terraform planning and applying use separate service accounts with different state and provider permissions.
The apply identity cannot administer its own grants
Permission installation remains a separately owned administrative boundary rather than a self-escalation capability.
Offline synchronization is security-sensitive
Replay, duplicate submissions, actor/device binding, timestamps, and conflict handling are treated as security concerns.
Evidence cannot exceed the test
A green CI run, static Terraform validation, and a zero-change apply are each recorded for what they actually prove and no more.
10 · Validation
Validation state
The public evidence distinguishes design, repository implementation, static validation, live cloud validation, and negative trust testing.
Threat model + landing zoneDesignedResource hierarchy, country boundaries, shared services, governance, regions, and data/security architecture are documented
Application security baselineValidatedAuthorization, scoping, persistence, audit, concurrency, and offline security controls have automated evidence
Terraform infrastructureStatic validationFoundation, network, workload, federation, observability, and edge roots initialize and validate in CI
Bootstrap control plane · v0.7HLive validatedCMEK-backed state, impersonation, measured IAM, controlled mutation, and temporary-privilege cleanup were exercised in GCP
GitHub → GCP federation · v0.7I–LLive + negative validatedOIDC/WIF, separate plan/apply identities, production approval, saved-plan provenance, state locking, real provider mutation, and fail-closed trust tests were exercised
Shift-left security · v0.8CI enforcedRepository security checks feed a fail-closed merge verdict and evidence bundle
Software supply chain · v0.9ValidatedSBOMs, signing, attestations, provenance, revocation, and negative tests are exercised on trusted main
Cloud posture · v0.10Repository validatedDesired-state and governance logic are exercised; live cloud posture and real drift remain pending
Country foundation, network, workloads, observability, edgePending live validationImplemented and statically validated, but not yet claimed as live-enforced
Current boundary
Current validation boundary
The live evidence currently covers the Terraform bootstrap and the GitHub-to-GCP deployment-control plane. Country foundations, Shared VPC enforcement, workload services, live observability, detections, public edge controls, posture collection, real drift, runtime attack simulation, rollback, and recovery still require their own evidence.
Next
- Apply and validate the country foundation and policy hierarchy
- Validate Shared VPC, private connectivity, routes, and firewall enforcement
- Deploy workload, data, KMS, secrets, and Artifact Registry controls
- Exercise logging, alerts, detections, and responder workflows
- Validate DNS, certificates, HTTPS routing, origin protection, and Cloud Armor
- Run shift-right and incident-recovery exercises
Repository
Repository and evidence
The case study is the readable overview. The repository contains the detailed threat model, landing zone, ADRs, Terraform, application baseline, workflows, runbooks, tests, posture controls, and validation records.