# EKS Fargate Pushes Proxy Control Into Kubernetes Admission Policy

- Link: https://thestackobserver.com/eks-fargate-pushes-proxy-control-into-kubernetes-admission-policy/
- Published: 2026-09-21T07:03:06-04:00
- Author: Stackxx

AWS published a practical pattern for one of the more awkward corners of Amazon 
EKS operations: how to make Fargate-based Kubernetes pods obey corporate proxy requirements
when the node layer is not available to configure. The answer in the AWS Containers
post is Kyverno, used as a mutating admission policy that injects proxy environment
variables into pods before they are persisted and scheduled.

The article is not just an AWS-specific how-to. It highlights a broader Kubernetes
operations lesson: as more teams move workloads onto managed or serverless node 
abstractions, admission-time policy becomes the most reliable place to enforce runtime
configuration that used to live in bootstrap scripts, machine images, or node-level
environment files. Fargate makes that shift obvious because customers cannot log
into or customize the underlying worker nodes, but the same design pressure shows
up across managed Kubernetes fleets.

The central thesis is that proxy configuration belongs in Kubernetes admission policy
when the compute substrate is managed, especially for regulated environments where
every outbound path must be predictable. Kyverno is useful here not because proxy
variables are complex, but because it gives platform teams a native, reviewable,
namespace-scoped way to apply them consistently without asking every application
team to edit every container spec.

## The Fargate Constraint

In a traditional EKS cluster running on EC2 worker nodes, operators often configure
proxies through instance user data, host environment files, systemd drop-ins, or
node image customization. That can help host-level processes such as kubelet, container
image pulls, or node agents. It does not automatically solve application egress 
from inside containers, because containers do not simply inherit the host environment
in the way many enterprise network teams might expect.

With EKS on Fargate, even that partial host-level option disappears. AWS runs the
underlying compute. Customers define pods, namespaces, profiles, IAM roles, and 
networking, but they do not administer the node operating system. If an organization
requires application traffic to leave through a corporate HTTP or HTTPS proxy, the
relevant configuration has to be present in the pod specification before the pod
starts. Otherwise, the first outbound call from the application may bypass the expected
path or fail because the network only permits egress through the proxy.

That requirement is common in regulated enterprises. Security teams may need centralized
inspection, allow-listing, logging, data loss prevention, or routing through on-
premises controls over VPN or Direct Connect. Application teams, meanwhile, want
to deploy workloads without hand-maintaining proxy variables in every manifest. 
The mismatch leads to brittle duplication: `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY`
repeated across containers, init containers, jobs, cron jobs, and Helm values.

## Why Admission Policy Fits

Kubernetes admission controllers sit on the path between a submitted object and 
the persisted cluster state. A mutating admission controller can change a pod specification
before the API server stores it. That timing is critical for proxy injection. If
the variables are added after scheduling, there is a race: the container might already
have started, and the application may already have attempted network calls. If they
are added at admission time, the pod starts with the correct environment from the
beginning.

Kyverno is a natural fit because it expresses policy as Kubernetes resources rather
than a custom webhook written and maintained by the platform team. In the AWS pattern,
a Kyverno `MutatingPolicy` matches pods in labeled namespaces and injects proxy 
environment variables into all containers and init containers. Namespace labels 
become the opt-in or targeting mechanism. Platform teams can enable proxy injection
for Fargate-profiled namespaces without requiring application teams to change deployment
manifests.

This is a small policy with a large operational effect. Instead of maintaining three
variables across hundreds of container specs, the platform team maintains one policy
and a namespace label. When the proxy endpoint or bypass list changes, the source
of truth changes in one place. New pods receive the updated configuration at creation
time. Existing pods still need to be restarted to pick up new environment variables,
but that behavior is visible and manageable through normal rollout practices.

## The NO_PROXY List Is the Hard Part

The most important engineering work in this pattern is not writing the mutation 
rule. It is composing the `NO_PROXY` value correctly. Kubernetes clusters rely on
internal DNS names, service CIDRs, pod networking, metadata endpoints, cloud APIs,
logging services, identity endpoints, and sometimes private VPC endpoints. Sending
all of that through a corporate proxy can break cluster behavior, introduce latency,
or route internal traffic through the wrong inspection boundary.

A practical `NO_PROXY` list usually includes loopback addresses, the Kubernetes 
service DNS names, the cluster DNS suffixes such as `.svc` and `.cluster.local`,
VPC CIDR ranges, the metadata endpoint when relevant, and cloud service domains 
that should be reached directly through VPC endpoints or normal AWS networking. 
The exact list is environment-specific. A platform team should treat it as production
network configuration, not as a copy-paste appendix from a blog post.

There is also client behavior to consider. Some libraries honor CIDR entries in `
NO_PROXY`; others match only hostnames or suffixes. The AWS post notes that clients
such as `curl` and `libcurl` do not handle CIDR matching the same way some SDKs 
do. That difference matters when an application reaches in-cluster services by IP
rather than DNS. If the bypass rule relies on a suffix match, service names are 
safer than raw ClusterIP addresses.

## What Platform Teams Should Standardize

The first decision is the targeting model. Namespace labels are a clean starting
point because they align with Fargate profiles and team boundaries. A label such
as `proxy-injection=enabled` makes the policy visible in standard Kubernetes inventory
and keeps application manifests free of enterprise network plumbing. The platform
team can then decide whether the label is applied manually, through a namespace 
provisioning workflow, or by a higher-level internal platform.

