Security & Platform Guardrails
Vertro standardizes security controls for Google Cloud application onboarding, infrastructure provisioning, and secure application delivery. Identity, IAM, CI/CD controls, policy enforcement, and auditability are built into the platform from day one.
Security and DevSecOps pain points
Most engineering teams already have security tools. The problem is that those controls are often applied inconsistently, too late, or through manual reviews that slow delivery.
Long-lived credentials
Service account keys and static credentials create risk when they are stored in repositories, CI/CD platforms, containers, or local developer environments.
Inconsistent access controls
Runtime access, developer permissions, and deployment privileges often vary across teams, Applications, and Environments.
Security added too late
Secret scanning, SAST, dependency checks, infrastructure scanning, and image scanning are often added after the delivery path has already been created.
Untrusted software supply chain
Teams may build and promote container images without consistent vulnerability scanning, SBOM generation, immutable digest promotion, or deployment enforcement.
Policy and configuration drift
Namespaces, quotas, labels, RBAC, admission policies, and delivery controls drift when every Application is onboarded manually.
Weak auditability
Manual changes make it difficult to trace who requested, reviewed, approved, provisioned, promoted, and deployed an Application.
Repeated security reviews
Security and platform teams repeatedly review the same architecture, IAM, pipeline, and deployment decisions because there is no trusted default path.
Delivery bottlenecks
Developers wait for tickets, approvals, and platform changes because security controls are separate from the onboarding and delivery workflow.
Business outcomes
Vertro turns security controls into reusable platform patterns. Development teams gain a faster delivery path, while platform and security teams gain consistency, enforcement, and traceability.
| Outcome | What changes | Business value |
|---|---|---|
| Reduced credential risk | Applications and CI/CD workflows use Workload Identity Federation instead of long-lived Google Cloud service account keys. | Lower exposure from leaked credentials and less operational effort managing and rotating keys. |
| Consistent least-privilege access | Runtime, developer, deployment, and platform permissions are defined through reusable IAM patterns and controlled infrastructure workflows. | Access becomes easier to review, apply consistently, govern, and revoke across Applications and Environments. |
| Security built into delivery | Secret scanning, SAST, dependency scanning, infrastructure-as-code scanning, and container image scanning are built into standardized CI/CD workflows. | Security issues are identified earlier without requiring every team to design and maintain its own DevSecOps pipeline. |
| Stronger software supply chain | Container images are scanned, documented with SBOMs, promoted using immutable digests, and governed through Binary Authorization. | Teams gain greater confidence that only approved and evaluated artifacts reach controlled Environments. |
| Faster security reviews | New Applications follow established Golden Paths with predefined controls, generated configuration, and standardized approval workflows. | Security review becomes validation of a trusted pattern instead of a new architecture exercise for every Application. |
| Reduced policy drift | Platform policies, namespace controls, and admission requirements are managed centrally through Git and reconciled consistently. | Teams reduce exceptions, configuration drift, and repeated manual remediation. |
| Lower change risk | Infrastructure, platform, and delivery changes pass through pull requests, branch protection, approvals, and controlled execution workflows. | Teams reduce untracked changes, failed deployments, and operational surprises. |
| Better audit readiness | Application requests, pull requests, approvals, workflow runs, generated artifacts, and deployment events create a traceable record. | Compliance reviews, incident investigations, and internal audits become easier to support. |
Identity model
Vertro uses Workload Identity Federation to give Applications and CI/CD workflows access to Google Cloud without relying on long-lived service account keys.
Application identity is defined
The Application request defines the Kubernetes service account, target Environment, and Google Cloud permissions required by the workload.
Runtime permissions are provisioned
Terraform grants the Kubernetes service account only the Google Cloud IAM roles required by that Application.
CI/CD trust is established separately
GitHub Actions authenticates through external Workload Identity Federation using repository-scoped and workflow-scoped trust conditions.
Applications and workflows access Google Cloud without stored keys
Runtime workloads and CI/CD workflows receive short-lived credentials without storing Google Cloud service account keys in repositories, pipelines, containers, or local environments.
IAM and least-privilege access
Vertro separates runtime, developer, deployment, and platform access so each identity receives only the permissions required for its role and Environment.
| Access type | Purpose | How it is controlled |
|---|---|---|
| Runtime identity | Google Cloud permissions used by a running Application. | Assigned directly to the Application's Kubernetes service account through GKE Workload Identity Federation and scoped IAM roles. |
| Developer access | Human access for troubleshooting, viewing resources, logs, or supporting an Application. | Granted through approved Google Groups using predefined and Environment-specific IAM roles. |
| CI/CD identity | Permissions required by infrastructure provisioning, build, promotion, and delivery workflows. | Authenticated through external Workload Identity Federation with repository, branch, workflow, and Environment restrictions. |
| Platform execution identity | Permissions required by Vertro provisioning and platform automation workflows. | Executed through controlled GitHub Actions workflows and private ARC runners with scoped platform permissions. |
| Administrative access | Elevated access required for platform administration, policy management, and exceptional operations. | Restricted to approved platform administrators and handled separately from routine Application delivery. |
Secure Application delivery
Vertro builds DevSecOps and software supply chain controls into the standard Application path. Security checks, approvals, artifact controls, and deployment policies are applied through reusable workflows rather than added manually by each team.
Protected source changes
Branch protection, required reviews, status checks, and controlled merge rules help ensure that Application and infrastructure changes are reviewed before execution.
Secret scanning
Repository and pipeline checks help identify credentials, tokens, and sensitive values before they are merged or included in build artifacts.
Static application security testing
SAST checks identify common security weaknesses in Application code as part of the standard CI workflow.
Dependency and software composition analysis
Application dependencies are checked for known vulnerabilities and supply chain risk before release.
Infrastructure-as-code scanning
Terraform and other infrastructure definitions are evaluated for insecure configuration, policy violations, and cloud security risks before provisioning.
Container image scanning
Container images are scanned for vulnerabilities during the build and registry workflow before promotion to controlled Environments.
SBOM generation
Software bills of materials can be generated to document the packages and components included in released container images.
Immutable artifact promotion
The same evaluated container image is promoted across Environments using immutable image digests rather than rebuilt independently for each stage.
Binary Authorization
Deployment policy can help ensure that only approved container images satisfying defined requirements are admitted to protected GKE Environments.
Controlled Environment promotion
Promotion from development to non-production and production follows standardized approval, validation, and deployment workflows.
Private workflow execution
Provisioning and delivery workflows can run on private ARC runners inside the Platform GKE environment, reducing reliance on public shared runners.
Documented exceptions
Security exceptions can be time-bound, approved, recorded, and reviewed instead of becoming undocumented permanent bypasses.
Policy enforcement and platform guardrails
Vertro separates platform governance from Application deployment. Platform-owned configuration establishes namespaces, quotas, identity boundaries, admission policies, and delivery controls before Applications are deployed.
Platform policies and configuration in Git
↓
Pull request review and approval
↓
Config Sync reconciliation
↓
Policy Controller admission checks
↓
Governed namespaces and deployment targets
↓
Application delivery through approved patternsNamespace standards
Namespaces are created with consistent labels, ownership metadata, quotas, RBAC, and Environment-specific configuration.
Resource controls
Resource requests, limits, quotas, and workload constraints help reduce noisy-neighbor risk, uncontrolled consumption, and unstable deployments.
Pod security controls
Pod Security Standards and admission policies can restrict privileged workloads, unsafe container settings, host access, and other high-risk deployment patterns.
Policy Controller enforcement
Policy Controller and Gatekeeper evaluate Kubernetes resources against centrally managed policies before they are admitted to the cluster.
Deployment boundaries
Applications deploy into governed namespaces and approved Environments rather than creating unrestricted runtime boundaries.
Required platform metadata
Policies can require ownership, Application ID, Environment, cost allocation, and operational metadata on namespaces and workloads.
Git-controlled policy changes
Platform policies remain versioned, reviewable, auditable, and reversible through pull requests and Config Sync reconciliation.
Controlled exceptions
Policy exceptions can be documented, approved, scoped, and time-bound instead of becoming permanent undocumented bypasses.
Auditability and traceability
Vertro creates a traceable path from the original Application request through generated configuration, approvals, infrastructure provisioning, security checks, promotion, and deployment.
| Audit source | What it captures | Why it matters |
|---|---|---|
| Application request | Application identity, ownership, Environment, infrastructure, IAM, dependencies, compute requirements, and selected platform capabilities. | Creates a durable record of what was requested and who owns the resulting Application. |
| Generated configuration | Terraform inputs, platform configuration, namespace definitions, IAM requirements, and delivery workflow artifacts. | Shows how the original request was translated into deployable platform configuration. |
| Pull requests and approvals | Proposed changes, reviewers, approval decisions, comments, and merge history. | Provides evidence of review and separation of duties before infrastructure or platform changes are applied. |
| CI/CD and security checks | Build results, test outcomes, secret scanning, SAST, dependency checks, IaC scanning, image scanning, and policy validation. | Demonstrates which controls were executed and whether the artifact satisfied the required delivery checks. |
| Provisioning workflow logs | Terraform execution, repository setup, identity configuration, runner setup, Kubernetes configuration, and workflow outcomes. | Provides execution-level evidence for troubleshooting, operational review, and compliance support. |
| Artifact and promotion records | Container image digest, vulnerability status, SBOM, approval state, and promotion history across Environments. | Helps trace exactly which evaluated artifact was promoted and deployed. |
| GitOps deployment history | Desired-state changes, Argo CD reconciliation, deployment status, drift, and rollback history. | Connects approved Git changes to the resulting state in each Application Environment. |
| Google Cloud audit logs | Administrative activity, IAM changes, resource operations, and relevant data-access events. | Supports centralized investigation, retention, security monitoring, and compliance review. |
| Policy violations and exceptions | Admission denials, policy findings, approved exceptions, owners, scope, and expiration details. | Makes governance decisions and deviations visible instead of leaving them undocumented. |
Frequently asked questions
How does Vertro secure Application access to Google Cloud?
Vertro uses GKE Workload Identity Federation so the Kubernetes service account can act as the Google Cloud IAM principal. This avoids long-lived service account keys and keeps runtime access controlled through scoped IAM roles.
How do GitHub Actions workflows authenticate to Google Cloud?
GitHub Actions uses a separate external Workload Identity Federation trust. Access can be restricted by repository, branch, workflow, and Environment so CI/CD workflows receive short-lived credentials without storing Google Cloud service account keys.
Does Vertro use least-privilege IAM?
Yes. Runtime, developer, deployment, platform, and administrative access are separated and provisioned through reusable IAM patterns and controlled Terraform workflows.
What DevSecOps controls can Vertro include?
Vertro can include secret scanning, SAST, dependency and software composition analysis, infrastructure-as-code scanning, container image scanning, SBOM generation, immutable image promotion, and Binary Authorization.
How does Vertro help ensure only approved images reach production?
Container images can be scanned, identified by immutable digest, promoted through controlled workflows, and evaluated by Binary Authorization before deployment to protected GKE Environments.
How does Vertro reduce security and policy drift?
Vertro manages platform configuration and policies through Git, pull requests, Config Sync, and standardized workflows. Policy Controller and Gatekeeper can enforce admission requirements before Kubernetes resources are accepted by the cluster.
Does Vertro support Pod Security Standards and admission policies?
Yes. Vertro can apply Pod Security Standards and additional admission policies for privileged workloads, unsafe container settings, required metadata, resource controls, and other platform requirements.
Does Vertro support private GKE Environments?
Yes. Vertro is designed for controlled GKE delivery patterns, including private clusters, private workflow execution, governed namespaces, and approved ingress and networking models.
How are Application secrets handled?
Application secrets are stored in Google Secret Manager rather than in source repositories or container images. Workloads access approved secrets through their runtime identity and the configured secret delivery pattern.
Can security approvals be added to delivery workflows?
Yes. Workflows can include pull request reviews, branch protection, required status checks, Environment approvals, promotion controls, and platform-administrator approval steps based on the organization’s governance model.
How does Vertro support audit readiness?
Application requests, generated configuration, pull requests, approvals, security checks, workflow logs, artifact metadata, policy findings, promotion history, and deployment records create a traceable delivery path.
Does Vertro replace existing security tools?
No. Vertro provides the standardized security and delivery path. It can use or integrate with the organization’s existing GitHub, Google Cloud, scanning, policy, logging, and security platforms.
Are security controls applied only to production?
No. Controls can be applied across development, non-production, production, and optional ephemeral Environments. The required checks and approval levels can vary by Environment.
Can policy or security exceptions be supported?
Yes. Exceptions can be scoped, documented, approved, assigned to an owner, and given an expiration date rather than becoming permanent undocumented bypasses.