#argocd

Researchers found a flaw in Argo CD where even limited API tokens could retrieve stored repository usernames and passwords, leaving projects open to unintended exposure.

Source: Argo Project | NVD

Optimizing Delivery: A Technical Analysis of Modern Deployment Patterns

An engineering breakdown of high-frequency deployment strategies, evaluating the trade-offs between infrastructure overhead, rollback speed, and traffic-shifting mechanics in 2026 environments.

Read the full report on -

It'll soon be 2 years since I last wrote here about Platform Engineering. Time flies when you're busy working. I do think it's important, however, to take time to show off what you're working on, get feedback and help others who are trying to head in the same direction.

Two years ago I was all over Terragrunt, writing Infrastructure-as-Code for clients in a consulting job. Terragrunt as a wrapper is a real boon for Platform Engineers wanting to create homogeneous environments in Terraform without having to repeat code in the root modules.

Since this time, I've become an employee doing Platform Engineering for a single company which opens your eyes about another set of problems that I believe more people will connect with than the plight of the Platform Engineering ronin.

There is more than one platform

What I mean by that is that within companies there are often multiple products, each with their own infrastructure requirements, but Infrastructure often gets treated as a monolith of configuration that either gets deployed as a whole or not. Either that or a lamentable set of feature flags that make it difficult to see what is actually getting deployed. This is understandable as we want to have homogeneity between environments, but if a product doesn't use a piece of infrastructure we probably should not deploy it for them.

The big wait.

This monolith approach also means that Platform Engineering teams spend a lot of time writing these big configuration modules or root modules for each product launched.

DevEx survey conducted by Rafay indicates that 25% of organizations take 3 months or more to deploy new applications, 45% of respondents are unhappy with their process and 33% say it's too complicated to provision new environments.

Time to consider self-service

Developers know what their applications need, that's why we all went through the era of DevOps, having the teams that developed the software handle operating it. We cannot, however, expect them to be experts in both the application side of things and Cloud architecture and Infrastructure as Code.

Gartner reports 85% of organizations with Platform Engineering teams plan to implement some sort of Internal Developer Platform (IDP) by 2028. This is up from 60% in 2025.

Terraform Stacks

Terraform can be a key element in self-service in infrastructure procurement. We just need to adjust our tools.

On September 25th HashiCorp made Terraform Stacks generally available to its cloud customers. This is a new orchestration method for familiar Terraform code in that it separates the Terraform workspace if you will into two dimensions. On the X axis you have 1 or more deployments and on the Y axis you have 1 or more components.

Components are basically input references for Terraform Modules. On the component level also are input variables, outputs and provider configuration.

Deployments are inputs for the components. On this level you also have integrated support for OIDC tokens from HCP Terraform which you can input to your components to enable authentication in your Terraform Providers using OAuth to your cloud infrastructure. Also on the Deployment level are Stack inputs and stack outputs allowing you to chain different Stacks together connecting their output as input to other Stacks.

There are also deployment groups and auto approval rules that allow you to set conditions for automatically approving Stack deployments based on speculative plan results, if there are no deleted resources for example, or if there are only new resources and no changes.

One of the strengths of Terraform Stacks is the concept of deferred deployments where it detects what parts of the deployment will need to be deferred until resources it depends on are ready. This means if you deploy an EKS cluster and then try to install a Helm chart to that cluster, Terraform Stacks knows to hold off on the Helm chart installation until after the EKS cluster is ready.

Terraform Stacks and GitOps

Deployments in Terraform Stacks are configured by a file you can easily template with jinja to generate new ones. One way to handle this is to create a Workflow Dispatch in GitHub to generate a new deployment by constructing a JSON context and applying it to a jinja template and appending to the .tfdeploy.hcl file in your repository, then generate a Pull Request and assign it to your Platform Engineering team.

Since most IDPs can integrate with Workflow Dispatch in self-service you now have a way for Developers to self service their need for infrastructure.

AWS Accounts and GitOps

You can even start further upstream. AWS Integration and Automation (aws-ia) has a mature Terraform product called Account Factor for Terraform (AFT). This product provides a GitOps way of procuring new AWS Accounts. To create one you can create or append to a Terraform file in your aft-account-request repository that contains a module block. This again can be handled with a Workflow Dispatch and it can end up being a Pull Request to your Platform Engineering team.

This reduces reuse of AWS Accounts which encourages separation of concerns and reduces blast radius of configuration errors.

And so on..

These two methods provide a golden path laid out by your Platform Engineering team to procure infrastructure. And I hope you can see where we can go from here.

We can create stacks to procure VPCs, or add a customization for AFT that generates a VPC from a common IPAM and sets up the networks you need.

A stack to procure EKS with a Helm chart installation for ArgoCD that references a repo and subdirectory for ArgoCD to deploy your K8s manifests to keep with the GitOps method, with output ffrom the VPC stack informing us of the subnets to use.

A reusable centralized workflow to allow your monorepo to deploy services to the EKS cluster using git push to the ArgoCD repo.

A Terraform Workspace that can grant development teams' Identity Center roles access to their newly vended AWS Account.

What about the small things?

