DevSecOps & Cloud Security for GCP
I help engineering teams design secure GCP platforms by embedding security directly into the architecture, infrastructure, and delivery pipelines — not adding it as a layer afterwards. My focus is security by default: IAM models that enforce least-privilege from day one, CI/CD pipelines with security gates built in, Terraform infrastructure with compliance controls codified, and GKE clusters hardened before workloads are deployed. I’m Amit Malhotra, a Principal GCP Architect based in Toronto with 20+ years in IT and 6+ years hands-on with GCP security architecture, Workload Identity Federation, Zero Trust network design, and DevSecOps pipeline implementation. I’ve built security-first GCP platforms at regulated enterprises including RBC, Tangerine Bank, and Telus Health — environments where security gaps have real compliance and regulatory consequences.
Security work on GCP is one of the areas where the SCALE Framework has the most impact — the Security by Design pillar ensures that every platform decision, from IAM model to network segmentation to CI/CD pipeline design, is made with security as a first-class requirement rather than a post-build concern.
The Problem Most Teams Face
Why Cloud Security Becomes a Problem — and Why It Stays One
Most GCP environments don’t have a security problem — they have a security debt problem. Security controls that weren’t designed in from the start accumulate over time into a posture that’s fragile, inconsistent, and expensive to fix. I’m typically brought in when one or more of these patterns has taken hold:
- IAM has grown organically without a clear model — permissions granted when people needed them, service accounts created for convenience, and project-level bindings that nobody fully understands anymore. The result is an IAM model that over-privileges most workloads and makes it impossible to audit who can access what.
- Service account keys are widely used — long-lived credentials stored in environment variables, code repositories, CI/CD secrets, and Kubernetes ConfigMaps, creating a broad attack surface that grows with every new service and is almost impossible to rotate consistently.
- CI/CD pipelines have excessive permissions — pipelines running with service account keys that have project-level roles, no security scanning before deployment, and no policy validation gates — meaning every release is a potential vector for deploying misconfigured or vulnerable infrastructure.
- Security is reactive rather than designed in — security reviews happen before audits, not before architecture decisions. Controls are added after the fact, creating a patchwork of policies that depend on people following processes rather than the platform enforcing them.
- Policies exist but are not enforced consistently — security documentation that describes what should happen, and a platform that doesn’t guarantee it. The gap between documented policy and actual platform behaviour is where most audit findings live.
The result is a platform that works — but is fragile, hard to audit, and one misconfiguration away from a significant security incident.
What I Typically Work On
The DevSecOps and GCP Security Work I Do
Zero Trust Identity Models on GCP: I design GCP identity architectures that assume no implicit trust between services, users, or environments — every request authenticated, every permission scoped to the minimum required, and every service communicating through explicitly defined identity channels. Workload Identity Federation for all service-to-service authentication, Access Context Manager for context-aware human access, and organisation-level IAM policies that enforce the model consistently.
Least-Privilege IAM Implementation: I restructure overgrown IAM models into clean, least-privilege designs — auditing existing bindings, removing excess permissions, scoping service accounts to individual workloads rather than projects, and implementing IAM conditions that restrict access by resource, time, or context. The output is an IAM model you can explain to an auditor and that won’t silently expand as the team grows.
Workload Identity Federation: I replace all static service account keys with Workload Identity Federation — for GKE workloads, GitHub Actions CI/CD pipelines, Cloud Build, and any external workload authenticating to GCP. No more credential rotation, no more keys in code repositories, and no more long-lived secrets that create breach exposure. This is the single highest-impact security improvement most GCP environments can make.
Secure CI/CD Pipeline Design: I redesign CI/CD pipelines to embed security at every stage — SAST and container image vulnerability scanning before build, Binary Authorization policy enforcement before deployment, Workload Identity Federation replacing service account keys, OPA/Gatekeeper policy validation before Terraform apply, and deployment gates that require security checks to pass before anything reaches production.
Network Security and Segmentation: I design GCP network security architectures that enforce data flow boundaries at the infrastructure layer — VPC Service Controls to prevent data exfiltration, Private Google Access to eliminate public internet exposure for GCP API calls, firewall rules based on service identity rather than IP addresses, and network policies in GKE enforcing namespace-level isolation.
Policy-as-Code Implementation: I implement Policy-as-Code using OPA/Gatekeeper for Kubernetes admission control, Terraform Sentinel or OPA for infrastructure policy validation, and GCP Organisation Policies for guardrails at the project and folder level — so security controls are enforced automatically on every deployment rather than depending on manual review.
Security by Design
The DevSecOps and GCP Security Work I Do
Zero Trust Identity Models on GCP: I design GCP identity architectures that assume no implicit trust between services, users, or environments — every request authenticated, every permission scoped to the minimum required, and every service communicating through explicitly defined identity channels. Workload Identity Federation for all service-to-service authentication, Access Context Manager for context-aware human access, and organisation-level IAM policies that enforce the model consistently.
Least-Privilege IAM Implementation: I restructure overgrown IAM models into clean, least-privilege designs — auditing existing bindings, removing excess permissions, scoping service accounts to individual workloads rather than projects, and implementing IAM conditions that restrict access by resource, time, or context. The output is an IAM model you can explain to an auditor and that won’t silently expand as the team grows.
Workload Identity Federation: I replace all static service account keys with Workload Identity Federation — for GKE workloads, GitHub Actions CI/CD pipelines, Cloud Build, and any external workload authenticating to GCP. No more credential rotation, no more keys in code repositories, and no more long-lived secrets that create breach exposure. This is the single highest-impact security improvement most GCP environments can make.
Secure CI/CD Pipeline Design: I redesign CI/CD pipelines to embed security at every stage — SAST and container image vulnerability scanning before build, Binary Authorization policy enforcement before deployment, Workload Identity Federation replacing service account keys, OPA/Gatekeeper policy validation before Terraform apply, and deployment gates that require security checks to pass before anything reaches production.
Network Security and Segmentation: I design GCP network security architectures that enforce data flow boundaries at the infrastructure layer — VPC Service Controls to prevent data exfiltration, Private Google Access to eliminate public internet exposure for GCP API calls, firewall rules based on service identity rather than IP addresses, and network policies in GKE enforcing namespace-level isolation.
Policy-as-Code Implementation: I implement Policy-as-Code using OPA/Gatekeeper for Kubernetes admission control, Terraform Sentinel or OPA for infrastructure policy validation, and GCP Organisation Policies for guardrails at the project and folder level — so security controls are enforced automatically on every deployment rather than depending on manual review.
DevSecOps in Practice
Embedding Security Into Every Stage of Delivery
DevSecOps isn’t a tool or a team — it’s the integration of security validation into the delivery pipeline so that security issues are caught before they reach production rather than discovered after. The CI/CD pipelines I build for DevSecOps clients include:
Secure GitHub Actions and Cloud Build Pipelines: Pipelines that authenticate to GCP through Workload Identity Federation — no service account keys in CI secrets — with step-level permissions scoped to the minimum required for each job. Pipeline configuration stored in version-controlled repositories with required code review before changes take effect.
Artifact Scanning and Image Signing: Container images scanned for known vulnerabilities before being pushed to Artifact Registry, signed with Cloud KMS keys, and verified through Binary Authorization policy before deployment to GKE — so only scanned, signed, approved images can run in production, regardless of how they were built.
Secrets Management — No Plaintext Secrets: Secret Manager integration in every pipeline and application — database credentials, API keys, and certificates retrieved at runtime through Workload Identity, never stored in environment variables, ConfigMaps, or CI/CD configuration. Automatic secret rotation where supported, with audit logs for every secret access.
Infrastructure Security via Terraform: Terraform configurations reviewed against security policy before apply — using OPA/Conftest or Terraform Sentinel to catch misconfigurations such as overly permissive firewall rules, publicly accessible storage buckets, or disabled audit logging before they’re deployed to any environment.
Continuous Security Validation: Ongoing security posture monitoring using GCP Security Command Center, automated policy compliance checks, and alerting on configuration drift — so the security posture you’ve designed doesn’t silently degrade as the platform evolves and new resources are added.
Typical Security Architecture
What a Secure GCP Platform Architecture Looks Like
The security architectures I design for GCP platforms typically include these foundational components — though the specific implementation varies based on your compliance requirements, team size, and existing environment:
Workload Identity for All GCP Authentication: All workloads — GKE pods, Cloud Run services, GitHub Actions pipelines, Cloud Build jobs — authenticate to GCP APIs through Workload Identity Federation. No service account key files anywhere in the environment. Short-lived tokens, automatically rotated, scoped to minimum permissions.
Private GKE Clusters: GKE clusters with private nodes — no public IP addresses on cluster nodes, all control plane access through Private Google Access or Authorised Networks, and no direct internet exposure for workloads that don’t need it. Combined with network policies between namespaces and Pod Security Standards enforcement.
Restricted Network Egress: VPC firewall rules and Cloud NAT configuration that restricts what GCP resources can reach on the internet, VPC Service Controls that prevent GCP managed services from exfiltrating data outside the defined perimeter, and Private Google Access ensuring GCP API calls never traverse the public internet.
Centralised Logging and Monitoring: Cloud Audit Logs enabled and centralised across all GCP projects — Admin Activity, Data Access, and System Event logs — with log sinks to a dedicated security logging project, retention configured for compliance requirements, and alerting on security-relevant events through Cloud Monitoring and Security Command Center.
Policy Enforcement at Deploy Time: OPA/Gatekeeper admission controllers on GKE preventing non-compliant workload deployments, Terraform policy validation in CI/CD pipelines catching infrastructure misconfigurations before apply, and GCP Organisation Policies enforcing guardrails at the resource hierarchy level — so the platform enforces your security requirements automatically.
Who This Is For
Is This the Right Engagement for Your Team?
DevSecOps and GCP security work delivers the most value when there are production workloads at risk or compliance requirements to meet. This is a good fit for:
Teams running production workloads on GCP with security debt — overgrown IAM, service account keys in use, no security gates in CI/CD. The FinTech & Regulated Systems page covers the regulated environment context in detail.
Organisations under compliance pressure — SOC 2, OSFI, PIPEDA, PCI DSS, or enterprise customer security requirements exposing gaps in the current GCP security posture that need to be addressed structurally rather than through documentation
Companies moving workloads to GCP from on-premises or legacy cloud environments — where the security model needs to be designed for cloud-native patterns from the start rather than translated from an on-prem model that won’t map cleanly
Teams replacing service account keys across their GCP environment — a complex, high-risk migration that needs to be sequenced carefully to avoid breaking production workloads. See the GCP Architecture & Modernization service for the broader modernisation context.
Engineering teams building internal platforms — where the platform security model needs to be designed in from the start so every team that uses the platform inherits a secure baseline. See the Platform Engineering service for how security integrates with platform design.
This is not the right fit for basic website hosting, single VM setups, or teams without CI/CD pipelines in place. If you’re earlier in your GCP journey, the
GCP Architecture & Modernization service is the right starting point — security architecture is embedded into every engagement I run regardless of the service.
LET’S TALK
Want Security Built Into Your GCP Platform — Not Bolted On?
Security that’s designed into the architecture is easier to maintain, easier to audit, and doesn’t slow your engineering team down. I start with a free 30-minute architecture review — an honest look at your current GCP security posture, the gaps that represent the most significant risk, and what a properly structured security architecture looks like for your environment. You work directly with me, Amit Malhotra, throughout — no account layer, no hand-offs.
Speak Directly With Amit Malhotra
Operating From
Based in Toronto (EST), working with engineering teams across Canada & USA
Ready to Architect Your Future on Google Cloud?
Speak directly with me — a Principal Cloud Architect — about your GCP architecture, security, platform engineering, or MLOps goals. I typically respond within one business day.
✓ Free 30-minute call ✓ No proposal, no pressure ✓ Responds within one business day
Get In Touch
Trusted Technical Advisor
Amit works as a true architecture partner, not just a consultant. He focuses on making the right decisions early and designing systems that remain maintainable as they scale. His guidance helped us avoid costly redesigns and establish a solid cloud foundation from the start.
- Kanishk P,
- Binoloop Inc
Architecture leadership
Amit helped us redesign our Google Cloud architecture to support rapid growth without increasing operational complexity. His ability to simplify difficult architectural decisions and design scalable platform foundations had an immediate impact on our engineering velocity and system reliability.
- Rohit Kulkarni,
- Cascade Cloud Inc.
Platform engineering & DevSecOps
We engaged Amit to build a secure and scalable platform on Google Cloud with Terraform, Cloud Run, Kong API gateway and automated CI/CD. He brought deep hands-on expertise and designed everything with long-term operability in mind. Our deployment process is now significantly more reliable and secure.
- Hema Kumar,
- Pemvish.com