{"id":2707,"date":"2022-12-16T17:35:57","date_gmt":"2022-12-16T22:35:57","guid":{"rendered":"http:\/\/blog.domb.net\/?p=2707"},"modified":"2023-11-23T18:05:34","modified_gmt":"2023-11-23T23:05:34","slug":"fault-injection-simulator-cross-account-experiments","status":"publish","type":"post","link":"https:\/\/blog.domb.net\/?p=2707","title":{"rendered":"AWS Fault Injection Simulator Cross Account Experiments via AWS StepFunctions"},"content":{"rendered":"

Many AWS customers run their workloads across multiple AWS accounts. Therefore they want to be able to run chaos experiments across accounts to understand how their workload behaves during a cascading or correlated failure. Today, AWS Fault Injection Simulator does not yet support targets in different accounts, but this doesn’t hinder us to run experiments via AWS StepFunctions which has great integrations with AWS Fault Injection Simulator.<\/p>\n

AWS StepFunctions allows us to create states with the following actions: <\/p>\n

\"\" \"\" \"\" \"\"<\/p>\n

If you are interested in having a central place where you create experiments and fan out experiments to the various accounts via service catalog, you can read up on it here<\/a>. In the case of this blog post, I’ve created an experiment that only executes a chaos-mesh experiment via FIS in account A and reboots an EC2 instances via FIS in account B. You will point the execution steps to your own FIS Experiment Templates. <\/p>\n

Please keep in mind that when running chaos experiments in your environment you’d want to follow the following workflow before the execution of the experiment. As the goal of this blog post is to provide you with insights on how to built a StepFunction that can run experiments cross accounts, I will therefore skip much of this workflow and only focus on the FIS execution via StepFunction. <\/p>\n

\"\"<\/p>\n

For our workload, that is comprised of an EKS Cluster in account A, and a Database on EC2 in account B, I will build the following state machine<\/p>\n

\"\"<\/p>\n

Before we can start, you will need to create a IAM role in account B<\/strong> that you will use to allow account A to assume the FIS-Execution role. <\/p>\n

[cc lang=”bash”]<\/p>\n

{
\n “Version”: “2012-10-17”,
\n “Statement”: [
\n {
\n “Sid”: “FisExecutionRole”,
\n “Effect”: “Allow”,
\n “Action”: [
\n “fis:StartExperiment”,
\n “fis:TagResource”
\n ],
\n “Resource”: “*”
\n }
\n ]
\n}<\/p>\n

[\/cc]<\/p>\n

You will also have to define a trust policy for this role so that account A is authorized to assume the role in account B<\/p>\n

[cc lang=”bash”]<\/p>\n

{
\n “Version”: “2012-10-17”,
\n “Statement”: [
\n {
\n “Effect”: “Allow”,
\n “Principal”: {
\n “AWS”: “arn:aws:iam::YourAccountID:root”
\n },
\n “Action”: “sts:AssumeRole”,
\n “Condition”: {}
\n }
\n ]
\n}
\n[\/cc]<\/p>\n

Note the ARN of the role in account B<\/strong> as you will need it in the Step Function Step in account A<\/strong>!<\/p>\n

Let’s create a state machine in account A<\/strong> and click next. <\/p>\n

\"\"<\/p>\n

In the search field on the top left enter FIS <\/p>\n

\"\"<\/p>\n

and drag the StartExperiment tab into your State Machine workflow. Rename it as you like. You should see something like this<\/p>\n

\"\"<\/p>\n

Click \"\" twice and notice the banner on the bottom of the page! We will add the permissions once the role is created.<\/p>\n

\"\"<\/p>\n

Give the StateMachine a name and click
\n\"\"<\/p>\n

This will get you to the following page. Click on Edit Role in IAM<\/strong> to Add the missing permissions.<\/p>\n

\"\"<\/p>\n

Keep in mind that our role does also need assume role permissions for the cross account access. We are therefore adding the following permissions<\/p>\n

Allow the role to assume all resources<\/p>\n

[cc lang=”bash”]
\n{
\n “Version”: “2012-10-17”,
\n “Statement”: [
\n {
\n “Sid”: “AllowAssumeRole”,
\n “Effect”: “Allow”,
\n “Action”: “sts:AssumeRole”,
\n “Resource”: “*”
\n }
\n ]
\n}
\n[\/cc]<\/p>\n

as well as execute the experiment. <\/p>\n

[cc lang=”bash”]<\/p>\n

{
\n “Version”: “2012-10-17”,
\n “Statement”: [
\n {
\n “Sid”: “FisExecutionRole”,
\n “Effect”: “Allow”,
\n “Action”: [
\n “fis:StartExperiment”,
\n “fis:TagResource”
\n ],
\n “Resource”: “*”
\n }
\n ]
\n}<\/p>\n

[\/cc]<\/p>\n

Now go back to your state machine and add a second step as follows<\/p>\n

\"\"<\/p>\n

Make sure that for the IAM role for cross-account access – optional you chose <\/p>\n

Provide IAM role ARN and choose the role ARN in account B<\/strong> that you’ve created before! arn:aws:iam::AccountNumberB:role<\/strong>\/fisfullaccess<\/p>\n

Click apply the changes. You are now ready to execute the State Machine. <\/p>\n

You should see both states turning green<\/p>\n

\"\"<\/p>\n

You can now go verify on both accounts in your FIS console that both experiments were executed with the Tag names defined in your step functions step!<\/p>\n

For a comprehensive workflow in a single account please review Chaos experiments using AWS Step Functions and AWS Fault Injection Simulator<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Many AWS customers run their workloads across multiple AWS accounts. Therefore they want to be able to run chaos experiments across accounts to understand how their workload behaves during a cascading or correlated failure. Today, AWS Fault Injection Simulator does not yet support targets in different accounts, but this doesn’t hinder us to run experiments…<\/p>\n","protected":false},"author":2,"featured_media":2847,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"footnotes":""},"categories":[173],"tags":[177,178,179,176,180,181],"class_list":["post-2707","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-chaos-engineering","tag-cross-account","tag-crossaccount","tag-fault-injection-simulator","tag-fis","tag-step-functions","tag-stepfunctions"],"_links":{"self":[{"href":"https:\/\/blog.domb.net\/index.php?rest_route=\/wp\/v2\/posts\/2707","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.domb.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.domb.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.domb.net\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.domb.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2707"}],"version-history":[{"count":32,"href":"https:\/\/blog.domb.net\/index.php?rest_route=\/wp\/v2\/posts\/2707\/revisions"}],"predecessor-version":[{"id":2768,"href":"https:\/\/blog.domb.net\/index.php?rest_route=\/wp\/v2\/posts\/2707\/revisions\/2768"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.domb.net\/index.php?rest_route=\/wp\/v2\/media\/2847"}],"wp:attachment":[{"href":"https:\/\/blog.domb.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2707"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.domb.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2707"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.domb.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2707"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}