AWS Connector Settings Reference

Updated 1 month ago by Michael Cretzman

AWS is used as a Harness Connector for activities such as obtaining artifacts, building and deploying services, and verifying deployments.

This topic provides settings and permissions for the AWS Connector.

In this topic:

AWS Permissions

The AWS role policy requirements depend on what AWS services you are using for your artifacts and target infrastructure.

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": "*"
}
]
}

AWS Policies Required

AWS S3

Reading from AWS S3

There are two policies required:

The AWS IAM Policy Simulator is a useful tool for evaluating policies and access.

Policy NameAmazonS3ReadOnlyAccess.

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": "*"
}
]
}
If you want to use an S3 bucket that is in a separate account than the account used to set up the AWS Cloud Provider, you can grant cross-account bucket access. For more information, see Bucket Owner Granting Cross-Account Bucket Permissions from AWS.
Writing to AWS S3

There are two policies required:

  • The Customer Managed Policy you create, for example HarnessS3Write.
  • The Customer Managed Policy you create using ec2:DescribeRegions.

Policy Name:HarnessS3Write.

Description: Custom policy for pushing to ECR.

Policy JSON:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": "s3:*Object",
"Resource": ["arn:aws:s3:::bucket-name/*"]
}
]
}

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": "*"
}
]
}
If you want to use an S3 bucket that is in a separate account than the account used to set up the AWS Cloud Provider, you can grant cross-account bucket access. For more information, see Bucket Owner Granting Cross-Account Bucket Permissions from AWS.
Read and Write to AWS S3

You can have a single policy that reads and writes with an S3 bucket.

See Allows read and write access to objects in an S3 Bucket and Allows read and write access to objects in an S3 Bucket, programmatically and in the console from AWS.

Here is an example that includes AWS console access:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ConsoleAccess",
"Effect": "Allow",
"Action": [
"s3:GetAccountPublicAccessBlock",
"s3:GetBucketAcl",
"s3:GetBucketLocation",
"s3:GetBucketPolicyStatus",
"s3:GetBucketPublicAccessBlock",
"s3:ListAllMyBuckets"
],
"Resource": "*"
},
{
"Sid": "ListObjectsInBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": ["arn:aws:s3:::bucket-name"]
},
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": "s3:*Object",
"Resource": ["arn:aws:s3:::bucket-name/*"]
}
]
}

AWS Elastic Container Registry (ECR)

Pulling from 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": "*"
}
]
}
Pushing to ECR

Policy Name: AmazonEC2ContainerRegistryFullAccess.

Policy ARN: arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess. See Amazon ECR Managed Policies from AWS.

Policy JSON Example:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:*",
"cloudtrail:LookupEvents"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"replication.ecr.amazonaws.com"
]
}
}
}
]
}

Use Kubernetes Cluster Connector for EKS

If you want to connect Harness to Elastic Kubernetes Service (Amazon EKS), use the platform-agnostic Kubernetes Cluster Connector Settings Reference.

Switching Policies

If the IAM role used by your AWS Connector 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 Connector is using.

When you switch or modify the IAM role used by the Connector, it might take up to 5 minutes to take effect.

AWS Connector Settings

Name

The unique name for this Connector.

ID

See Entity Identifier Reference.

Description

Text string.

Tags

See Tags Reference.

Credentials

Ensure that the AWS IAM roles applied to the credentials you use (the Harness Delegate or the access key) includes the policies needed by Harness to deploy to the target AWS service.

Credentials that enable Harness to connect your AWS account.

There are three options:

  • Assume IAM Role on Delegate
  • AWS Access Keys manually
  • Use IRSA

The settings for each option are described below.

Assume IAM Role on Delegate

This is often the simplest method for connecting Harness to your AWS account and services.

Once you select this option, you can select a Delegate in the next step of the AWS Connector.

Typically, the Delegate(s) is running in the target infrastructure.

AWS Access Key

The access key and your secret key of the IAM Role to use for the AWS account.

You can use Harness secrets for both. See Add Text Secrets.

Access and Secret Keys

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.

The following steps are for a new Delegate installation and new AWS Connector. If you updating an existing Delegate and AWS Connector, you can simply edit the Delegate YAML for your existing Delegate as described below, and select the Use IRSA option in your AWS Connector.

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 AWS 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 a 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:

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: default
namespace: harness-delegate-ng
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: harness-delegate-cluster-admin
subjects:
- kind: ServiceAccount
name: iamserviceaccount
namespace: harness-delegate-ng
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---

Next, update StatefulSet spec with the new serviceAccountName.

Old StatefulSet spec serviceAccountName:

New StatefulSet spec serviceAccountName (for example, using the name iamserviceaccount):

...
spec:
containers:
- image: harness/delegate:latest
imagePullPolicy: Always
name: harness-delegate-instance
ports:
- containerPort: 8080
...
...
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 a Kubernetes Delegate.

When you install the Delegate in the cluster, the serviceAccount you added is used and the environment variables AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE are added automatically by EKS.

Create a new AWS Connector.

In Credentials, select Use IRSA.

In Set up Delegates, select the Delegate you used.

Click Save and Continue to verify the Delegate credentials.

Enable cross-account access (STS Role)

Assume STS Role is supported for EC2 and ECS. It is not supported for EKS.

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.

The Harness Delegate(s) always runs in the account you specify in Credentials via Access/Secret Key or Assume IAM Role on Delegate.

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.

You can use Assume STS Role to establish trust between roles in the same account, but cross-account trust is more common.

Role ARN

The Amazon Resource Name (ARN) of the role that you want to assume. This is an IAM role in the target deployment AWS 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.

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.

The AWS IAM Policy Simulator is a useful tool for evaluating policies and access.

Troubleshooting

Error Checking Push Permissions

This error occurs when the AmazonEC2ContainerRegistryFullAccess policy is missing from the AWS role used for the AWS Connector.

See Also


Please Provide Feedback