Amazon ECS and EKS

Vendor key: aws_containers. In Arthur this source appears as ECS and EKS. For how source fields and scan configs fit together, see Agent Discovery Integrations.

Lists every ECS service, every ECS task no service owns, and every EKS workload in one AWS account and the regions you name. Arthur reports a workload when one of its images is a known agent's, or when the IAM role it runs as called a Bedrock model, as CloudTrail shows. Each agent names the role the workload runs as. To cover more accounts, add one source for each.

An EKS workload is a Deployment, StatefulSet, DaemonSet or CronJob, or a Job or Pod that nothing owns. System namespaces such as kube-system are left out. ECS lists a stopped task for only about an hour, so a task that no service owns is seen only while it runs or just after.

Before you start

On each EKS cluster, create an access entry for the IAM principal Arthur uses and associate the AmazonEKSViewPolicy access policy with it at cluster scope. For a cluster that still uses CONFIG_MAP authentication, map the principal in aws-auth to a group bound to the view ClusterRole instead.
Make sure your Arthur engine can reach each EKS cluster's API endpoint. A cluster with only a private endpoint is reachable only from inside its network.

For step-by-step instructions, see the EKS access entries guide in the AWS documentation.

Source fields

Field	Required	Sensitive	Default	Description
`regions`	Yes	No		Comma-separated AWS regions, for example `us-east-1,us-west-2`. ECS and EKS are both listed in each, and CloudTrail is read in each when `read_cloudtrail` is on.
`read_cloudtrail`	No	No	`true`	`true` or `false`. Reports a workload whose IAM role called Bedrock models, with the models it called. No trail setup is needed.
`report_all_workloads`	No	No	`false`	`true` or `false`. Reports every workload with the IAM role it runs as, not only known agents' images and Bedrock-calling roles.
`role_arn`	No	No		An IAM role to assume before reading, for another account or for a credential with no permissions of its own. For example `arn:aws:iam::123456789012:role/arthur-discovery`.
`external_id`	No	No		The external ID the role's trust policy requires. Sent only when assuming `role_arn`.
`access_key_id`	No	Yes		An IAM access key ID. Set it together with `secret_access_key`.
`secret_access_key`	No	Yes		The secret of the IAM access key.

Leave access_key_id and secret_access_key empty only if your Arthur engine is configured to use its own AWS credentials (ARTHUR_ENGINE_AWS_CONTAINERS_ALLOW_DEFAULT_CREDENTIALS=true).

The role Arthur reports is the ECS task role (never the execution role), or on EKS the pod's IAM role for service accounts, then its Pod Identity association, then the managed node group's node role. A node or instance role is shared by everything that runs on it, and the agent's name says so. A Fargate pod has no node role. EKS doesn't list nodes outside managed node groups, such as self-managed or Karpenter nodes, so their roles aren't reported.

Scan config

Setting	Value
`query`	`""` to use Arthur's built-in agent catalog, or your own catalog YAML.
`query_language`	`none`
`lookback_window_seconds`	Every scan lists every workload. CloudTrail is read over this window. `0` reads the last 7 days.

Required permissions

All the actions are read-only.

ECS: ecs:ListClusters, ecs:ListServices, ecs:DescribeServices, ecs:ListTasks, ecs:DescribeTasks, ecs:DescribeTaskDefinition.
ecs:DescribeContainerInstances, ec2:DescribeInstances and iam:GetInstanceProfile. Needed only for ECS tasks on EC2 that have no task role.
EKS: eks:ListClusters, eks:DescribeCluster, eks:ListNodegroups, eks:DescribeNodegroup, eks:ListPodIdentityAssociations, eks:DescribePodIdentityAssociation, eks:ListFargateProfiles, eks:DescribeFargateProfile.
On each EKS cluster, an access entry with AmazonEKSViewPolicy at cluster scope.
cloudtrail:LookupEvents. Needed only if read_cloudtrail is on.
sts:AssumeRole on role_arn. Needed only if you set role_arn.

For least privilege, grant a custom policy with just these actions. Task definitions and Kubernetes objects come back with their containers' environment variables, which these calls can't leave out. Arthur keeps only images, roles, names and timestamps from them.

If ECS or EKS listing is refused in a region, or a cluster's Kubernetes API answers 401 or 403 or can't be reached, the scan reads the rest and reports it as a denied scope. EKS answers 401 when the principal has no access entry on that cluster. If the AWS credential is refused, or every ECS and EKS listing is refused, the scan fails.