Add Amazon Web Services (AWS) Cloud Provider
- Before You Begin
- Review: Use Kubernetes Cluster Cloud Provider for EKS
- Review: Switching IAM Policies
- Step 1: Add the Cloud Provider
- Step 2: Display Name
- Step 3: Credentials
- Review: AWS Security Token Service (STS)
- Review: AWS GovCloud and Override Default Region
- Review: AWS IAM Roles and Policies
- All AWS Cloud Providers: DescribeRegions Required
- Policies Required: Elastic Container Registry (ECR)
- Policies Required: Amazon S3
- Policies Required: ECS (Existing Cluster)
- Policies Required: AWS AMI/ASG Deployments
- Policies Required: AWS CodeDeploy
- Policies Required: AWS EC2
- Policies Required: Amazon Lambda
AWS is used as a Harness Cloud Provider for obtaining artifacts, deploying services, and for verifying deployments using CloudWatch Verification Overview.
This topic explains how to set up the AWS Cloud Provider, and the IAM roles and policies needed by the AWS account used in the Cloud Provider.
In this topic:
- Before You Begin
- Review: Use Kubernetes Cluster Cloud Provider for EKS
- Review: Switching IAM Policies
- Step 1: Add the Cloud Provider
- Step 2: Display Name
- Step 3: Credentials
- Review: AWS Security Token Service (STS)
- Review: AWS GovCloud and Override Default Region
- Review: AWS Permissions
- All AWS Cloud Providers: DescribeRegions Required
- Policies Required: Elastic Container Registry (ECR)
- Policies Required: Amazon S3
- Policies Required: ECS (Existing Cluster)
- Policies Required: AWS AMI/ASG Deployments
- Policies Required: AWS CodeDeploy
- Policies Required: AWS EC2
- Policies Required: Amazon Lambda
Before You Begin
- See Harness Key Concepts.
Review: Use Kubernetes Cluster Cloud Provider for EKS
If you want to connect Harness to Elastic Kubernetes Service (Amazon EKS), use the platform-agnostic Kubernetes Cluster Cloud Provider.
Review: Switching IAM Policies
If the IAM role used by your AWS Cloud Provider does not have the policies required by the AWS service you want to access, you can modify or switch the role.
This entails changing the role assigned to the AWS account or Harness Delegate your AWS Cloud Provider is using.
When you switch or modify the IAM role used by the Cloud Provider, it might take up to 5 minutes to take effect.
Step 1: Add the Cloud Provider
To add a cloud provider to your Harness account, do the following:
- Click Setup, and then click Cloud Providers.
- Click Add Cloud Provider and select Amazon Web Services.
The Add Amazon Web Services Cloud Provider panel appears.
Step 2: Display Name
Choose a name for this provider. This is to differentiate AWS providers in Harness. It is not the actual AWS account name.
Step 3: Credentials
Assume the IAM Role on Delegate
This is the recommended method.
If you selected Assume the IAM Role on Delegate, in Delegate Selector, enter the Selector of the Delegate that this Cloud Provider will use for all connections. For information about Selectors, see Select Delegates for Specific Tasks with Selectors.
Enter AWS Access Keys manually
If you selected Enter AWS Access Keys manually, enter your Access Key and your Secret Key.
For secrets and other sensitive settings, select or create a new Harness Encrypted Text secret.
For more information, see Access Keys (Access Key ID and Secret Access Key) from AWS.
Use IRSA (IAM roles for service accounts)
Select Use IRSA if you want to have the Harness Kubernetes Delegate in AWS EKS use a specific IAM role when making authenticated requests to resources.
By default, the Harness Kubernetes Delegate uses a ClusterRoleBinding to the default service account. Instead, you can use AWS IAM roles for service accounts (IRSA) to associate a specific IAM role with the service account used by the Harness Kubernetes Delegate.
Setting up this feature requires a few more steps than other methods, but it is a simple process.
- Create the IAM role with the policies you want the Delegate to use. The policies you select with depend on what AWS resources you are deploying via the Delegate. See the different Policies Required sections in this document.
- In the cluster where the Delegate will be installed, create a service account and attach the IAM role to it.
Here is an example of how to create a new service account in the cluster where you will install the Delegate and attach the IAM policy to it:
eksctl create iamserviceaccount \
--name=cdp-admin \
--namespace=default \
--cluster=test-eks \
--attach-policy-arn=<policy-arn> \
--approve \
--override-existing-serviceaccounts —region=us-east-1
- In Harness, download the Harness Kubernetes Delegate YAML file. See Install the Harness Kubernetes Delegate.
- Open the Delegate YAML file in text editor.
- Add service account with access to IAM role to Delegate YAML.
There are two sections in the Delegate YAML that you must update.
First, update the ClusterRoleBinding
by adding replacing the subject name default
with the name of the service account with the attached IAM role.
Old ClusterRoleBinding
:
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: harness-delegate-cluster-admin
subjects:
- kind: ServiceAccount
name: default
namespace: harness-delegate
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
New ClusterRoleBinding
(for example, using the name iamserviceaccount
):
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: harness-delegate-cluster-admin
subjects:
- kind: ServiceAccount
name: iamserviceaccount
namespace: default
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
Next, update StatefulSet spec with the new serviceAccountName
.
Old StatefulSet spec serviceAccountName
:
...
spec:
containers:
- image: harness/delegate:latest
imagePullPolicy: Always
name: harness-delegate-instance
ports:
- containerPort: 8080
...
New StatefulSet spec serviceAccountName (for example, using the name iamserviceaccount
):
...
spec:
serviceAccountName: iamserviceaccount
containers:
- image: harness/delegate:latest
imagePullPolicy: Always
name: harness-delegate-instance
ports:
- containerPort: 8080
...
- Save the Delegate YAML file.
- Install the Delegate in your EKS cluster and register the Delegate with Harness. See Install the Harness Kubernetes Delegate.
AWS_ROLE_ARN
and AWS_WEB_IDENTITY_TOKEN_FILE
are added automatically by EKS.- Create a new AWS Cloud Provider.
- In Credentials, select Use IRSA.
- In Delegate Selector, select the Delegate you used.
- Click Test to verify the Delegate credentials.
Review: AWS Security Token Service (STS)
If you want to use one AWS account for the connection, but you want to deploy in a different AWS account, use the Assume STS Role option. This option uses the AWS Security Token Service (STS) feature.
In this scenario, the AWS account used for AWS access in Credentials will assume the IAM role you specify in Role ARN setting.

