Access Key Management for .NET Applications – Part 1

In this post, we talk about the three methods for providing AWS access keys to your .NET applications and look at a few best practices. We look at the following questions while discussing the different options for managing access keys.

• Security: How do you securely store credentials and supply them to your application?
• Ease of management: What do you do if the credentials are compromised? How easy is it to rotate the credentials? How do you supply the new credentials to your application? (We’ll talk about this in detail in a future post.)

Setting credentials while constructing the service client

You can pass the IAM user credentials directly as parameters while constructing the service client. All service clients and the AWSClientFactory class have overloads that allow you to pass the credentials. The following snippet demonstrates creating an Amazon S3 client using AWSClientFactory.

var accessKey = "";// Get access key from a secure store
var secretKey = "";// Get secret key from a secure store
var s3Client = AWSClientFactory.CreateAmazonS3Client(accessKey,secretKey,RegionEndpoint.USWest2);

The preceding snippet assumes you have a way to manually retrieve IAM user access keys from a secure location. You should never store access keys in plain text in the code, as anyone with access to your code can misuse them.

Application configuration file

Instead of passing credentials to the service client in code, you can define access keys in an application configuration file (e.g., app.config or web.config). The SDK looks up the application configuration for both components of the access keys [AWSAccessKey and AWSSecretKey] and uses its values. We strongly recommended using IAM user access keys instead of root account access keys, as root account access keys always have full permissions to your entire AWS environment. If your application configuration file is ever compromised, you will want to ensure the access keys it contains are as limited in scope as possible. Defining an IAM user lets you do this.

The following snippet shows a sample app.config file and creation of a S3 client using the AWSClientFactory class.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="AWSAccessKey" value=""/>
    <add key="AWSSecretKey" value=""/>
    <add key="AWSRegion" value="us-west-2"/>
  </appSettings>
</configuration>

var s3Client = AWSClientFactory.CreateAmazonS3Client();

If you store credentials in the configuration file, be careful not to commit the file with credentials to your source control, making it available to anyone with access to it.

We looked at two methods to pass credentials, both of these are easy to use but only support trivial scenarios. For production grade usage, you will additionally need to implement the following

• Securely store and retrieve credentials.
• Implement a mechanism to rotate credentials.

Next, we’ll see a method that provides both these features out of the box.

Preferred method: IAM roles for EC2

If your application runs on an Amazon EC2 instance, you can use AWS Identity and Access Management(IAM) roles for EC2 to secure and simplify access key management. Roles for EC2 automatically distributes temporary security credentials to your EC2 instances that the AWS SDK for .NET in your application can use as if they were long-term access keys. These temporary security credentials are auto-rotated, and the SDK transparently picks up the new credentials before the existing ones expire.

To use this method, you first need to create an IAM role with only the permissions to access AWS resources required by your application. When you launch an EC2 instance with the IAM role, your application can query the EC2 instance metadata service for the temporary security credentials that will be retrieved automatically by the instance that assumes the role. The SDK supports loading these credentials from the EC2 instance metadata service, so you don’t need to take any special steps to use this feature. If you construct a service client without specifying the credentials, the client will pick up the credentials from the metadata service. (We’ll cover IAM roles in detail in a subsequent post.)

This is a good time to understand how credentials are loaded by the SDK when there are multiple ways in which they are made available to an application. Knowing this information can save you time debugging or trying to figure out the credentials being actually used when they are specified in multiple ways. The credentials are loaded or resolved in the following order

• Credentials explicitly passed to the service client.
• Credentials in application configuration file.
• Credentials from EC2 instance metadata service (applicable only when your code is running in an EC2 instance).

A few best practices

• Do not hard-code access keys in code or embed them in your application. Doing so makes it difficult to rotate the keys, and you risk disclosure.
• Do not use root access keys associated with your AWS account for development or in production. These keys have unlimited privileges. Instead, create IAM users and use their associated access keys.
• For applications that run on Amazon EC2, only use IAM roles to distribute access keys. The security and management properties of IAM roles for EC2 are superior to any alternative where you manually manage access keys.

You will find more best practices with in-depth information here.