Fis Security

Contents

• The experiment IAM role (roleArn)
• Restrict who can start experiments
• Bounded blast radius (safety, not just IAM)
• Data handling
• Auditing
• Further reading

The experiment IAM role (roleArn)

FIS assumes the experiment role to perform actions on your behalf. It is a service role with:

1. A trust policy allowing fis.amazonaws.com to assume it, with confused-deputy conditions.
2. Identity-based permissions for exactly the target-service APIs the experiment’s actions invoke (and SSM / logs / report S3+CloudWatch if those features are used).

Trust policy with confused-deputy protection (required)

Condition on aws:SourceAccount and aws:SourceArn so only your account’s FIS experiments can assume the role — never leave the trust policy unconditioned.

Least-privilege permissions (scope to actions AND target ARNs)

Grant only what the chosen actions need, scoped to the specific target resources — never "*" across a service. Example for an EC2 reboot experiment on tagged prod instances:

Describe* calls FIS uses for target resolution/filtering generally require Resource: "*" (they don’t support resource-level scoping), but the fault actions should be scoped by ARN and/or aws:ResourceTag. Match permissions to the action’s underlying API.

Action → underlying-permission mapping (illustrative — verify with get-action)

The exact IAM actions each FIS action needs evolve; treat this as a starting point and confirm the authoritative list before finalizing a policy (see “authoritative source” below). The pattern is always the same: fault permission(s) scoped by ARN/tag + the Describe* resolution permission on Resource: "*".

EKS pod actions are the common trap: IAM alone will not run them. You also need Kubernetes RBAC (map the experiment role into the cluster and bind it to a role that permits the pod operation) and the cluster must be prepared for FIS. Grant eks:* sparingly and lean on k8s RBAC for the actual pod permissions.

Authoritative source (use when an action is not in the table above, or to confirm one that is): run aws fis get-action --id <action-id> and consult How AWS FIS works with IAM (opens in a new tab) and any AWS-managed FIS policies. Do not invent IAM action names for an action whose underlying API you cannot confirm — scaffold the correctly-scoped policy and mark the fault permissions as <verify with get-action> rather than guessing.

Additional permissions per feature

• Experiment logging — grant FIS vended-logs delivery permissions to the CloudWatch Logs log group and/or S3 bucket you configure.
• Experiment reports — cloudwatch:GetDashboard, cloudwatch:GetMetricWidgetImage, s3:PutObject, s3:GetObject (scoped to the report bucket/prefix); plus kms:GenerateDataKey, kms:Decrypt if the report bucket uses a customer-managed KMS key.
• Multi-account — each target account needs its own role that the orchestrator’s FIS can assume, with the same confused-deputy conditions and least-privilege target permissions.

Restrict who can start experiments

Starting an experiment is a privileged action. Scope the human/CI principals allowed to call fis:StartExperiment (and template CRUD), ideally with aws:ResourceTag conditions and by template ARN. FIS supports identity-based policies, ABAC (tags in policies), service-specific condition keys, and PassRole controls — use iam:PassRole conditions so only approved experiment roles can be passed to FIS.

Caller iam:PassRole — required

When emitting an experiment role, ALSO emit the caller’s PassRole policy. Without it, any caller who can create/update templates can reference any FIS-trusting role in the account.

Rules: Resource = explicit experiment-role ARN(s), never *. Condition iam:PassedToService = fis.amazonaws.com.

Bounded blast radius (safety, not just IAM)

• Always attach a stop condition — a CloudWatch alarm on your steady-state metric. It is the automated kill-switch. {"source":"none"} is acceptable only in a throwaway sandbox.
• Start narrow — COUNT(1) or a small PERCENT(n), single AZ, pre-production first. Widen only after the experiment passes.
• Preview targets (actionsMode: skip-all) before a real run to confirm the exact resources.
• Production requires change management — treat prod fault injection as a change with approval, a run window, and a rollback/stop plan.
• Empty-target behavior — leave emptyTargetResolutionMode at fail so an over- or under-matching target surfaces immediately instead of silently doing nothing.

Data handling

• No sensitive data in string fields — template/experiment descriptions, action assertion text, tags, and log/report content surface in CloudTrail, CloudWatch Logs, S3, the console, and (multi-account) target-account AWS Health dashboards. Never embed PII, secrets, or sensitive architecture detail.
• Encrypt logs & reports — experiment logs and PDF reports reveal resilience posture and architectural weaknesses. Use SSE-KMS on the S3 buckets, enforce TLS with a bucket policy condition on aws:SecureTransport, restrict to a dedicated bucket/prefix, and consider S3 Object Lock on report buckets so evidence can’t be altered or deleted.

Auditing

FIS API calls are recorded in AWS CloudTrail (including the actions FIS takes in each target account for multi-account experiments). Review CloudTrail and experiment logs after each run.

Further reading

• Security in AWS FIS (opens in a new tab)
• How AWS FIS works with IAM (opens in a new tab)
• IAM best practices (opens in a new tab)
• AWS Well-Architected Reliability Pillar (opens in a new tab)