To assume the role in Role ARN, the AWS account in Credentials must be trusted by the role. The trust relationship is defined in the Role ARN role's trust policy when the role is created. That trust policy states which accounts are allowed to give that access to users in the account.
The assumed role in Role ARN must have all the IAM policies required to perform your Harness deployment, such as Amazon S3, ECS (Existing Cluster), and AWS EC2 policies. For more information, see Assuming an IAM Role in the AWS CLI from AWS.
To use AWS Security Token Service (STS) for cross-account access, do the following:
- Select the Assume STS Role option.
- In Role ARN, enter the Amazon Resource Name (ARN) of the role that you want to assume. This is an IAM role in the target deployment AWS account.
- (Optional) In External ID, if the administrator of the account to which the role belongs provided you with an external ID, then enter that value. For more information, see How to Use an External ID When Granting Access to Your AWS Resources to a Third Party from AWS.
Review: AWS GovCloud and Override Default Region
By default, Harness uses the us-east-1 region to test the credentials for the Cloud Provider.
If you want to use an AWS GovCloud account for this Cloud Provider, use the Override Default Region option.
In Region, select the GovCloud region you want to use.
GovCloud is used by organizations such as government agencies at the federal, state, and local level, as well as contractors, educational institutions. It is also used for regulatory compliance with these organizations.
Restrictions
You can access AWS GovCloud with AWS GovCloud credentials (AWS GovCloud account access key and AWS GovCloud IAM user credentials).
You cannot access AWS GovCloud with standard AWS credentials. Likewise, you cannot access standard AWS regions using AWS GovCloud credentials.
Review: AWS IAM Roles and Policies
The AWS role policy requirements depend on what AWS services you are using for your artifacts and target infrastructure (ECR, S3, EC2, ECS, etc).
In this topic, we have called out the deployment scenario, such as Lambda and AMI deployments.
Here are the user and access type requirements that you need to consider.
User: Harness requires the IAM user be able to make API requests to AWS. For more information, see Creating an IAM User in Your AWS Account from AWS.
User Access Type: Programmatic access. This enables an access key ID and secret access key for the AWS API, CLI, SDK, and other development tools.
As described below, DescribeRegions
is required for all AWS Cloud Provider connections.
All AWS Cloud Providers: DescribeRegions Required
The DescribeRegions action is required for all AWS Cloud Providers regardless of what AWS service you are using for your target infrastructure.
Harness needs a policy with the DescribeRegions
action so that it can list the available regions for you when you define your target architecture.
Create a Customer Managed Policy, add the DescribeRegions
action to list those regions, and add that to any role used by the Cloud Provider.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "ec2:DescribeRegions",
"Resource": "*"
}
]
}
Policies Required: Elastic Container Registry (ECR)
Policy Name:AmazonEC2ContainerRegistryReadOnly
.
Policy ARN: arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
.
Description: Provides read-only access to Amazon EC2 Container Registry repositories.
Policy JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:GetRepositoryPolicy",
"ecr:DescribeRepositories",
"ecr:ListImages",
"ecr:DescribeImages",
"ecr:BatchGetImage"
],
"Resource": "*"
}
]
}
Policies Required: Amazon S3
There are two policies required:
- The Managed Policy AmazonS3ReadOnlyAccess.
- The Customer Managed Policy you create using
ec2:DescribeRegions
.
Policy Name: AmazonS3ReadOnlyAccess
.
Policy ARN: arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
.
Description: Provides read-only access to all buckets via the AWS Management Console.
Policy JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "*"
}
]
}
Policy Name: HarnessS3
.
Description: Harness S3 policy that uses EC2 permissions. This is a customer-managed policy you must create. In this example we have named it HarnessS3
.
Policy JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "ec2:DescribeRegions",
"Resource": "*"
}
]
}
Policies Required: ECS (Existing Cluster)
Ensure that you add the IAM roles and policies to your ECS cluster when you create it. You cannot add the IAM roles and policies to an existing ECS cluster. You can add policies to whatever role is already assigned to an existing ECS cluster.
In addition to the default ECS role, ecsInstanceRole, these policies are required:
- The Managed Policy AmazonEC2ContainerServiceforEC2Role from AWS.
- The Managed Policy AmazonEC2ContainerServiceRole from AWS.
- The Customer Managed Policy you create using Application Auto Scaling.
Attach these policies to the ecsInstanceRole role, and apply that to your ECS cluster when you create it. For information on ecsInstanceRole, see Amazon ECS Instance Role from AWS.
ELB, ALB, and ECS
Policy Name: AmazonEC2ContainerServiceforEC2Role
.
Policy ARN: arn:aws:iam::aws:policy/AmazonEC2ContainerServiceforEC2Role
.
Description: Makes calls to the Amazon ECS API. For more information, see Amazon ECS Container Instance IAM Role from AWS.
Policy JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:CreateCluster",
"ecs:DeregisterContainerInstance",
"ecs:DiscoverPollEndpoint",
"ecs:Poll",
"ecs:RegisterContainerInstance",
"ecs:StartTelemetrySession",
"ecs:UpdateContainerInstancesState",
"ecs:Submit*",
"ecr:GetAuthorizationToken",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
Policy Name: AmazonEC2ContainerServiceRole
.
Policy ARN: arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceRole
.
Description: Default policy for Amazon ECS service role.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:Describe*",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:DeregisterTargets",
"elasticloadbalancing:Describe*",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:RegisterTargets"
],
"Resource": "*"
}
]
}
Policy Name: HarnessECS
.
Description: Harness ECS policy. This is a customer-managed policy you must create. In this example we have named it HarnessECS
.
Policy JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:DescribeRepositories",
"ecs:ListClusters",
"ecs:ListServices",
"ecs:DescribeServices",
"ecr:ListImages",
"ecs:RegisterTaskDefinition",
"ecs:CreateService",
"ecs:ListTasks",
"ecs:DescribeTasks",
"ecs:DeleteService",
"ecs:UpdateService",
"ecs:DescribeContainerInstances",
"ecs:DescribeTaskDefinition",
"application-autoscaling:DescribeScalableTargets",
"iam:ListRoles",
"iam:PassRole"
],
"Resource": "*"
}
]
}
Notes
- There is a limit on how many policies you can attach to a IAM role. If you exceed the limit, copy the permissions JSON under Action, create a single custom policy, and add them to the policy.
- Due to an AWS limitation, Harness is unable to limit the three actions for ECS to
Create
,Update
, andDeleteService
for just a specific cluster/resource. This limitation is why we requireResource *
. - ECS with Public Docker Registry: All ECS permissions are required.
- ECS with Private Docker Registry: All ECS permissions are required. Also, the Docker agent on the container host should be configured to authenticate with the private registry. Please refer to AWS documentation here.
- ECS with ECR: For ECS and ECR, all permissions are required.
- ECS with GCR: This is currently not supported.
Auto Scaling with ECS
For Auto Scaling, the AWS Managed policy AWSApplicationAutoscalingECSServicePolicy should be attached to the default ecsInstanceRole role, and applied to your ECS cluster when you create it.
For information on AWSApplicationAutoscalingECSServicePolicy, see Amazon ECS Service Auto Scaling IAM Role from AWS. For information on ecsInstanceRole, see Amazon ECS Instance Role from AWS.
Policy Name: AWSApplicationAutoscalingECSServicePolicy
.
Policy ARN: arn:aws:iam::aws:policy/AWSApplicationAutoscalingECSServicePolicy
.
Description: Describes your CloudWatch alarms and registered services, as well as permissions to update your Amazon ECS service's desired count on your behalf.
Policy JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:DescribeServices",
"ecs:UpdateService",
"cloudwatch:PutMetricAlarm",
"cloudwatch:DescribeAlarms",
"cloudwatch:DeleteAlarms"
],
"Resource": [
"*"
]
}
]
}
Policies Required: AWS AMI/ASG Deployments
For details on these deployments, see AWS AMI Quickstart and AMI How-tos.
Provisioned and Static Hosts
Policy Name: AmazonEC2FullAccess
.
Policy ARN: arn:aws:iam::aws:policy/AmazonEC2FullAccess
.
Description: Provides full access to Amazon EC2 via the AWS Management Console.
Policy JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "elasticloadbalancing:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "cloudwatch:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "autoscaling:*",
"Resource": "*"
}
]
}
Tagging
AMI Blue/Green deployments require AWS tags. Please create the following custom policy and apply it to the IAM role used by the AWS Cloud Provider (access key or IAM role applied to the Harness Delegate).
This is a customer managed policy. Here we call it HarnessAmiTagging
.
Policy Name: HarnessAmiTagging
.
Description: Enables AWS tagging for Harness AMI Blue/Green deployments.
Policy JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:CreateOrUpdateTags",
"autoscaling:DeleteTags",
"autoscaling:DescribeTags"
],
"Resource": "*"
}
]
}
Policies Required: AWS CodeDeploy
There are two policies required: AWSCodeDeployRole and AWSCodeDeployDeployerAccess.
Policy Name: AWSCodeDeployRole
.
Policy ARN: arn:aws:iam::aws:policy/service-role/AWSCodeDeployRole
.
Description: Provides CodeDeploy service access to expand tags and interact with Auto Scaling on your behalf.
Policy JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:CompleteLifecycleAction",
"autoscaling:DeleteLifecycleHook",
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeLifecycleHooks",
"autoscaling:PutLifecycleHook",
"autoscaling:RecordLifecycleActionHeartbeat",
"autoscaling:CreateAutoScalingGroup",
"autoscaling:UpdateAutoScalingGroup",
"autoscaling:EnableMetricsCollection",
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribePolicies",
"autoscaling:DescribeScheduledActions",
"autoscaling:DescribeNotificationConfigurations",
"autoscaling:DescribeLifecycleHooks",
"autoscaling:SuspendProcesses",
"autoscaling:ResumeProcesses",
"autoscaling:AttachLoadBalancers",
"autoscaling:PutScalingPolicy",
"autoscaling:PutScheduledUpdateGroupAction",
"autoscaling:PutNotificationConfiguration",
"autoscaling:PutLifecycleHook",
"autoscaling:DescribeScalingActivities",
"autoscaling:DeleteAutoScalingGroup",
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:TerminateInstances",
"tag:GetTags",
"tag:GetResources",
"sns:Publish",
"cloudwatch:DescribeAlarms",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeInstanceHealth",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:DeregisterTargets"
],
"Resource": "*"
}
]
}
Policy Name: AWSCodeDeployDeployerAccess
.
Policy ARN: arn:aws:iam::aws:policy/AWSCodeDeployDeployerAccess
.
Description: Provides access to register and deploy a revision.
Policy JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"codedeploy:Batch*",
"codedeploy:CreateDeployment",
"codedeploy:Get*",
"codedeploy:List*",
"codedeploy:RegisterApplicationRevision"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
Policies Required: AWS EC2
Provisioned and Static Hosts
Policy Name: AmazonEC2FullAccess
.
Policy ARN: arn:aws:iam::aws:policy/AmazonEC2FullAccess
.
Description: Provides full access to Amazon EC2 via the AWS Management Console.
Policy JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "elasticloadbalancing:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "cloudwatch:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "autoscaling:*",
"Resource": "*"
}
]
}
Trusted entities
Newly created roles under Amazon EC2 have trusted entities listed as ec2.amazonaws.com. For ECS, this needs to be updated with ecs.amazonaws.com. See the AWS documentation at Amazon ECS Service Scheduler IAM Role.
Policies Required: Amazon Lambda
The IAM role attached to your Delegate host (either an EC2 instance or ECS Task) must have the AWSLambdaRole policy attached. The policy contains the lambda:InvokeFunction
needed for Lambda deployments.
Policy Name: AWSLambdaRole
.
Policy ARN: arn:aws:iam::aws:policy/service-role/AWSLambdaRole
.
Description: Default policy for AWS Lambda service role.
Policy JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": [
"*"
]
}
]
}
For more information, see Identity-based IAM Policies for AWS Lambda from AWS.