Install AWS Cloud Service Agent

Continue, if you want to install the cloud service agent to attack AWS cloud resources. In case you are interested in host based attacks, attacking e.g. the host and software running on it, refer to Docker , Kubernetes or Linux Hosts installation documentation.
Capabilities
The cloud service agent uses cloud apis to interact with cloud resources.
The current features are:
Discover and shutdown EC2 instances​
​Blackhole Availability Zones​
​Integrate AWS FIS Experiments​
Required permissions for AWS API Access
For querying metadata and using the AWS API executing the attacks a suitable IAM role needs to be created.
The following policies needs to be attached to the IAM role. If you don't want to provide permission for a particular feature, you can disable the discovery by creating an environment variable STEADYBIT_AGENT_DISCOVERIES_DISABLED containing a comma separated list of discovery names.
EC2 Instance Discovery and Attack
Discovery Name: EC2InstancesDiscovery
iam-policy-ec2.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeTags",
        "ec2:StopInstances",
        "ec2:TerminateInstances",
        "ec2:StartInstances",
        "ec2:RebootInstances",
        "ec2:CreateTags"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}
Availability Zone Discovery and Attack
Discovery Name: AvailabilityZoneDiscovery
iam-policy-az.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:DescribeTags",
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeVpcs",
        "ec2:DescribeSubnets",
        "ec2:DescribeNetworkAcls",
        "ec2:CreateNetworkAcl",
        "ec2:CreateNetworkAclEntry",
        "ec2:ReplaceNetworkAclAssociation",
        "ec2:DeleteNetworkAcl",
        "ec2:CreateTags"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}
