> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Consider Fargate Running Untrusted Workloads

### More Info:

It is Best Practice to restrict or fence untrusted workloads when running in a multi-tenant environment.

### Risk Level

Low

### Address

Security

### Compliance Standards

* APRA CPS 234 (Australia)
* BSI C5 (Germany)
* Brazil LGPD
* CCPA / CPRA (California)
* CIS Critical Security Controls v8
* CIS EKS
* CMMC 2.0
* CSA Cloud Controls Matrix v4
* DPDPA
* Digital Operational Resilience Act (EU)
* Essential 8
* ISO/IEC 27017
* ISO/IEC 27018
* ISO/IEC 27701
* KSA PDPL
* MAS Technology Risk Management (Singapore)
* MITRE ATT\&CK (Cloud)
* NIS2 Directive
* NIST SP 800-171
* NYDFS 23 NYCRR 500
* SWIFT Customer Security Controls Framework
* Sarbanes-Oxley IT General Controls
* UK NCSC Cyber Assessment Framework

### Triage and Remediation

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. **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:
             ```bash theme={null}
             kubectl get ns
             kubectl get pods -A -o wide
             ```
           * Decide which namespaces (or pod labels) should be considered “untrusted” and isolated onto Fargate.

        2. **Check existing Fargate profiles and selectors**
           * On any machine with AWS CLI configured, list Fargate profiles and review their selectors:
             ```bash theme={null}
             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).

        3. **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).

        4. **Create or update Fargate profiles for untrusted workloads**
           * If needed, create a new Fargate profile for a whole namespace:
             ```bash theme={null}
             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:
             ```bash theme={null}
             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.

        5. **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):
             ```bash theme={null}
             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.

        6. **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.
      </Accordion>

      <Accordion title="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.
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/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
        ```
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>

### Additional Reading:

* [https://docs.aws.amazon.com/eks/latest/userguide/fargate.html](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html)