Okay, it's probably fine to keep the big things like EKS in Stacks and procure them via self-service but what about the IAM role your Service Account needs, its permissions, the S3 buckets you need for your backend application or the DynamoDB table?

AWS and GCP have interesting products called Amazon Controllers for Kubernetes and Config Connector. These are Controllers for Kubernetes that expose an API in the form of Custom Resource Definitions so you can move these things closer to the application's context by adding it to the Kubernetes Manifests.

That way you can think of the application's manifests as a set of requirements for the application to run properly. This can and usually does vary by applications, the permissions each of their workload service accounts need in the context of cloud IAM.

These connectors then reconcile reality of the cloud infrastructure with the desire state of the manifest and continually resolve differences, eliminating drift.

Conclusion

There are shared feelings of attrition in the Software Development world involving delays in software deployment, the wait for infrastructure procurement, developers blocked by not having access to what they need to do their jobs.

The only way we can ever get out of this mess is if we stop doing things in an unsustainable way and start creating pathways and processes of self-service. It can be painful to shift course and let go of the current process that we have already spent a lot of time an effort developing, but fortunately for many of us working in Terraform there is emerging a way to migrate to a better, less monolithic and more GitOps process.

Platform Engineering teams can then focus on creating these self-service golden paths for each component and supporting those that need to use them.

#Guess Let's play 'Guess The Logo!' 🤔

Can you recognize this logo? Drop your guesses below!👇

💻 Explore insights on the latest in #technology on our Blog Page 👉 https://simplelogic-it.com/blogs/

What Is Argo CD?

Argo CD is declarative Kubernetes GitOps continuous delivery.

In DevOps, ArgoCD is a Continuous Delivery (CD) technology that has become well-liked for delivering applications to Kubernetes. It is based on the GitOps deployment methodology.

When was Argo CD Established?

Argo CD was created at Intuit and made publicly available following Applatix’s 2018 acquisition by Intuit. The founding developers of Applatix, Hong Wang, Jesse Suen, and Alexander Matyushentsev, made the Argo project open-source in 2017.

Why Argo CD?

Declarative and version-controlled application definitions, configurations, and environments are ideal. Automated, auditable, and easily comprehensible application deployment and lifecycle management are essential.

Getting Started

Quick Start

kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

For some features, more user-friendly documentation is offered. Refer to the upgrade guide if you want to upgrade your Argo CD. Those interested in creating third-party connectors can access developer-oriented resources.

How it works

Argo CD defines the intended application state by employing Git repositories as the source of truth, in accordance with the GitOps pattern. There are various approaches to specify Kubernetes manifests:

Applications for Customization

Helm charts

JSONNET files

Simple YAML/JSON manifest directory

Any custom configuration management tool that is set up as a plugin

The deployment of the intended application states in the designated target settings is automated by Argo CD. Deployments of applications can monitor changes to branches, tags, or pinned to a particular manifest version at a Git commit.

Architecture

The implementation of Argo CD is a Kubernetes controller that continually observes active apps and contrasts their present, live state with the target state (as defined in the Git repository). Out Of Sync is the term used to describe a deployed application whose live state differs from the target state. In addition to reporting and visualizing the differences, Argo CD offers the ability to manually or automatically sync the current state back to the intended goal state. The designated target environments can automatically apply and reflect any changes made to the intended target state in the Git repository.

Components

API Server

The Web UI, CLI, and CI/CD systems use the API, which is exposed by the gRPC/REST server. Its duties include the following:

Status reporting and application management

Launching application functions (such as rollback, sync, and user-defined actions)

Cluster credential management and repository (k8s secrets)

RBAC enforcement

Authentication, and auth delegation to outside identity providers

Git webhook event listener/forwarder

Repository Server

An internal service called the repository server keeps a local cache of the Git repository containing the application manifests. When given the following inputs, it is in charge of creating and returning the Kubernetes manifests:

URL of the repository

Revision (tag, branch, commit)

Path of the application

Template-specific configurations: helm values.yaml, parameters

A Kubernetes controller known as the application controller keeps an eye on all active apps and contrasts their actual, live state with the intended target state as defined in the repository. When it identifies an Out Of Sync application state, it may take remedial action. It is in charge of calling any user-specified hooks for lifecycle events (Sync, PostSync, and PreSync).

Features

Applications are automatically deployed to designated target environments.

Multiple configuration management/templating tools (Kustomize, Helm, Jsonnet, and plain-YAML) are supported.

Capacity to oversee and implement across several clusters

Integration of SSO (OIDC, OAuth2, LDAP, SAML 2.0, Microsoft, LinkedIn, GitHub, GitLab)

RBAC and multi-tenancy authorization policies

Rollback/Roll-anywhere to any Git repository-committed application configuration

Analysis of the application resources’ health state

Automated visualization and detection of configuration drift

Applications can be synced manually or automatically to their desired state.

Web user interface that shows program activity in real time

CLI for CI integration and automation

Integration of webhooks (GitHub, BitBucket, GitLab)

Tokens of access for automation

Hooks for PreSync, Sync, and PostSync to facilitate intricate application rollouts (such as canary and blue/green upgrades)

Application event and API call audit trails

Prometheus measurements

To override helm parameters in Git, use parameter overrides.