AWS Fis Experiments Integration
Discovery Name: FisExperimentTemplateDiscovery
iam-policy-fis.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "fis:ListExperimentTemplates",
        "fis:GetExperiment",
        "fis:StartExperiment",
        "fis:StopExperiment",
        "fis:TagResource"
      ],
      "Effect": "Allow",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:CreateServiceLinkedRole",
      "Resource": "arn:aws:iam::<YOUR-ACCOUNT>:role/aws-service-role/fis.amazonaws.com/AWSServiceRoleForFIS"
    }
  ]
}
FIS will create a ServiceLinkedRole AWSServiceRoleForFIS when you start an experiment. If you started the experiment from the ui and the role is already existing, you can omit the iam:CreateServiceLinkedRole permission. If you want to start the very first fis experiment via the steadybit agent, you will need to add the permission.
Authentication
The agent is using the default credentials provider chain. You can pass credentials using the following sequence:
1.Java System Properties (aws.accessKeyId and aws.secretAccessKey)
2.Environment variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY)
3.Web identity token from AWS STS
4.The shared credentials and config files
5.Amazon ECS container credentials
6.Amazon EC2 instance profile credentials
You can find more information about best matching ways to provide credentials in the following installation guides.
Installation guides
Install on EC2 Instance
The following command will download and run the latest steadybit agent package on your EC2 instance:
curl -sfL https://get.steadybit.io/agent-linux.sh | sh -s -- -a <agent-key> -e <platform-url> -o aws
For your convenience you can use the setup page in the SaaS platform, where your agent key is already prepared in the command. Make sure to add -o aws to the copied command.
See also the Amazon ECS Container Instance documentation for using User Data mechanism on new EC2 instances to automate the agent installation.
Authentication
If you installed the agent on an EC2 instance, the easiest way is to use the 6th option from the default credentials provider chain, namely the InstanceProfileCredentialsProvider .
Steps:
Assign your previous created IAM role to the ec2 instance. There is a slight difference between IAM Roles and Instance Profiles, if you see a message like No roles attached to instance profile, make sure to check this page​
The IAM role needs a trust relationship so that EC2 is able to assume the role.
{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": [
            "ec2.amazonaws.com"
          ]
        },
        "Action": "sts:AssumeRole"
      }
    ]
}
Install as ECS Task
Secret for accessing the agent image
First you need to create a secret for accessing our private Docker Registry (docker.steadybit.io) to download the agent image.
{
  "username": "_",
  "password": "<replace-with-agent-key>"
}
Example
For your convenience we have prepared an example task definition to use for ECS in EC2 (or FARGATE). Please fill in the missing "replace-with" prefixed fields:
{
    "family": "steadybit-agent",
    "requiresCompatibilities": [
        "<EC2 or FARGATE>"
    ],
    "networkMode": "awsvpc",
    "cpu": "512",
    "memory": "1024",
    "taskRoleArn": "<replace-with-task-role-arn>",
    "executionRoleArn": "<replace-with-execution-role-arn>",
    "containerDefinitions": [
        {
            "portMappings": [],
            "environment": [
                {
                    "name": "STEADYBIT_AGENT_KEY",
                    "value": "<replace-with-agent-key>"
                },
                {
                    "name": "STEADYBIT_AGENT_MODE",
                    "value": "aws"
                }
            ],
            "repositoryCredentials": {
              "credentialsParameter": "<replace-with-secret-arn-from-secretmanager>"
            },
            "image": "docker.steadybit.io/steadybit/agent:latest",
            "name": "steadybit-agent"
        }
    ]
}
Authentication
The taskRoleArn needs to have the required permissions mentioned before.
Make sure, that the role can be assumed by ECS and provide a trust relationship to the role.
{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": [
            "ecs-tasks.amazonaws.com"
          ]
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }
Install on EKS
You can use our helm chart with the parameter `agent.mode=aws`.
Authorization in EKS with WebIdentityTokenFileCredentialsProvider
If you installed the agent into an EKS cluster, the recommend way to provide credentials is to use the 3th option from the default credentials provider chain, namely the WebIdentityTokenFileCredentialsProvider .
With this option you need to associate an IAM role with a Kubernetes service account.
1.​Create an OIDC Provider for your cluster​
2.Create an IAM Role with the required permissions.
3.Allow the Role to be assumed by the OIDC Provider. Add the following trust relationship to the IAM Role
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<ACCOUNT>:oidc-provider/oidc.eks.<REGION>.amazonaws.com/id/<ID>"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.<REGION>.amazonaws.com/id/<ID>:aud": "sts.amazonaws.com",
                    "oidc.eks.<REGION>.amazonaws.com/id/<ID>:sub": "system:serviceaccount:<SERVICE-ACCOUNT-NAMESPACE>:<SERVICE-ACCOUNT-NAME>"
                }
            }
        }
    ]
}
1.Associate the IAM Role to your Kubernetes Service Account. If you are using our helm charts to create the Service Account, you can use the parameter serviceAccount.eksRoleArn.
Outside of AWS
You can dedicate any agent running outside of your AWS infrastructure to communicate with the AWS API. In this case you need to setup an IAM User with API credentials which is allowed to access the resources already described in the section above.
The following variables needs to be added to the environment configuration:
AWS_REGION=<replace-with-region-to-attack>
AWS_ACCESS_KEY_ID=<replace-with-aws-access-key>
AWS_SECRET_ACCESS_KEY=<replace-with-aws-secret-access-key>
Assume-Role into multiple AWS accounts
By default, the agent uses the provided credentials to discover all resources in the belonging AWS account.
Another option is to provide a comma separated list of role-ARNs via the environment variable STEADYBIT_AGENT_AWS_ASSUME_ROLE_LIST. The provided credentials are then only used to assume-role into the given role-ARNs.
In this case make sure:
The provided credentials are allowed to assume the provided role-ARNs.
iam-policy-assume-role.yml
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::<TARGET-ACCOUNT>:role/steadybit-agent"
        }
    ]
}
The given roles themself have all required permissions.
The given roles do have trust relationship to allow to be assumed by the given credentials.
relationship.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<ACCOUNT-RUNNING-THE-AGENT>:<ROLE-RUNNING-THE-AGENT>"
            },
            "Action": "sts:AssumeRole",
            "Condition": {}
        }
    ]
}
F.A.Q
Q: The agent is running, but I can't see any AWS Attacks.
A: Maybe you missed allowing your team to execute the attack? Check your team settings and add the required permissions.
​
Q: Can I run multiple instances of the agent on the same host?
A: Yes, you can. If you want to run multiple instances of the AWS-Cloud-Agent you need to consider, that the agent needs a unique identifier. By default, the hostname is used for that. If you are running multiple instances on the same host, you need to provide an identifier via STEADYBIT_AGENT_IDENTIFIER.
​
Q: Can I run multiple instances of the agent using the helm chart?
A: Yes, but you currently need to use an own namespace for each agent. The namespace is then used as identifier.
​
Q: How can I make sure, that I don't attack the agent itself?
A: We recommend running the cloud agent in a separate subnet to be sure that the agent is still working properly, when you are attacking the cloud resources. The subnet of the agent will be excluded from network based attacks like the Blackhole Zone Attack.
Install on Amazon Elastic Container Service (ECS) running on EC2
Configuration Options
Last modified 8d ago