Consider Fargate Running Untrusted Workloads

Manual Steps

Identify and classify untrusted workloads
- On any machine with kubectl access, list all namespaces and note which are multi-tenant, customer-facing, or otherwise untrusted:
  kubectl get ns kubectl get pods -A -o wide
- Decide which namespaces (or pod labels) should be considered “untrusted” and isolated onto Fargate.
Check existing Fargate profiles and selectors
- On any machine with AWS CLI configured, list Fargate profiles and review their selectors:
  aws eks list-fargate-profiles --cluster-name YOUR_CLUSTER_NAME aws eks describe-fargate-profile \ --cluster-name YOUR_CLUSTER_NAME \ --fargate-profile-name FARGATE_PROFILE_NAME
- Confirm whether any existing profiles already cover the untrusted namespaces or workloads (via namespace and label selectors).
Decide coverage gaps and Fargate strategy
- Compare the untrusted workloads (step 1) to the current Fargate profile selectors (step 2).
- For each untrusted namespace/workload not matching an existing Fargate profile, decide whether it should:
  - Always run on Fargate (new/updated Fargate profile), or
  - Continue on node groups with other isolation controls (and document why Fargate is not used).

Create or update Fargate profiles for untrusted workloads

If needed, create a new Fargate profile for a whole namespace:

aws eks create-fargate-profile \
  --cluster-name YOUR_CLUSTER_NAME \
  --fargate-profile-name untrusted-namespace-fargate \
  --pod-execution-role-arn arn:aws:iam::ACCOUNT_ID:role/EKSFargatePodExecutionRole \
  --subnets subnet-AAAAAAA subnet-BBBBBBB \
  --selectors namespace=UNTRUSTED_NAMESPACE

Or create a profile targeting specific labels within a namespace:

aws eks create-fargate-profile \
  --cluster-name YOUR_CLUSTER_NAME \
  --fargate-profile-name untrusted-labeled-fargate \
  --pod-execution-role-arn arn:aws:iam::ACCOUNT_ID:role/EKSFargatePodExecutionRole \
  --subnets subnet-AAAAAAA subnet-BBBBBBB \
  --selectors namespace=SHARED_NAMESPACE,labels={tier=untrusted}

If using IaC (CloudFormation/Terraform), make equivalent changes there instead of using CLI and apply them through your normal deployment pipeline.

Verify scheduling behavior for untrusted workloads
- Deploy or restart a representative untrusted pod and confirm it is scheduled onto Fargate (no node name, eks.amazonaws.com/compute-type=fargate annotation):
  kubectl get pods -n UNTRUSTED_NAMESPACE -o wide kubectl get pod POD_NAME -n UNTRUSTED_NAMESPACE -o yaml | grep -i eks.amazonaws.com/compute-type
- Ensure that trusted/system workloads that should remain on node groups are not unintentionally matched by the Fargate profile selectors.
Document residual risk and ongoing review
- Record which namespaces/labels are intended to run on Fargate and which are intentionally left on node groups, including rationale.
- Establish a process so that when new untrusted namespaces or tenants are added, their scheduling (Fargate vs node groups) is explicitly reviewed and configured using steps 1–5.

Using kubectl

kubectl can’t create or manage EKS Fargate profiles; those are configured at the AWS control plane level via the AWS console, CLI, or IaC (such as CloudFormation or Terraform). To address this finding, follow the guidance in the Manual Steps section for creating or updating appropriate Fargate profiles and namespace/label selectors.

Automation

#!/usr/bin/env bash
set -euo pipefail

echo "=== EKS Fargate / untrusted workload review ==="

# 1) List Fargate profiles and their selectors (runs anywhere with aws + kubectl access)
echo
echo "== Fargate profiles and selectors =="
aws eks list-clusters --output text | awk '{print $2}' | while read -r CLUSTER; do
  echo "--- Cluster: ${CLUSTER} ---"
  REGIONS="$(aws eks list-clusters --output json 2>/dev/null >/dev/null || true)" # no-op, just to keep aws happy
  aws eks list-fargate-profiles --cluster-name "${CLUSTER}" --output text 2>/dev/null | awk '{print $2}' | while read -r PROFILE; do
    echo "Profile: ${PROFILE}"
    aws eks describe-fargate-profile \
      --cluster-name "${CLUSTER}" \
      --fargate-profile-name "${PROFILE}" \
      --output json | jq -r '.fargateProfile.selectors[] | "  Namespace: \(.namespace // "*")  Labels: \(.labels // {})"'
  done || echo "  (no Fargate profiles found)"
done

# 2) Current cluster: show which pods are on Fargate vs nodes (runs on any machine with kubectl access)
echo
echo "== Pods and where they are running (current kube-context) =="

echo
echo "-- Pods scheduled on Fargate (no assigned node, capacity-type=fargate or fargate label) --"
kubectl get pods -A -o json | jq -r '
  .items[]
  | select(
      (.spec.nodeName == null)
      or (.metadata.labels["eks.amazonaws.com/capacityType"] == "FARGATE")
      or (.spec.nodeSelector["eks.amazonaws.com/compute-type"] == "fargate")
    )
  | [.metadata.namespace, .metadata.name] | @tsv' | column -t || echo "none"

echo
echo "-- Pods scheduled on standard worker nodes --"
kubectl get pods -A -o wide

# 3) Optional: highlight candidate "untrusted" namespaces (heuristic, manual review needed)
echo
echo "== Namespaces likely hosting tenant / app workloads (manual review required) =="
kubectl get ns -o json | jq -r '
  .items[]
  | select(.metadata.name as $n | ($n != "kube-system" and $n != "kube-public" and $n != "kube-node-lease" and $n != "default"))
  | .metadata.name' | sort

cat <<'EOF'

INTERPRETING RESULTS (manual decision required):

- Potential problems / gaps:
  * Namespaces that host untrusted or multi-tenant workloads (e.g., per-team, per-customer)
    appear in the list above but:
      - Do NOT have matching Fargate profile selectors (by namespace/labels), and
      - Their pods in "Pods scheduled on standard worker nodes" are running on EC2 nodes.
  * There are no Fargate profiles at all, but you expect to isolate certain workloads.

- Safer / desired patterns:
  * Untrusted / tenant namespaces have corresponding Fargate profiles with selectors that
    match all of their pods (by namespace and labels).
  * Pods that should be fenced are visible in the "Pods scheduled on Fargate" section.

Next step is to:
  - Identify which namespaces/workloads you classify as "untrusted" or multi-tenant.
  - Compare them to Fargate profile selectors.
  - For gaps, create or adjust Fargate profiles via AWS console/CLI/IaC as per the benchmark.
EOF

AWS Introduction

AWS Pricing

AWS Threats

AWS Misconfigurations

Consider Fargate Running Untrusted Workloads

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

Additional Reading:

​More Info:

​Risk Level

​Address

​Compliance Standards

​Triage and Remediation

​Remediation

​Additional Reading: