Create a remediation worker group for your AWS cloud accounts

To correctly configure a remediation worker in AWS, you'll need to create IAM roles for the worker and each of the cloud accounts you plan to remediate in before taking any additional steps.

For a list of supported AWS remediation jobs and their minimum permissions when setting up IAM policies, refer to the VMware Aria Automation for Secure Clouds Remediation Github repository.

Configure your account permissions

The AWS remediation framework is designed to work in an environment where a customer hosts the remediation work in a central cloud account that can access and run remediation scripts on other cloud accounts. The directions are designed with this model in mind, but you may be working with single cloud account. That said, you must have a single cloud account to remediate. In that case, you can still follow these directions successfully as long as you keep in mind that you're deploying the worker and running the remediations on the same account.

To get started, you must create at least two IAM roles, each with a unique policy.

• An IAM role associated with the cloud account you plan to run remediations on.
  • Attached policy: Grants the minimum permissions needed to perform the selected remediation actions on the cloud account.
• An IAM role to serve as the instance profile for the EC2 instance the remediation worker runs on.
  • Attached policy: Allows the EC2 instance to assume the permissions set on the cloud account while performing a remediation action.

Create a cloud account IAM role

You can refer to the AWS documentation for specific instructions on creating an IAM role for your cloud account. When creating the role, you should configure an external ID to connect your cloud account to a remediation worker group later on. The value for the external ID must match your organization ID, or the remediation worker won't be able to connect to your account.

To create a policy to attach to the IAM role, refer to the minimum_policy.json files for the remediation jobs you want to run on your cloud account. This example shows a policy that grants permissions to remediate open PostgreSQL Server ports on security groups in your cloud account. This sample policy grants permission to remove inbound security group rules and was created with content from the associated job page.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ec2:RevokeSecurityGroupIngress"
            ],
            "Resource": "*"
        }
    ]
}

You can add support for more remediation jobs by including their required permissions in Actions. Observe least privilege principles by only including the permissions for the types of findings you plan to remediate.

Once you've created the IAM role, copy the Role ARN and External ID for use in the next section.

Repeat this process for as many cloud accounts as you plan to remediate.

Create an IAM instance profile for EC2

You can refer to the AWS documentation for specific instructions on creating an IAM instance profile for EC2.

You must create the IAM instance profile in the same cloud account you plan to host the remediation worker in (see the Deploy remediation worker section). This might be the same account you set up an IAM role for if you're remediating a single cloud account, or a separate one if you're remediating multiple cloud accounts.

The attached policy for this role uses sts:AssumeRole to allow the remediation worker to assume the cloud account role you created in the previous step. You can create the policy with this JSON:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "*"
        }
    ]
}

Once you've created the role and attached a policy, you can proceed to the next section.

Create the remediation worker group

VMware Aria Automation for Secure Clouds uses remediation worker groups to issue commands to remediation workers after they've been deployed and configured with remediation jobs to perform. This section shows you how to create a worker group and associate it with any cloud accounts you set up permissions for in the previous section.

1. From your dashboard, navigate to Settings > Remediation worker groups.

2. Enter a name for the worker group and an optional description.

3. Click on Generate Deployment Info to get credentials for deploying the remediation worker. Make sure you copy and store the client secret in a safe place-for security purposes, it is displayed only once. If you lose the secret, you must delete the existing worker group and create a new one. You can also copy the code snippet here for use in the next section.

4. On the next screen, associate your cloud accounts with the worker group. Enter the Role ARN and External ID you copied in the previous section.

Note: You are responsible for ensuring that the appropriate permissions are created in the cloud account for the desired remediation actions, whether native or custom. If this is not setup correctly, remediation actions will fail later and log the missing permissions. You can add or remove more cloud accounts after creating the worker group (click the Options button from the worker group details page), but at least one cloud account must be associated during setup to create the worker group.

5. Click on Save to create the worker group.

You should see the worker group displayed in your list of remediation worker groups now. Many users may find they only need a single worker group for their entire organization, but if you need logical separation between different groupings of resources (like cloud providers or software environments) then it may be useful to create multiple worker groups. A typical use case would be to create an individual worker group for development, staging, production, and so on.

Deploy the remediation worker

Now that you've configured permissions access to your cloud accounts and associated them with a remediation worker group, you can create the remediation worker in your AWS environment. This section shows you how to provision an EC2 instance and deploy the docker container that runs the worker. You must connect to the instance by SSH or other means to perform some of these steps.

1. Provision an EC2 instance in the same cloud account you created an IAM instance profile in previously. The minimum specifications to host the remediation worker are 128 MB memory and 1/2 core CPU.

Note: Make sure you assign the instance profile you created in the first section when launching the instance, or it won't be able to access any cloud accounts for remediation.

2. Install Docker on your EC2 instance. You can refer to the documentation at AWS or Docker for specific steps based on the image your instance is running.

3. Connect to your EC2 instance and run the code snippet from the deployment info in the previous section to start the worker image.

docker run --name vss-remediation-{WORKER_GROUP_NAME} \
-e VSS_CLIENT_ID={ENTER CLIENT ID} \
-e VSS_CLIENT_SECRET={ENTER CLIENT SECRET} \
vmware/vss-remediation-worker:latest

Note: To ensure the worker image remains running in the event of a host reboot, consider configuring the docker container with a restart policy

The worker should connect to the remediation worker group you created automatically. You can confirm by going to the details page for your worker group and selecting the Workers tab.

Now that your worker is deployed and connected to your remediation worker group, you're ready to start creating configuring remediation jobs on your associated cloud accounts. Refer to the Setting up remediations section for the next steps.

Update the remediation worker

New remediation jobs are frequently added for additional AWS rules. If you want to take advantage of new jobs, re-deploy the remediation worker to your EC2 instance (make sure you remove the old one), and then add the desired remediation jobs as described further in this guide.

Troubleshooting

If you see the worker container error out, ensure that there are no outbound networking rules or firewalls configured to block calls to VMware Aria Automation for Secure Clouds. You may have to allow certain calls so that the worker can communicate back to the service. You may also need to see if the worker container has the appropriate networking configuration. Verify this by running the command docker network ls to list all the containers with their drivers. Please make sure an appropriate network driver, such as bridge, is selected for the worker container. This can also be passed into the worker execute command as an argument --network=bridge.