AWS Storage Blog

AWS Identity and Access Management on AWS Snowball Edge

Many of our customers use AWS Snowball Edge devices for secure data transfer and edge computing applications. Recently, AWS announced support for AWS Identity and Access Management (IAM) on Snowball Edge. Before the introduction of IAM on Snowball Edge, IT administrators shared a single access key/secret key combination with all the users who wanted to copy files or run compute workloads. This method of access lacked granularity and flexibility to control individual services. IAM enables customers to securely manage access to AWS services and resources running on Snowball Edge devices by controlling which actions users can take. IAM also enables customers to manage which AWS resources on the device users can take those actions on. In this blog, we explore the IAM capabilities on Snowball Edge and show some practical examples.

Overview

With Snowball Edge, you can access the storage and compute power of the AWS Cloud locally and cost-effectively in places where connecting to the internet may not be an option. You can transfer hundreds of terabytes or petabytes of data between your on-premises data centers and Amazon Simple Storage Service (Amazon S3). Additionally, Snowball Edge provides the ability to run specific Amazon EC2 instance types and AWS Lambda functions, so that applications developed on-premises or in the cloud can be deployed on the same device. Common use cases of Snowball Edge include data migration, data transport, data analytics, image collation, IoT sensor stream capture, and machine learning inferences.

Snowball Edge employs multiple layers of encryption to ensure that customer data is safe and secure. The device is also locked during transit and is unlocked only by the customer, using a unique unlock-code and a manifest file. After unlocking the device, a set of credentials, like the access key/secret key can be retrieved from the device. These credentials are then used to enable access to the services on the device. With the introduction of IAM on Snowball Edge, customers can now deploy complex workflows requiring more granular access controls at the edge.

Getting Started

To get started, you must first unlock the Snowball Edge device, and then apply fine-grained access control using IAM. Using IAM, you can control which actions users can take and which AWS resources they can access just like they would in the AWS Cloud. Policies can be created and applied to the device using AWS OpsHub (OpsHub), AWS Command Line Interface (AWS CLI), or AWS Software Development Kit (SDK).

With OpsHub — an application that you can download and install on any Windows or Mac workstation — you now have a graphical user interface to manage your Snowball devices. With just a few clicks in AWS OpsHub, you are now able to:

  • Unlock and configure Snow Family devices
  • Drag-and-drop data to migrate to the Snow devices
  • Launch applications
  • Monitor Snow Family device metrics
  • Configure IAM users, roles, and policies

If you are interested in knowing more about OpsHub, view the AWS OpsHub documentation and check out this AWS OpsHub demo video:

The following diagram depicts the AWS capabilities available on Snowball Edge and how IAM users, policies, and roles apply to them:

Diagram depicting AWS capabilities available on Snowball Edge and how IAM users, policies, and roles apply to them

One key distinction is that IAM users, roles, and/or policies created on Snowball Edge are local to the Snowball Edge device only, and they do not persist in the AWS Cloud. Similarly users, groups, roles, and/or policies created in your VPC cannot be applied to the Snowball Edge device. In order to access the Snowball Edge with IAM credentials, you need the following:

  • An unlocked Snow Family device that is connected to your local network
  • AWS OpsHub, AWS CLI, or AWS SDK
  • A user’s credentials file provided by your administrator

With IAM on Snowball Edge, you can now perform the following:

  1. Create and manage AWS users for login to your Snowball Edge device
  2. Use permissions to allow and deny user access to the AWS resources on your Snowball Edge device
  3. Have fine-grained policies to control access to storage and EC2 resources
  4. Set policies to enable or restrict access to your buckets and objects
  5. Set permissions for your EC2 instances
  6. Specify a principal, like an EC2 instance, to have access to the data
  7. Provide temporary security credentials for accessing AWS resources for a short time period

Using IAM locally on AWS Snowball Edge

Let’s look at a scenario, wherein a Snowball Edge is being used for collecting, processing, and aggregating data from remote sensor devices. Using Snowball Edge, the sensors would transfer data into an incoming S3 bucket and/or prefix as S3 objects, which would then get moved to another S3 prefix after categorization. Thereafter, end users would have the ability to download those files (S3 objects). In this scenario, the organization would like to separate the different operational functions to be performed by different roles:

  • Use an IAM policy or role to categorize and permit moving S3 objects to another S3 prefix
  • Use an IAM policy or role on EC2 to perform processing tasks on the S3 objects
  • Use another IAM role that limits some users to only be able to read the categorized S3 objects

Let’s look at some examples of identity-based policies, where the IT administrator can attach these policies to IAM identities (users and roles) to grant permissions to perform operations on Snowball Edge resources locally.

To allow read and write access to a specific bucket, we would need the following IAM policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "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/*"
        }
    ]
}

Here is an example of how to allow only list operations to a specific bucket but deny everything else:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyObjectActions",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": "*"
        },
        {
            "Sid": "ListObjectsInBucket",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::bucket-name"
        }
    ]
}

If we wanted to limit access to only list objects, add objects, or retrieve objects from a specific bucket, we would use the following policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:List*"
            ],
            "Resource": "arn:aws:s3:::examplebucket/*"
        }
    ]
}

If we must allow EC2 to perform processing on the S3 objects, we must set up a policy to allow full access to EC2 instances running on Snowball Edge:

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

Now, if we want to have a policy that only allows access to start and stop Amazon EC2 instances, we would specify the following policy:

{
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Effect": "Allow", 
            "Action": [ 
                "ec2:StartInstances", 
                "ec2:StopInstances" 
            ], 
            "Resource": "*" 
        } 
    ] 
}

If you want to set up temporary security credentials to access AWS resources, you would do so by specifying a trust policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "AWS-account-ID" or "Principal ID"
                ]
            },
            "Action": [
                "sts:AssumeRole"
            ]
        }
    ]
}

With the IAM policy examples, you can easily modify the policy definition to further restrict or expand the permissions to suit your organization’s needs.

This feature is available in AWS Regions where Snowball Edge is supported, and is available at no additional cost.

Summary

In this post, we explored IAM on Snowball Edge and looked at sample policies to implement fine-grained access to S3 buckets and EC2 instances. You now have greater flexibility to control and enforce access to services and resources running on Snowball Edge using IAM users, roles, and policies. Using IAM on Snowball Edge is similar to the experience of using IAM in the AWS Cloud. You can also use OpsHub to manage IAM on Snow Family devices through the easy-to-use graphical user interface.

To learn more and get started with IAM on Snowball Edge, check out the following links:

Thank you for reading about AWS Identity and Access Management on AWS Snowball Edge. Please leave a comment in the comments section if you have any questions.

Ju-Lien Lim

Ju-Lien Lim

Ju-Lien Lim is a Senior Storage Specialist at AWS. Her area of focus is Hybrid Cloud Storage and Data Transfer Solutions. Ju enjoys helping customers innovate and accelerate their journey to the cloud. Outside of work, Ju enjoys spending time with family, traveling, and trying new foods.

Vinod Pulkayath

Vinod Pulkayath

Vinod Pulkayath is a Storage and Migration Specialist at AWS. He is a technology enthusiast and has worked in the industry for over three decades in various roles. Outside of work, he enjoys spending time with the family, gardening, and martial arts.