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 the Edge Delta SaaS needs to access your AWS for services such as rehydration, or if an Edge Delta Hosted Agent 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 hosted agents 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 authenticaiton. 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. Hosted agents 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 agent configuration:

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

Shared Credentials

The Edge Delta agent 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 agent 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 agent 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)