AWS Amplify, Secured DevOps - Part 1, Why It Matters

Well, fresh off an awesome AWS re:Invent, I wanted to put out a short series of posts about a common issue I run into talking with people about CI/CD. These posts center around the aws-exports.js that the CLI will generate when initializing or pulling from the Admin/Studio UI. If you're unfamiliar with this, I'd recommend starting at the Getting Started section of the AWS Amplify Documentation.

What is inside the aws-exports.js file that makes it such a big deal, and why do we exclude it in the first place?

First, you have to understand why committing credentials into a source code repository is generally seen as a bad idea. For a good read on this, take a look at Why storing secrets and passwords in Git is a bad idea. TL;DR: It's not a good idea, don't do it.

So with that established, let's look at the aws-exports.js file:

// WARNING: DO NOT EDIT. This file is automatically generated by AWS Amplify. It will be overwritten.

const awsmobile = {
  aws_project_region: 'us-east-1',
  aws_cognito_identity_pool_id:
    'us-east-1:<SNIP>',
  aws_cognito_region: 'us-east-1',
  aws_user_pools_id: 'us-east-1_<SNIP>',
  aws_user_pools_web_client_id: '<SNIP>',
  oauth: {
    domain: '<SNIP>',
    scope: [
      'phone',
      'email',
      'openid',
      'profile',
      'aws.cognito.signin.user.admin'
    ],
    redirectSignIn:
      'https://<SNIP>,<SNIP>',
    redirectSignOut:
      'https://<SNIP>,<SNIP>',
    responseType: 'code'
  },
  federationTarget: 'COGNITO_USER_POOLS',
  aws_cloud_logic_custom: [
    {
      name: 'AdminQueries',
      endpoint: 'https://<SNIP>.execute-api.us-east-1.amazonaws.com/dev',
      region: 'us-east-1'
    }
  ],
  aws_appsync_graphqlEndpoint:
    'https://<SNIP>.appsync-api.us-east-1.amazonaws.com/graphql',
  aws_appsync_region: 'us-east-1',
  aws_appsync_authenticationType: 'AMAZON_COGNITO_USER_POOLS',
  aws_appsync_apiKey: '<SNIP>'
};

export default awsmobile;

Just look at all the places I removed information and put in <SNIP>. If you wouldn't post it in a Dev.To blog post, here's a good rule of thumb, you probably shouldn't commit it.

While SPA and some SSG apps might end up embedding some of these values, generally, these are keys and values that the end-user should not get ahold of, or they could start running attacks on your backend surfaces.

Imagine someone getting the aws_appsync_apiKey along with the aws_appsync_graphqlEndpoint and just starting to DDoS or brute force their way past your auth. Or just overall knowing what the architecture for your application backend is. The less information the attacker has, the slower and more challenging it is to get in and do bad things.

Now, let's talk about what generates aws-exports.js. Like I mentioned at the beginning when you launch amplify init or run amplify pull with the variables given from the Admin/Studio UI. When you first run those commands, it will ask you where your source folder is (default is /src), and it will generate this file in that folder. Every time you run amplify pull from then on, it will regenerate the aws-exports.js file with any changes on the backend. It will also regenerate if you use amplify add <feature> with those features' security details.

Amplify will, by default, exclude aws-exports.js in the .gitignore file. Here is an example of a .gitignore file I had locally:

#amplify
amplify/\#current-cloud-backend
amplify/.config/local-*
amplify/mock-data
amplify/backend/amplify-meta.json
amplify/backend/awscloudformation
build/
dist/
node_modules/
aws-exports.js
awsconfiguration.json
amplifyconfiguration.json
amplify-gradle-config.json
amplifyxc.config

If you didn't read the linked article earlier, you might be inclined to remove these lines and commit these files anyway. I hope you don't.

Lastly, this aws-exports.js file is what you're going to use to configure your Amplify Libraries SDK in your project. Eventually, I'll add an "aws-modifications.js` tutorial for a simple trick I use for modifying that file in runtime.

Hopefully, that gives you a little more idea of what is going on under the hood and why you don't want to break it. Next, I will show you a few real-world scenarios that I've used for dealing with these and other security values. Keep an eye out for Part 2.