AWS Identity and Access Management (IAM) Role Authentication

Configuring AWS authentication.

  3 minute read  

Overview

You need to configure AWS authentication to enable access to AWS resources. If an Edge Delta Cloud Fleet needs to access your AWS resources then additional authentication using assumed roles is required.

Process Overview

Normal read access to AWS end points can be configured with a simple key ID and secret. For rehydration or Cloud Fleets access, Edge Delta has defined specific users. In this instance, authentication involves creating an AWS role and giving the required permissions to these users.

If the Edge Delta rehydration component is self-hosted or if you use a self-hosted back end you should not use assumed role authentication. Rather define your own users with appropriate roles and permissions or, if provide permission to the EC2 instance role.

Configure AWS Authentication

There are three methods you can use to provide AWS authentication to Edge Delta. Cloud Fleets and rehydration accesses your AWS Services from the Edge Delta back end and require an assumed role. This could also be achieved using a direct keyID/secKey but this approach is not recommended for security reasons.

Configuration File

You can provide the AWS key ID and AWS security key in the Edge Delta fleet configuration:

aws_key_id: '{{ Env "AWS_KEY_ID" }}'
aws_sec_key: '{{ Env "AWS_SECRET_KEY" }}'

Shared Credentials

The Edge Delta fleet can access the AWS endpoints using credentials in environment variables:

export AWS_ACCESS_KEY_ID="<key_id>"
export AWS_SECRET_ACCESS_KEY="<secret_key>"

Alternatively, if the Edge Delta fleet is running on EC2 instance it can use the EC2 instance role to access the AWS endpoints.

Assumed Roles

An assumed role provides permissions to specific resources for a short period of time. To do this you create a role, configure the required permissions, and provide the role arn to Edge Delta support.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"VisualEditor0",
         "Effect":"Allow",
         "Action": [
             "s3:PutObject",
             "s3:GetObject",
             "s3:ListBucket",
         ]
         "Resource":  "arn:aws:s3:::<Customer Account ID>"
      }
   ]
}

Edge Delta support will add the assumed role permission for the resource to the user and return a user arn. Next you create a trust relationship with the user arn for the required resources. It is not a best practice to create a trust relationship for the entire AWS organization account, rather create an external ID for the specific third-party user. This prevents a “confused deputy” vulnerability.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Principal":{
            "AWS":"arn:aws:iam::<ED Account ID>:user/<ED_IAM_User>"
         },
         "Action":"sts:AssumeRole",
         "Condition":{
            "StringEquals":{
               "sts:ExternalId":"<UUID provided by customer>"
            }
         }
      }
   ]
}

Finally, you return the external ID to Edge Delta to enable write access to objects in the bucket.

Authentication Order

The Edge Delta fleet will attempt to use the various authentication methods to access AWS resources in the following order:

  1. If an assumed role configuration is defined: (assume role provider)
  • Search for user keyID/secKey definitions in config to assume role
  • If no keyID/secKey definitions exist then use shared user for assuming the role
  1. If no assumed role configuration is defined: use the CredentialFilePath file if one is defined (shared credentials).
  2. If no shared credential file is configured, use the keyID/secKey pair if it is defined (static credentials).
  3. Otherwise, use env variables ($AWS_ACCESS_KEY_ID, $AWS_SECRET_ACCESS_KEY) (env credentials)