Securitain Docs
On this page

Machine Identities

Machine Identities classifies all IAM roles used by non-human workloads — Kubernetes pods, EC2 instances, Lambda functions, ECS tasks, CodeBuild jobs, GitHub Actions runners, GitLab CI pipelines and generic OIDC services — based strictly on trust-policy evidence collected from IAM.

Where to find Machine Identities

Open Exposure → Machine Identities. The list is paginated and filterable by identity type and classification confidence. Each row is a classified IAM role — selecting it opens a detail panel with its trust-policy evidence, effective permissions, blast radius and privilege escalation context.

Why machine identities matter

Machine identity roles carry real AWS permissions and are subject to the same policy evaluation as human roles. Unlike human identities, they are frequently long-lived, automated, issued at scale, and rarely reviewed in credential reports or access reviews. Common risk patterns include:

  • permissions granted for initial setup that were never reduced once the workload was stable
  • broad trust conditions that allow more workloads to assume the role than intended
  • privilege escalation paths that let a compromised workload assume a more powerful role
  • sensitive permissions (IAM mutation, PassRole, secret access) held by roles that power-on at cluster or instance start and run continuously

Classification evidence tiers

Classification is strictly evidence-ordered. Securitain reads the actual trust-policy document collected from IAM — names and tags are supplementary signals used only when trust-policy evidence is absent:

  • Tier 1 — trust-policy Federated principal (high confidence): the role trusts an external identity provider via OIDC or SAML. Sub-types: EKS IRSA, GitHub Actions, GitLab CI, generic OIDC federation.
  • Tier 2 — trust-policy Service principal (high confidence): the role trusts an AWS service directly. Sub-types: EKS Pod Identity, EC2, Lambda, ECS tasks, CodeBuild.
  • Tier 3 — customer-set purpose tags on the role (medium confidence): the classification is customer-supplied and unverified. A tag can be set by anyone with tagging permissions.
  • Tier 4 — role name pattern (low confidence): reported as a guess, not a determination.

Security

A role named github-actions-deploy whose trust policy admits only ec2.amazonaws.com is classified as an EC2 instance role — not a GitHub Actions runner. Getting this backwards is the exact failure the evidence-ordered approach prevents.

Classified identity types

Kubernetes / EKS workload identities

  • EKS IRSA — Federated OIDC principal with a system:serviceaccount: subject condition. The subject condition determines which Kubernetes service accounts can assume the role. A wildcard or absent subject is flagged as exposure. See EKS IRSA.
  • EKS Pod Identity — EKS Pod Identity service principal. Namespace and service-account scoping lives in the EKS Pod Identity association, not in the trust policy, so Securitain classifies the role but cannot read which pods are mapped. See EKS Pod Identity.

AWS compute service roles

  • EC2 instance roles — trust policy contains the EC2 service principal. Credentials are delivered via the EC2 instance metadata service. The role's permissions are accessible to any code running on the instance.
  • Lambda execution roles — trust policy contains the Lambda service principal. The role's permissions are available to the function for the duration of each invocation.
  • ECS task roles — trust policy contains the ECS tasks service principal. Credentials are scoped per task and delivered via the ECS credentials endpoint.
  • CodeBuild service roles — trust policy contains the CodeBuild service principal. Permissions are available to all commands run inside the build environment.

CI/CD and external workload identities

  • GitHub Actions — Federated OIDC principal from the GitHub Actions OIDC provider. The subject condition should scope the role to a specific repository, workflow and branch. A wildcard subject exposes the role to any GitHub Actions workflow in the trusted organization.
  • GitLab CI — Federated OIDC principal from a GitLab instance OIDC endpoint. Subject condition scoping determines which pipelines can assume the role.
  • Generic OIDC federation — a Federated principal from an OIDC provider not recognized as a known CI/CD system. Classified by trust-policy evidence; the provider value is shown as-is.

What each record shows

  • Identity type and classification confidence — the detected workload type and which evidence tier produced the classification
  • Trust-policy evidence — the principal type, provider value (for Federated), and subject/audience conditions that were found
  • Blast radius score — the potential scope of impact if the role's credentials are misused
  • Effective permissions — what the role can do after permission boundaries, SCPs and resource-policy denies are applied
  • Privilege escalation paths — whether the role can reach a stronger capability than intended
  • Sensitive permissions — high-consequence actions held by the role

What it means

A high blast-radius score represents the potential scope of impact if this workload role's credentials were misused — through a container escape, a compromised instance, a misconfigured metadata endpoint, or an overly wide trust condition.

What it does not mean

  • The workload is actively exploiting its permissions.
  • All high blast-radius machine identities are confirmed vulnerabilities.
  • The role should be restricted without first checking effective permissions and observed usage.

Classification confidence

  • High — classification is from trust-policy Federated or Service principal evidence (Tier 1 or Tier 2). This is the most reliable signal.
  • Medium — classification is from customer-set purpose tags. Treat as an unverified customer label.
  • Low — classification is from role name pattern only. This is a guess and is explicitly flagged as such.

A role whose trust-policy document could not be resolved is classified at lower confidence and that fact is stated on the record — it is never silently omitted from the list.

Note

You can filter Machine Identities by minimum confidence. Filtering to High shows only roles whose type is determined from trust-policy evidence — the most reliable starting point for a workload identity security review.

Limitations

Limitation

  • Classification depends on trust-policy collection. A role whose trust policy document could not be fully resolved during the last scan is classified at lower confidence or not classified at the current tier.
  • For EKS Pod Identity roles, the namespace and service-account scope lives in EKS Pod Identity associations — not in IAM. Securitain cannot read those associations.
  • A role that has a mixed trust policy (e.g. both a GitHub Actions OIDC principal and a Lambda service principal) is classified by the highest-evidence tier present and both principals are reported. The combination itself is not assessed for intent.
  • Runtime behavior — which workloads actually assumed the role, how frequently, and from where — is CloudTrail evidence. Securitain surfaces CloudTrail-based activity context where collected; machine identity classification itself is a structural IAM assessment.