Moving to a Declarative Platform Workflow #
This is a simplified, representative pattern. Details have been generalised and do not reproduce a client’s internal architecture, commercial arrangements, or implementation.
An anonymised case study in reducing platform cost without giving up secure self-service, auditability, or isolation between teams and environments.
The Problem #
An organisation used separate commercial platforms for infrastructure state and secrets. They provided useful capabilities, but the cost and operating model were no longer a good match for how the platforms were being used.
The replacement still needed to preserve:
- secure, self-service infrastructure delivery;
- strict identity boundaries around Terraform state and secrets;
- repeatable workflows across multiple cloud environments;
- auditable access and changes; and
- a migration path that teams could adopt without each designing its own solution.
Architecture: Before and After #
The important change was moving platform configuration from separately administered web tooling into a reviewed, version-controlled definition. The diagrams show the general design shift rather than the original environment.
Before #
flowchart LR
ADMIN(["🖱 Web administration
Configuration split across portals"])
GH(["◉ Git repository
Infrastructure source"])
GHA(["⚙ CI/CD workflow
Plan and apply"])
TFC(["◆ Managed state platform
Workspaces and remote state"])
HV(["🔐 Managed secrets platform
Secrets and identities"])
CLOUD(["☁ Cloud environments
Provisioned resources"])
ADMIN -->|Manual setup| TFC
ADMIN -->|Manual setup| HV
GH ==>|Push / pull request| GHA
TFC <-.->|Terraform state| GHA
HV -.->|Credentials| GHA
GHA ==>|Provision| CLOUD
classDef core fill:#e0f2fe,stroke:#0284c7,color:#0f172a,stroke-width:1.5px;
classDef service fill:#ecfdf5,stroke:#059669,color:#0f172a,stroke-width:1.5px;
class GH,GHA,CLOUD core;
class ADMIN,TFC,HV service;
State and secret-management objects were administered separately, creating multiple configuration surfaces for teams to maintain.
After #
flowchart TB
GH(["◉ Git repository
Infrastructure source"])
YAML(["▤ YAML platform definition
Environments, state, secrets and identities"])
GHA(["⚙ Reusable CI/CD
Platform workflows"])
subgraph PLATFORM["Declaratively managed platform services"]
direction LR
ID(["◌ Workload identities
Federation and RBAC"])
SA(["▣ Object storage
Isolated Terraform state"])
KV(["🔐 Managed secrets store
Secrets and access"])
end
CLOUD(["☁ Cloud environments
Provisioned resources"])
GH ==>|Push / pull request| GHA
YAML ==>|Desired platform configuration| GHA
GHA -->|Create / reconcile| ID
GHA -->|Create / reconcile| SA
GHA -->|Create / reconcile| KV
ID -.->|Federated identity| GHA
SA <-.->|Read / write state| GHA
KV -.->|Credentials| GHA
GHA ==>|Plan, apply and provision| CLOUD
classDef core fill:#e0f2fe,stroke:#0284c7,color:#0f172a,stroke-width:1.5px;
classDef service fill:#ecfdf5,stroke:#059669,color:#0f172a,stroke-width:1.5px;
class GH,YAML,GHA,CLOUD core;
class ID,SA,KV service;
The YAML definition became the source of truth for platform configuration. A reviewed change could create or update the required identity boundaries, state locations, secret access, and target-cloud resources through the same reusable workflow.
The Approach #
The replacement was a cloud-native, configuration-driven platform built around:
- version-controlled YAML definitions for environments, state, secrets, identities, and access boundaries;
- reusable CI/CD workflows for delivery and cloud authentication;
- cloud object storage for Terraform state;
- a managed secrets service for secrets; and
- workload identity and least-privilege access to isolate state and secrets.
Security and Platform Design #
Access to state and secrets was scoped to the appropriate workload, environment, and automation identity, supporting defence in depth while keeping routine use straightforward for developers.
Outcome #
The migration:
- significantly reduced recurring licensing costs;
- retained secure, auditable infrastructure and secrets workflows;
- provided application teams with reusable self-service automation; and
- established identity-based isolation for Terraform state across multi-cloud environments.