How are secrets handled in Vertro?

Vertro avoids storing long-lived cloud credentials in repositories. Application secrets are handled through Google Secret Manager and runtime identity controls.

How does Vertro support auditability?

Vertro creates a traceable path using pull requests, generated configuration, workflow logs, status updates, and deployment history.

Security overview

Security & guardrails

Q: How does Vertro reduce security drift?

Vertro keeps platform configuration in Git and applies controls through standardized templates, pull requests, Config Sync, branch protection, and governed delivery workflows.

Vertro standardizes security controls for GKE application onboarding and delivery. Identity, IAM, CI/CD controls, policy enforcement, and auditability are built into the platform path instead of being added after deployment.

Primary platformGoogle Cloud and GKE

Core controlWorkload Identity and least-privilege IAM

Operating modelGit-based review, execution, and audit trail

Security pain points

Many platform teams do not lack tools. They lack a consistent path that applies security controls every time a new application is created.

Long-lived credentials

Service account keys and static secrets increase operational risk when they are copied into repositories, pipelines, or local workflows.

Inconsistent IAM

Runtime access and developer access often vary by team, environment, or ticket history.

Security added late

Controls such as scanning, approvals, IAM review, and secret handling are often added after the deployment path already exists.

Policy drift

Namespaces, quotas, labels, RBAC, and delivery rules can drift when every service is onboarded manually.

Weak audit trail

Manual changes make it hard to prove who requested, reviewed, approved, provisioned, and deployed an application.

Platform bottlenecks

Security teams and platform teams become repeated approval gates because the default path is not trusted.

Business outcomes

Vertro is designed to reduce risk without slowing delivery. The goal is a secure path that development teams can use repeatedly and platform teams can trust.

Outcome	What changes	Business value
Reduced credential risk	Workloads use Workload Identity instead of long-lived service account keys.	Lower exposure from leaked keys and less manual rotation work.
Consistent access model	Runtime IAM and developer IAM are captured during onboarding and applied through Terraform.	Access becomes easier to review, repeat, and govern.
Faster security reviews	New services follow a known path with predefined controls and generated artifacts.	Security review becomes validation of a standard pattern, not a one-off design exercise.
Lower change risk	Configuration changes pass through Git review, branch protection, and controlled execution workflows.	Teams reduce untracked changes and operational surprises.
Better audit readiness	Requests, PRs, workflow runs, generated files, and deployment events create a traceable record.	Compliance and incident review become easier to support.

Identity model

Vertro uses Workload Identity to connect Kubernetes service accounts to Google service accounts. This gives workloads access to Google Cloud APIs without distributing long-lived keys.

The default pattern is keyless runtime access: Kubernetes service account → Workload Identity binding → Google service account.

Runtime identity is defined

The application request captures the Google service account name and Kubernetes service account name.

Terraform creates the binding

The executor provisions the Google service account and the Workload Identity IAM binding.

Kubernetes is annotated

The Kubernetes service account receives the annotation that points to the runtime Google service account.

Application runs keyless

The workload can access approved Google Cloud resources without service account keys in code, repos, or pipelines.

IAM and least privilege

Vertro separates runtime access from developer access. Runtime roles define what the application can do. Developer roles define what humans can view or manage.

Access type	Purpose	How it is controlled
Runtime IAM	Permissions used by the running workload.	Defined in the application request and applied to the runtime service account.
Developer IAM	Human access for debugging, viewing resources, or supporting the application.	Applied to approved Google Groups with scoped roles.
Deploy identity	CI/CD permissions used by app infrastructure and app code workflows.	Bound through Workload Identity Federation and repo-scoped execution.
Platform identity	Permissions used by Vertro execution workflows.	Runs through controlled GitHub Actions and ARC runners in the platform environment.

Secure delivery controls

Delivery security is part of the generated application path. Vertro is designed to give each application a controlled baseline for build, scan, promote, and deploy workflows.

Branch protection

Main branches can be protected so application and infrastructure changes follow review rules.

Security scanning

CI/CD templates can include SAST, dependency scanning, image scanning, and secret scanning.

Private execution

Provisioning and delivery workflows can run on ARC runners inside the shared platform GKE environment.

Promotion controls

Environment progression can follow a standard workflow from feature branches to non-prod and production.

Policy and platform guardrails

Vertro separates platform governance from application deployment. Platform-owned configuration controls the namespace, quotas, identity, labels, and delivery boundaries before workloads are deployed.

Platform configuration in Git
      ↓
Review and merge
      ↓
Config Sync reconciliation
      ↓
Namespaces + quotas + labels + RBAC
      ↓
Application delivery into governed targets

Namespace standards

Namespaces are created with consistent labels, quotas, limits, and ownership metadata.

Resource controls

Compute defaults and limits reduce noisy-neighbor issues and uncontrolled resource usage.

Deployment boundaries

Applications deploy into already-governed namespaces rather than creating their own runtime boundaries.

Git-controlled changes

Platform changes remain visible, reviewable, and reversible through pull requests.

Audit and traceability

Vertro creates an audit path from the original application request to the generated files, platform PRs, provisioning workflow, and deployment state.

Audit source	What it captures	Why it matters
Application config	The submitted application, environment, IAM, compute, dependency, and ownership details.	Creates a durable source of truth for what was requested.
Pull requests	Generated platform changes and review history.	Shows what changed, who reviewed it, and when it was merged.
Workflow logs	Terraform, Kubernetes, repository setup, runner setup, and notification outcomes.	Provides execution-level visibility for troubleshooting and compliance review.
Cloud Logging	Structured logs from platform services and execution workflows.	Supports centralized search, retention, and operational investigation.

Frequently asked questions

How does Vertro secure application access to Google Cloud?

Vertro uses Workload Identity to map Kubernetes service accounts to Google service accounts. This avoids long-lived service account keys and keeps runtime access controlled through IAM.

Why use Workload Identity instead of service account keys?

Service account keys are long-lived credentials that can be copied, leaked, or forgotten. Workload Identity allows workloads to authenticate to Google Cloud without storing keys in repositories, pipelines, or containers.

Does Vertro use least-privilege IAM?

Yes. Runtime and developer roles are captured during onboarding and applied through Terraform. This makes access repeatable, reviewable, and easier to govern.

How does Vertro reduce security drift?

Vertro uses Git-based configuration, pull requests, generated artifacts, Config Sync, branch protection, and controlled execution workflows to keep standards consistent.

Does Vertro support private GKE environments?

Yes. Vertro is designed around controlled GKE delivery patterns, including private application environments and platform-managed namespaces.

How are secrets handled?

Vertro avoids storing cloud credentials in repositories. Application secrets can be created in Google Secret Manager and accessed by workloads through runtime identity.

Can security approvals be added?

Yes. The workflow can include pull request review, branch protection, environment approvals, and platform-admin approval steps depending on the client governance model.

How does Vertro support audit readiness?

Each onboarding request produces generated configuration, pull requests, workflow logs, and deployment records that can be reviewed later for compliance or incident investigation.

Does Vertro replace security tools?

No. Vertro provides the secure platform path. It can integrate with existing scanning, GitHub, GCP, policy, and logging tools already used by the organization.

Is this only for production workloads?

No. Vertro applies controls across environments, including non-prod, production, and optional ephemeral environments.