Platform Engineering on Kubernetes for Government Programs: Self-Service Without Losing the Boundary

Most program teams don’t want Kubernetes. They want a place to run their software that is secure, repeatable and there when they need it. Kubernetes is often the best way to provide that, but only when someone has done the work of turning a powerful, complicated system into a platform that application teams can use without becoming cluster experts.

That work is platform engineering. In enterprise commercial software it’s now a standard discipline, because the alternative, every team building and patching its own infrastructure, doesn’t scale. At Thazen, we bring that discipline to federal and DoW programs, and we still do it for commercial customers today. The practices carry over well. What changes is the environment around them.

Treat the Platform as a Product

A platform has users: the engineers who deploy onto it. At Thazen, we design it the way we’d design any product for them. That means a small number of well-supported paths rather than unlimited options: a standard way to build a service, deploy it, expose it, give it secrets and see its logs and metrics.

The goal is developer self-service. A team should be able to request an environment, deploy a service or roll back a change through a reviewed pull request, not a ticket that waits in a queue. Self-service doesn’t mean anything goes. It means the guardrails are built into the paths, so the easy way and the approved way are the same way.

Everything as Code, Everything Reviewable

On a government program, an environment someone built by hand is an environment nobody can fully explain. We define clusters, networking, identity and policy in infrastructure as code, typically Terraform, and manage what runs on the clusters through GitOps.

With GitOps, the Git repository is the source of truth. A change to the platform or to an application’s deployment is a pull request. A person reviews it, the pipeline checks it, and a controller inside the cluster applies it. If the running state drifts from what’s in Git, the controller pulls it back or flags it. That gives a program work you can review: every change to the environment has a diff, an approver and a history, and the trail assessors ask for is produced as a by-product of the work.

The Loop Applies to Infrastructure Too

At Thazen, every piece of work runs through the same four steps, and platform work is no exception.

• Plan. Write down the change: which clusters, which modules, what should be different afterward. Nothing proceeds until a person approves it.
• Act. Make the change in code, in an isolated branch, and preview it, for example with a Terraform plan, before anything touches a live environment.
• Observe. Apply it to a non-production environment first, then watch the health checks, logs and metrics inside the program’s boundary.
• Evaluate. Compare the result against what the plan said should happen, then a person reviews and promotes the change.

The loop is what makes speed safe. An environment that can be rebuilt from code can also be changed with confidence, because each change is small, previewed and reversible.

Multi-Cluster by Design

Many government programs don’t fit in one cluster. Shared services need to stay up for months, while exercise-, tenant- or test-specific environments need to appear and disappear on demand. Designing for that from the start is far easier than splitting a single cluster later.

On the U.S. Army’s Next Generation Constructive (NGC) program, where Thazen’s program-embedded engineers work as a subcontractor via General Dynamics Mission Systems, the platform runs on ECMA / cArmy on AWS and follows that pattern on Amazon EKS: a long-lived cluster for shared simulation services, plus clusters provisioned for each training event. Terraform and GitOps let new simulation environments come online in minutes, and the team supports live exercise execution when it matters most.

Secure Traffic Between Services and Clusters

Once services run across several clusters, the network can’t be the only line of defense. A service mesh gives each workload a cryptographic identity and encrypts traffic between workloads with mutual TLS, so services authenticate each other rather than trusting whatever happens to share the network.

On NGC, a service mesh with SPIFFE-based workload identity and mutual TLS secures traffic between clusters. The same approach applies on any program where services from several teams or vendors need to talk to each other: identity and policy are declared in code, reviewed like code, and enforced by the platform rather than by convention.

Built for Government-Controlled Environments

Commercial platform teams usually own their cloud accounts, their network and their release calendar. On federal and DoW programs, that is often not true. A program may run across AWS, AWS GovCloud (US), Azure and on-premises environments, with its own accreditation requirements, approved images and release windows.

We design for that rather than around it. Platforms are built to run on EKS, AKS or OpenShift, so the same patterns hold when the hosting changes. Container images come from approved sources and are scanned in the pipeline. Deployments go through the program’s own process, and infrastructure code makes the differences between environments visible instead of surprising. On the Synthetic Training Environment (STE), our engineers supported an OpenShift migration and added Kafka metrics and Grafana dashboards that made system readiness visible to the program team.

Observability and Reliability From Day One

A platform nobody can see into is a platform nobody can trust. Logging, metrics, tracing and alerting go in with the first cluster, not after the first incident. Service-level objectives give teams a shared definition of healthy, and runbooks answer the questions the on-call engineer will ask at the worst possible moment.

Delivery pipelines are part of the platform too. In the U.S. Army’s PCTE Development Factory, our engineers helped build an automated path from commit to release, with release management built into the pipeline rather than added at the end.

Embedded, Under the Program’s Rules

Most of our federal and DoW platform work happens as a subcontractor, with our engineers embedded inside a prime contractor’s program team. That means starting with the program’s backlog, cadence and security rules, not a parallel process of our own. We introduce platform practices by example, in the part of the system we’re responsible for, and leave infrastructure code, documentation and runbooks behind so the platform outlasts the engagement.

AI fits here as well. When engineers use AI coding agents on infrastructure code, the same rules apply as for application code: the change comes back as a pull request, the plan is previewed, and a person reviews it before anything is applied.

How Thazen Can Help

At Thazen, we build Kubernetes platforms that give program teams self-service environments without giving up control: infrastructure as code, GitOps, service mesh security, multi-cluster design and observability from day one, all running inside the environments the program controls. Our senior engineers work embedded in program teams, alongside primes on federal and DoW programs, and bring the Plan, Act, Observe, Evaluate loop with them. If your program needs environments that come online quickly and hold up under review, we’d be glad to talk about where to start.

More from Thazen Insights: Streaming Data for Government Analytics: From Sensors and Systems to a Governed Lakehouse