The second decision is failure behavior. Admission webhooks can block pod creation
if they are unavailable, or they can fail open. For proxy injection, the right answer
depends on the environment. In a strict egress-control regime, allowing pods to 
start without proxy settings may violate policy or simply produce broken workloads.
In a high-availability environment, blocking all pod starts because a policy controller
is temporarily unavailable can become its own outage. The AWS walkthrough discusses
fail-open behavior as a way to avoid scheduling disruption, but each organization
needs to align that with its compliance model.

The third decision is how to handle exceptions. Some workloads do not use proxy 
environment variables. Some need direct egress to private endpoints. Some have language
runtimes or SDKs with special proxy semantics. Rather than letting teams fork manifests,
a platform group should define an exception path: namespace-level opt-out, workload
annotation, policy precondition, or a separate class of namespace. The important
point is that exceptions should be reviewable and searchable.

The fourth decision is restart mechanics. Mutating admission happens at creation
time. If the proxy URL changes, existing pods do not magically inherit a new environment.
Teams need a rollout mechanism, whether that is a Deployment restart, a GitOps-driven
annotation bump, or a platform operation that identifies affected workloads and 
restarts them. This is not a weakness of the pattern; it is the normal behavior 
of pod environment variables. But it must be included in the runbook.

## Security Benefits and Tradeoffs

The security benefit is consistency. Central policy reduces the chance that one 
workload forgets a proxy variable, misses an init container, or ships a stale bypass
list. It also gives auditors and security engineers a single Kubernetes object to
inspect. Instead of sampling dozens of application repositories, they can evaluate
the admission policy, the namespace targeting, and the cluster state.

The tradeoff is that Kyverno becomes part of the pod creation path. That does not
mean it is heavy or inappropriate; Kyverno is a mature CNCF policy engine. But it
does mean the platform team must operate it as critical control-plane-adjacent infrastructure.
Controller availability, webhook configuration, policy versioning, and upgrade testing
matter. A broken mutation policy can affect every workload in the targeted namespaces.

There is also a risk of hidden application coupling. Environment-variable proxy 
support is common, but it is not universal. Some applications use custom HTTP clients,
pinned networking libraries, or explicit proxy configuration files. Admission-time
injection should be paired with validation, synthetic tests, and application owner
documentation so teams know what behavior the platform provides and what remains
their responsibility.

## Why This Is Bigger Than Proxies

The larger pattern is the migration of operational defaults from machines to APIs.
In a server-managed node model, the old habit of fixing fleet behavior with base
images and bootstrap scripts has less reach. Kubernetes operators increasingly need
to express defaults through admission, policy, and workload abstractions. Proxy 
settings are one example. Other examples include sidecar injection, runtime class
selection, security contexts, tolerations, labels, annotations, image pull configuration,
and compliance metadata.

This does not mean every platform concern should become a mutating webhook. Overuse
of mutation can make manifests surprising: what developers submit is not exactly
what runs. The best use cases are those with clear ownership, predictable transformations,
and visible policy boundaries. Proxy injection for Fargate namespaces meets that
bar because the requirement is environment-wide, the fields are standard pod fields,
and the target can be expressed through namespace labels.

It also shows why policy-as-code tools need to be part of platform engineering, 
not an afterthought added by security. A useful policy is not merely a gate that
says no. In this case, policy actively completes the workload spec so that applications
can run inside enterprise network constraints without every team becoming an expert
in egress architecture. That is the more productive direction for platform controls:
make the compliant path the easy path.

## Adoption Checklist

 * **Map the traffic paths.** Identify which destinations must use the proxy and
   which must bypass it, including Kubernetes service DNS, VPC endpoints, AWS APIs,
   logging, identity, and private service domains.
 * **Define namespace targeting.** Decide which namespaces should receive proxy 
   injection and how labels are applied during namespace creation.
 * **Test client behavior.** Validate `NO_PROXY` handling with the actual languages,
   SDKs, and command-line tools used by workloads.
 * **Choose webhook failure behavior.** Align fail-open or fail-closed settings 
   with availability and compliance requirements.
 * **Create an exception model.** Make opt-outs explicit, reviewable, and searchable
   rather than hidden in application-specific manifest changes.
 * **Document restart procedures.** Changing proxy values affects newly created 
   pods; existing pods need rollouts.

## The Bottom Line

The AWS EKS Fargate proxy pattern is valuable because it solves a mundane but persistent
enterprise problem with Kubernetes-native mechanics. It does not require a custom
webhook, per-application manifest edits, or access to managed nodes that Fargate
intentionally hides. It uses admission-time mutation to put the right environment
into the pod before the workload starts.

For platform teams, the takeaway is broader than the specific Kyverno YAML. Managed
compute changes where operational control lives. When the node is no longer yours,
the pod admission path becomes one of the most important enforcement points in the
system. Used carefully, that path can make regulated Kubernetes environments simpler
rather than more fragile.

## Sources

 * [AWS Containers Blog: Automate proxy injection for Amazon EKS on AWS Fargate using Kyverno](https://aws.amazon.com/blogs/containers/automate-proxy-injection-for-amazon-eks-on-aws-fargate-using-kyverno/)
 * [Kyverno project](https://kyverno.io/)
 * [Amazon EKS documentation: AWS Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html)